- 博客(204)
- 资源 (5)
- 收藏
- 关注
RSS订阅原创 基于开闭原则优化数据库查询语句拼接方法
这两种方案都遵循了开闭原则，使得代码在添加新的查询条件时更加灵活，同时减少了修改现有代码的风险。策略模式适合条件逻辑复杂、需要多维度扩展或复用的场景，通过接口化设计提升代码规范性。函数切片则以更轻量的方式实现条件解耦，适合快速开发或条件相对固定的场景。无论选择哪种方案，核心目标都是将查询条件的 “修改” 操作转化为 “扩展” 操作 —— 新增条件时无需触碰原有逻辑，从架构层面降低人为失误导致的风险。
2025-04-29 11:52:54
471
原创 误在非开发分支上开发解决方案
在新功能开发时，通常会创建独立的开发分支（如feature/new-feature），完成后合并到联调分支（如dev）。但有时会忘记切回开发分支，直接在dev分支上继续开发并提交代码，直到推送前才发现分支错误。此时若尚未执行git push，可通过以下步骤修复，避免污染dev分支。
2025-04-29 11:51:15
498
原创 ShardingSphere-Proxy数据隔离方案：不同用户操作不同的数据库
在分布式数据库架构中，实现多项目间的数据隔离是核心安全需求。不同业务模块需仅访问其专属数据库实例中的表结构，例如用户中心仅操作用户相关表，图文社区仅访问内容相关表。
2025-04-27 11:06:01
900
原创 优化 Go 语言函数传参设计，提升代码可读性与可维护性
控制参数数量：尽量将参数数量保持在 3 - 5 个以内。若参数过多，优先考虑使用结构体封装必需参数，或采用选项模式处理可选参数。规范命名：参数名应具有明确的描述性，能够准确传达参数的含义，避免使用含义模糊的名称。确定参数顺序：在 Go 语言中，通常将作为函数的第一个参数。常用于控制请求的生命周期，传递请求范围内的数据，将其前置有助于统一代码风格，提升可读性。选择传递方式：根据实际需求选择合适的参数传递方式。若函数需要修改传入的参数值，应使用指针传递；
2025-04-27 11:05:11
326
原创 golang不使用锁的情况下，对slice执行并发写操作，是否会有并发问题呢？
golang的slice不是线程安全的对象，那么，是否只要slice类型的对象在多线程中就需要加锁呢？
2025-03-26 13:55:04
1187
原创 诡异的服务重启原因探索
通过模拟服务器运行程序的方式，终于找到了问题所在。原因，就是我一开始思考的方向，服务器分配的资源限制导致了程序重启。事后，我们运行本地程序，通过任务管理器发现，内存也暴涨了3G左右，只是，一开始没有想到会这么消耗内存，加之Grafana的误导，使得我绕了一大圈。我做了进一步测试，通过协程并行获取15万的数据，内存消耗增长到了230M左右，这其实符合我们的预期。导致内存暴涨竟然是写Excel文件，写15万的数据，内存涨了3G左右，有点夸张。
2025-03-25 16:26:38
836
原创 寻找一个合适的并发平衡点
奇怪的是，增加连接池数量，耗时时长并没有发生改变，这个有时间再寻找背后的原因。通过实际测试，最适合是20的并发，单次查询100条，这种情况下，虽然耗时稍微长了一点，但是，没有单次查询耗时比较长的情况。没有十全十美的解决方案，世间万物都要有取舍，所以，仓央嘉措问：世间安得两全法，不负如来不负卿？都是顾了这头，丢了那头。而这就是我们的机会，要么取舍，要么极致，都有机会，人生又何尝不是这样的呢？
2025-03-25 16:25:45
802
原创 ShardingSphere：Error 20024 (44000): Sharding value ‘[B@4732d699‘ must implements Comparable
使用ShardingSphere分表组件，遇到了这么一个报错。这个报错的意思是指，分表键的类型没有实现Comparble接口，导致了这个报错。比如，有这么一个查询。我的分表规则是基于order_no实现，截取前四位，即我实际传的是string类型，但是， ShardingSphereProxy收到的确实[]byte类型，而这个类型并没有实现Comparble接口，导致了这个报错。
2025-03-19 18:12:54
478
原创 ShardingSphere：压测计划及结果分析
为深入了解系统在特定使用场景下的边界能力，并为实际部署所需资源提供可靠的数据支撑，我们特此制定本压测计划。本次压测将在 100 万数据量、分表数为 8 的环境下展开，分别对 100 的并发写入以及 500 的并发查询（包含含分表键查询和不含分表键查询两种情况）进行测试。
2025-03-19 15:33:43
876
原创 ShardingSphere：java.lang.NullPointerException报错原因
数据源定义的别名是ds,在规则中引用时写成了ds1,导致数据源名称与实际规则中引用的名称不一致导致了这个报错。获取存储单元时，因名称不匹配返回。
2025-03-12 15:30:44
325
原创 ShardingSphere:基于创建时间的时间戳进行分表的场景配置
那么，当基于创建时间的时间戳进行分表时，ShardingSphere 的配置规则该如何设置呢？目前官方文档并未给出基于时间戳分表的具体案例，本文将重点介绍此场景下的配置方案。
2025-03-12 15:29:33
787
原创 recover无法捕获的panic场景
由于recover只能在defer函数中才能生效，所以，recover无法捕获panic的场景主要有如下的一些场景。
2025-03-11 11:45:53
416
原创 初探Groovy
在使用 ShardingSphere 的分表组件时，我们常常会碰到各种分表场景，比如，根据创建的时间戳进行分表。ShardingSphere的INLINE模式通过配置分片逻辑，但仅支持 Groovy 语法中的基础运算（如取模、字符串拼接）和部分内置函数（如toString()基于此，了解一下Groovy表达式。
2025-03-11 11:45:31
414
原创 golang panic信息捕获
我们的日志接入阿里云sls平台，但是，日志是以json的格式存储在阿里云sls平台上，程序中产生的error,info等日志都可以实现以json的格式打印。但是，golang程序中产生的panic信息本身不是以json的格式输出，这就导致panic信息在阿里云sls平台上不方便检索。基于上述痛点，我们期望捕获程序的panic信息，并且以json的格式打印，如此，我们就可以方便的实现在阿里云sls平台上检索的目的。通过defer和recover()机制捕获panic信息。。
2025-02-19 16:39:32
582
原创 golang panic原理
stack结构体类型，包含lo（低地址）和hi（高地址）两个uintptr字段，描述 Goroutine 的栈内存区间[lo, hi)。初始栈大小为 2KB，可动态扩容至 1GB。m指向当前运行此 Goroutine 的内核线程（M）。调度器通过 M 将 Goroutine 映射到操作系统线程。
2025-02-19 16:39:24
376
原创 kafka消费能力压测：使用官方工具
在之前的业务场景中，我们发现Kafka的实际消费能力远低于预期。尽管我们使用了kafka-go组件并进行了相关测试。但并未能准确找出消费能力低下的原因。我们曾怀疑这可能是由我的电脑网络带宽问题或Kafka部署时的某些未知配置所导致。为了进一步确定问题的根源，我们决定对Kafka的消费能力进行压力测试。这篇文章中我们重点看一下压测的情况。
2025-02-18 15:04:42
956
原创 kafka的Docker镜像使用说明：wurstmeister/kafka
为了评估Kafka的性能，我们需要使用Kafka自带的压测工具。经过查询，我们发现Apache Kafka官方镜像中并未包含这些压测工具，但wurstmeister/kafka镜像中则包含了这些工具，因此决定采用该镜像进行安装。
2025-02-18 14:59:08
615
原创 2024年总结
我对程序开发有了不同的认识，我产生了约束大于规范的想法，有时候甚至会有点性能的牺牲，不再停留在文档的规范的约束，而是通过脚本生成代码，通过组件封装逻辑，比如，缓存组件的封装，基于cahe aside模式封装，把流程封装起来，让开发的人只关注业务逻辑，而忽略到底是先删除缓存，还是先删除持久化数据等。让我对团队建设也有了新的认识，规范化的流程有着重要的意义，虽然，有时候规范化的流程会带来时效性的损失，但是，规范化的流程带来了更可靠的代码的质量。在此，首先预祝各位，新的一年里，万事顺意，阖家欢乐！
2025-01-23 13:58:58
160
原创 单元测试在复杂业务逻辑开发中的重要性与实践
编写单元测试对于提高代码质量和开发效率具有重要意义。通过针对各个方法编写测试用例，我们可以迅速发现和修复问题，验证逻辑的正确性，并在代码重构时确保代码的稳定性。因此，我们应该在编写业务逻辑时养成良好的单元测试习惯，以更好地应对开发过程中的挑战。
2025-01-23 10:04:50
912
原创 接口鉴权方案
接口生成签名分两个逻辑，首先，对原始数据，过期时间，随机字符串组成的字符串明文进行加密，对这个密文进行加签，最后，把密文和签名编码生成最终的签名，在发送http请求时带上这个最终生成的签名。这个方案的设计思路主要是为了确保数据在传输过程中的保密性和完整性。secret通过这种设计，可以确保数据在传输过程中既不会被窃听（通过加密），也不会被篡改（通过签名验证）。同时，时间戳和随机字符串的使用也防止了重放攻击。
2025-01-16 09:22:25
368
原创 kafka-go:性能测试
在这篇文章中，由于kafka消息堆积引起的一些探索，上篇文章中遗留的问题，已经解决了消息堆积的问题，是通过打印日志的地方开启协程的方式解决了，但是，造成这个问题背后的原因还是值得探索探索。在实际测试过程中，通过pprof工具发现，这个地方context的会导致内存增长，且似乎没有下降的趋势，看着像是内存泄漏。这个问题很是令人困惑。这个问题，留待后续继续探索。今天，我们主要围绕着kafka-go这个组件探索展开。
2025-01-16 09:21:55
617
原创 kafka消费堆积问题探索
我们的商城项目用PHP写的，原本写日志方案用的是PHP的方案，但是，这个方案导致资源消耗一直降不下来，使用了20个CPU。后面考虑使用通过kafka的方案写日志，商城中把产生的日志丢到kafka中，在以go写的项目中消费kafka中的日志，并打印到控制台，最后，统一使用阿里sls抓取日志。我们kafka的分区有12个，go程序部署在k8s集群中，开启了弹性扩缩容，最多开启了8个pod进行消费，每秒产生的日志数量高峰在1500条左右，在这种情况下，依然产生了消息的堆积。
2025-01-11 11:40:17
1190
原创 golang:微服务架构下的日志追踪系统（二）
在使用Gin框架进行服务开发时，我们遇到了一个日志记录的问题。由于Gin的上下文（）实现了接口，在调用日志记录器的InfoWarnError等方法时，直接传递Gin的上下文通常不会导致编译错误。会导致我们在《》一文中定义的日志统计维度信息无法正确串联。为了解决这一问题，我们之前的解决方案是让业务方在使用日志记录器时，将Gin的上下文手动转换为。但这种方案带来了一个明显的弊端：它依赖于开发人员的主动转换，而开发人员往往会忘记进行这一步操作，直接传递Gin的上下文，从而导致日志并未按照预期格式打印。
2025-01-02 14:15:45
462
原创 golang:微服务架构下的日志追踪系统
为了把一个请求中所有的日志串联起来，我在日志中增加一个traceId的信息。》在这篇文章中，提供了第一个版本的解决方案。这个解决方案主要是解决单体服务架构下的日志串联问题。随着，我们分布式应用的发展，我们面临着需要一个能串联跨服务调用链路的日志系统。因此，我们在第一个版本上做了优化处理。主要是增加了日志的统计维度。
2025-01-02 13:51:35
1143
原创 图文社区用户搜索关系表设计方案：空间换时间的权衡与抉择
本质上第二种方案也是一种空间换时间的方案，把复杂的查询退化成简单的查询。空间换时间是一种思维方式，不能仅仅狭隘的认为用缓存换时间是空间换时间，同一个表基于不同的分表键或者分库健进行分表分库是空间换时间。
2024-12-20 16:40:05
887
原创 Postman前置脚本使用案例
由于我们的服务接口需要进行验签，每次通过Postman手动调用接口时都显得颇为繁琐。为了简化这一过程，我们可以充分利用Postman提供的脚本功能，自动为接口请求生成所需的签名。
2024-12-19 17:32:21
775
原创 基于阿里云日志服务的程序优化策略与实践
我们的服务端程序日志现已全面迁移至阿里云，这一举措极大地便利了我们通过阿里云的日志工具来深入洞察接口的调用状况。content是个json对象，request和path是content对象下的字段。我的需求是统计每个请求一分钟调用次数。以此为依据考虑优化的方案。比如，我上面的这个查询，每个接口调用次数一目了然。由于当前服务处于第一版本上线初期，在实际观察中发现，部分接口的调用频次极高，如某个用于查询 topic 的接口，其每分钟的请求量高达 1184 次。
2024-12-19 17:06:10
807
原创 ShardingSphere-Proxy 连接实战：从 Golang 原生 SQL 到 GORM 的应用
在这篇文章《》中，我们介绍了如何通过 Navicat 连接 ShardingSphere-Proxy。实际上，ShardingSphere-Proxy 兼容标准的 SQL 和原生数据库协议，因此你可以使用任何 MySQL 客户端与其进行连接，包括 Golang 的原生 SQL 库和流行的 ORM 框架 GORM。接下来，我们将展示如何使用 Golang 原生 SQL 和 GORM 连接并操作 ShardingSphere-Proxy。
2024-12-18 16:43:59
984
原创 基于K8s部署ShardingSphere-Proxy
在《》这篇文章中，根据官方文档，基于Docker，在本地快速部署并测试。这篇文章，我们主要介绍在k8s中部署的方案。
2024-12-18 14:09:28
926
原创 ShardingSphere-Proxy报错：Table or view ‘user‘ does not exist.
在《》这篇文章中，我详细记录了如何基于 Docker 运行 ShardingSphere-Proxy，并通过 Navicat 等工具连接到 ShardingSphere-Proxy 进行操作。然而，在实际测试过程中，我遇到了一个报错：“Table or view ‘user’ does not exist”。经过排查，我发现这个报错主要由两种场景触发。
2024-12-13 16:23:44
740
原创 ShardingSphereProxy:快速入门
在基于 Docker 安装 ShardingSphere 时，按照官方文档《》所提供的步骤操作即可。在运行ShardingSphereProxy之前，我们需要基于我们的测试场景修改配置文件，我测试场景中主要用了三张表，一个订单表，订单表基于user_id进行分表，还有一个user表和product表，这两张表未进行分表。基于这个场景，我们只需要修改两个配置文件，这两个配置文件分别是和。
2024-12-13 15:36:17
1172
原创 MySQL索引再认识
在最近的一次MySQL测试过程中，我的同事幺加明遇到了一些令人困惑的现象，这些现象超出了我们最初的预期。一直以来，我们在建立索引时，首要考虑的原则是在区分度大的字段上建立索引。然而，在实际测试中，我们发现区分度大的索引并不总是最佳选择，而是需要结合具体的使用场景进行深入分析。综上所述，索引的建立并不是一件简单的事情，而是需要根据实际数据场景进行测试和分析，才能得到最优解。的区分度不高，导致扫描的行数仍然较多，但由于是联合索引，至少减少了回表操作，所以查询速度得到了显著提升。索引后，查询时间只需要6毫秒！
2024-12-06 15:53:46
581
原创 ES 与 MySQL 在较大数据量下查询性能对比
1.mysql建立合适的索引，避免回表的情况下，其查询性能还是非常优异的。2.对于 ES 的测试结果，其实并不令人意外。不过，对于 ES 在字典中查找对应 keyword 的具体方式，我充满了好奇。目前我在思考它是否基于二分法进行查找呢？毕竟在面对庞大的数据量时，如果采用二分法，可能会在一定程度上影响查询速度。遗憾的是，目前我还没有找到关于 ES 底层查询原理的详细资料，所以这仅仅是我的一种猜测罢了。倘若让我来编写这样一个程序，在没有更多信息的情况下，二分法或许是我首先能想到的一种实现方式。
2024-12-06 15:34:21
1265
原创 vitess使用记录：vtctldclient，设置分表规则
继续探索未完成的事情。vitess使用记录系列已经写了好几篇了，记录了在测试过程中遇到的各种问题。》、《》、《》整个系列不具备很强的逻辑性，待我熟悉了这个开源组件之后，再做详细且完备的梳理。这篇文章，先说明一下如何设置分表规则，再记录遇到的问题。
2024-11-29 17:08:45
964
原创 vitess使用：基于源码运行vtctldclient工具
记录了基于官方文档起的一个vitess的server。由于设置分库分表的规则，需要使用vtctldclient这个工具，这个工具的摸索费了诸多周折，《》这篇文章记录了，想通过docker的方式运行这个工具，但是，这一步尝试以失败告终，目前尚不明白失败的原因，待后续有时间再做探索。最后，通过源码的方式运行这个工具。由于，我是在windows下运行这个工具。需要把这一段代码注释掉，这一段代码应该是和统计相关，和业务不相关，并不影响我们的测试。这个错误的解决需要import这两个包，主要是初始化用的。
2024-11-26 17:20:45
448
C#公共通用类
2018-09-07
ASP.NET MVC 5高级编程 第5版（中文版）
2018-07-03
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人