- 博客(217)
- 资源 (5)
- 收藏
- 关注
RSS订阅原创 营业数据多维度统计系统设计：解决跨期去重与精准分析难题
摘要：为解决多维度统计分析中的性能瓶颈和跨期数据去重问题，本文提出基于MySQL的预计算方案。采用星型/雪花模型构建数据体系，通过ETL四层架构（ODS→DWD→DWS→ADS）实现数据分层加工。方案创新性使用bitmap技术处理跨期去重，存储用户ID集合并通过位运算实现高效聚合。针对客单价、留存率等核心指标设计专门计算逻辑，建立会员消费时间序列中间表支持跨周期分析。性能测试显示，bitmap并集计算平均耗时469ms，内存消耗30MB，满足实时查询需求。该方案在保证查询效率的同时，解决了传统预计算方法面临
2025-07-17 14:46:16
1091
原创 巧用 Golang 函数特性实现单元测试中的数据库操作 Mock
本文介绍了一种基于Golang函数特性的Mock方案，用于解决单元测试中数据库依赖问题。通过将数据库操作封装为函数变量，在测试时重新赋值这些变量来模拟数据库行为，实现测试与数据库的解耦。该方法利用Golang函数作为"一等公民"的特性，无需引入复杂框架即可实现简洁高效的Mock功能。示例代码展示了如何模拟数据库查询结果和并发场景测试。该方案优势包括：消除数据库依赖、简化测试数据准备、提升测试效率、便于模拟特殊场景，同时保持代码简洁性，特别适合业务逻辑复杂、数据库操作频繁的项目场景。
2025-07-17 14:41:13
480
原创 docker设置镜像加速
在使用 Docker 拉取镜像时，我首先按照官方指引尝试配置阿里云镜像加速器。然而，多次操作后仍无法正常使用，怀疑是个人账号没有权限拉取镜像，但经过多轮权限检查与配置核对，始终未能定位问题根源，这一步的尝试最终以失败告终。为突破镜像拉取的瓶颈，我转向网络上的第三方解决方案，筛选了多个公开的镜像加速器资源后，选择了其中一个进行配置修改。具体操作包括更新 Docker 的 daemon.json 配置文件，添加新的加速器地址并重启 Docker 服务。完成这些步骤后，再次尝试拉取镜像。
2025-07-11 08:55:30
394
原创 golang条件编译：Build constraints
Go语言构建约束机制详解 Go语言通过构建约束(Build Constraints)实现跨平台编译控制，主要方式包括： 显式约束：使用//go:build注释行，支持逻辑运算符组合条件 隐式约束：通过文件名后缀(_GOOS_GOARCH)自动实现 案例演示了Windows和Linux平台的不同代码实现，其中： main.go调用SayHello() sayhello_linux.go和sayhello_windows.go分别实现平台特定逻辑 需注意gorun命令的两种使用方式差异： gorun main.
2025-07-09 11:24:46
965
原创 上线文档模板
变更项变更内容简述变更影响范围变更风险评估[配置文件路径1][如修改数据库连接地址][影响用户认证模块][低风险，验证后生效][配置文件路径2][如调整日志级别][影响系统日志输出][中风险，可能丢失部分调试信息]变更类型变更对象变更内容简述变更影响范围回滚方案表结构变更[表名1][如新增字段age][用户信息模块][执行SQL脚本回滚新增字段]数据迁移[表名2][如历史数据格式转换][订单统计模块][备份原数据，异常时恢复]脚本类型脚本路径/名称。
2025-07-09 08:37:33
678
原创 技术方案设计模板
示例：用户提交积分兑换请求→后端校验用户积分是否充足→校验商品库存→创建兑换订单→扣减积分→通知物流系统发货。1.重点描述需求的边界，比如，由于某些原因，某些功能这一期无法实现或者降级实现。2.如果是修改的逻辑，需要重点描述兼容性等问题，描述改动前后的影响。比如：积分扣减的原子性（模拟并发场景，避免超扣 / 漏扣）用文字或流程图描述需处理的核心流程（最好附上流程图）：。接口测试整个业务流程。
2025-07-09 08:35:03
381
原创 多维度缓存一致性挑战：Cache-Aside模式下的解决方案精要
针对多维度缓存场景下缓存删除遗漏的问题，提出了四种解决方案：1）集中式缓存键管理器统一管理实体缓存键；2）缓存标签机制通过标签批量删除关联键；3）事件驱动解耦业务与缓存清理；4）测试与监控机制兜底保障。核心思路是将多维度缓存关联关系从分散转为集中管理，建议根据场景特点选择方案：键管理器适合简单场景，标签机制灵活性高，事件驱动适合分布式系统，测试监控作为通用兜底方案。这些方案可有效解决缓存不一致问题，降低开发维护成本。
2025-07-08 11:43:26
981
原创 深度排查 benchstat 无输出问题：编码格式引发的 “隐形故障”
本文分析了Golang benchstat工具无输出的问题。通过源码分析发现benchstat严格依赖UTF-8编码解析基准测试文件，当文件采用GBK等非UTF-8编码时，会触发utf8.RuneError导致解析终止。验证测试表明，将文件转换为UTF-8无BOM编码后问题解决。建议规范基准测试文件的生成流程，确保统一使用UTF-8编码保存，以避免此类"隐形约束"导致的工具异常。
2025-07-04 08:32:44
473
原创 使用Process Monitor定位benchstat工具执行过程
摘要：在Windows11系统Go1.21.0环境下使用benchstat工具比较基准测试结果时遇到问题。通过ProcessMonitor工具捕获分析，确认benchstat已成功读取目标文件(20_runs_bench.txt)。使用官方示例文件(D:\Go\pkg\mod\golang.org\x\[email protected]\benchproc\testdata)测试成功，证明工具本身运行正常。
2025-07-02 16:47:28
415
原创 Benchmarking in Go
本文对比了Golang中JSON和Protobuf在序列化/反序列化性能上的差异。通过基准测试(Benchmark)方法，作者设置了包含20个字段的复杂消息结构，分别测试了两种协议的序列化速度、反序列化速度和数据大小。测试结果显示Protobuf在各方面均优于JSON：序列化速度快约1.5倍，反序列化速度快约2倍，生成的数据体积更小（480B vs 904B）。文章详细介绍了基准测试的实施方法，包括测试数据准备、测试命令参数(-benchmem,-count)以及推荐使用benchstat工具进行结果分析。
2025-07-02 15:23:53
753
原创 could not import google.golang.org/protobuf/proto
在Go项目测试中导入protobuf包时遇到"could not import google.golang.org/protobuf/proto"错误。临时解决方案是通过go mod vendor命令将依赖复制到本地的vendor目录，使编译器优先使用本地依赖而非模块缓存。虽然该方案能暂时解决问题，但用户仍困惑于根本原因未解决，寻求遇到过类似问题的开发者帮助。疑问焦点在于为何常规依赖管理方式会持续报错，而vendor模式却能正常工作。
2025-06-27 16:42:34
244
原创 缓存和数据库一致性问题
直接更新缓存方案虽能减少缓存穿透风险并确保数据一致性，但仍存在主从延迟和并发一致性问题。更优方案是采用Cache-Aside模式（更新数据库后删除缓存），配合SingleFlight解决缓存穿透，并通过延迟双删或Binlog监听应对主从延迟。该模式在并发场景下数据不一致概率极低，建议封装缓存组件隐藏底层实现，仅暴露数据库操作接口。
2025-06-27 11:18:01
1102
原创 基于开闭原则优化数据库查询语句拼接方法
这两种方案都遵循了开闭原则，使得代码在添加新的查询条件时更加灵活，同时减少了修改现有代码的风险。策略模式适合条件逻辑复杂、需要多维度扩展或复用的场景，通过接口化设计提升代码规范性。函数切片则以更轻量的方式实现条件解耦，适合快速开发或条件相对固定的场景。无论选择哪种方案，核心目标都是将查询条件的 “修改” 操作转化为 “扩展” 操作 —— 新增条件时无需触碰原有逻辑，从架构层面降低人为失误导致的风险。
2025-04-29 11:52:54
497
原创 误在非开发分支上开发解决方案
在新功能开发时，通常会创建独立的开发分支（如feature/new-feature），完成后合并到联调分支（如dev）。但有时会忘记切回开发分支，直接在dev分支上继续开发并提交代码，直到推送前才发现分支错误。此时若尚未执行git push，可通过以下步骤修复，避免污染dev分支。
2025-04-29 11:51:15
526
原创 ShardingSphere-Proxy数据隔离方案：不同用户操作不同的数据库
在分布式数据库架构中，实现多项目间的数据隔离是核心安全需求。不同业务模块需仅访问其专属数据库实例中的表结构，例如用户中心仅操作用户相关表，图文社区仅访问内容相关表。
2025-04-27 11:06:01
999
原创 优化 Go 语言函数传参设计，提升代码可读性与可维护性
控制参数数量：尽量将参数数量保持在 3 - 5 个以内。若参数过多，优先考虑使用结构体封装必需参数，或采用选项模式处理可选参数。规范命名：参数名应具有明确的描述性，能够准确传达参数的含义，避免使用含义模糊的名称。确定参数顺序：在 Go 语言中，通常将作为函数的第一个参数。常用于控制请求的生命周期，传递请求范围内的数据，将其前置有助于统一代码风格，提升可读性。选择传递方式：根据实际需求选择合适的参数传递方式。若函数需要修改传入的参数值，应使用指针传递；
2025-04-27 11:05:11
347
原创 golang不使用锁的情况下，对slice执行并发写操作，是否会有并发问题呢？
golang的slice不是线程安全的对象，那么，是否只要slice类型的对象在多线程中就需要加锁呢？
2025-03-26 13:55:04
1236
原创 诡异的服务重启原因探索
通过模拟服务器运行程序的方式，终于找到了问题所在。原因，就是我一开始思考的方向，服务器分配的资源限制导致了程序重启。事后，我们运行本地程序，通过任务管理器发现，内存也暴涨了3G左右，只是，一开始没有想到会这么消耗内存，加之Grafana的误导，使得我绕了一大圈。我做了进一步测试，通过协程并行获取15万的数据，内存消耗增长到了230M左右，这其实符合我们的预期。导致内存暴涨竟然是写Excel文件，写15万的数据，内存涨了3G左右，有点夸张。
2025-03-25 16:26:38
852
原创 寻找一个合适的并发平衡点
奇怪的是，增加连接池数量，耗时时长并没有发生改变，这个有时间再寻找背后的原因。通过实际测试，最适合是20的并发，单次查询100条，这种情况下，虽然耗时稍微长了一点，但是，没有单次查询耗时比较长的情况。没有十全十美的解决方案，世间万物都要有取舍，所以，仓央嘉措问：世间安得两全法，不负如来不负卿？都是顾了这头，丢了那头。而这就是我们的机会，要么取舍，要么极致，都有机会，人生又何尝不是这样的呢？
2025-03-25 16:25:45
813
原创 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
555
原创 ShardingSphere：压测计划及结果分析
为深入了解系统在特定使用场景下的边界能力，并为实际部署所需资源提供可靠的数据支撑，我们特此制定本压测计划。本次压测将在 100 万数据量、分表数为 8 的环境下展开，分别对 100 的并发写入以及 500 的并发查询（包含含分表键查询和不含分表键查询两种情况）进行测试。
2025-03-19 15:33:43
893
原创 ShardingSphere：java.lang.NullPointerException报错原因
数据源定义的别名是ds,在规则中引用时写成了ds1,导致数据源名称与实际规则中引用的名称不一致导致了这个报错。获取存储单元时，因名称不匹配返回。
2025-03-12 15:30:44
451
原创 ShardingSphere:基于创建时间的时间戳进行分表的场景配置
那么，当基于创建时间的时间戳进行分表时，ShardingSphere 的配置规则该如何设置呢？目前官方文档并未给出基于时间戳分表的具体案例，本文将重点介绍此场景下的配置方案。
2025-03-12 15:29:33
826
原创 recover无法捕获的panic场景
由于recover只能在defer函数中才能生效，所以，recover无法捕获panic的场景主要有如下的一些场景。
2025-03-11 11:45:53
459
原创 初探Groovy
在使用 ShardingSphere 的分表组件时，我们常常会碰到各种分表场景，比如，根据创建的时间戳进行分表。ShardingSphere的INLINE模式通过配置分片逻辑，但仅支持 Groovy 语法中的基础运算（如取模、字符串拼接）和部分内置函数（如toString()基于此，了解一下Groovy表达式。
2025-03-11 11:45:31
434
原创 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
620
原创 golang panic原理
stack结构体类型，包含lo（低地址）和hi（高地址）两个uintptr字段，描述 Goroutine 的栈内存区间[lo, hi)。初始栈大小为 2KB，可动态扩容至 1GB。m指向当前运行此 Goroutine 的内核线程（M）。调度器通过 M 将 Goroutine 映射到操作系统线程。
2025-02-19 16:39:24
400
原创 kafka消费能力压测：使用官方工具
在之前的业务场景中，我们发现Kafka的实际消费能力远低于预期。尽管我们使用了kafka-go组件并进行了相关测试。但并未能准确找出消费能力低下的原因。我们曾怀疑这可能是由我的电脑网络带宽问题或Kafka部署时的某些未知配置所导致。为了进一步确定问题的根源，我们决定对Kafka的消费能力进行压力测试。这篇文章中我们重点看一下压测的情况。
2025-02-18 15:04:42
995
原创 kafka的Docker镜像使用说明：wurstmeister/kafka
为了评估Kafka的性能，我们需要使用Kafka自带的压测工具。经过查询，我们发现Apache Kafka官方镜像中并未包含这些压测工具，但wurstmeister/kafka镜像中则包含了这些工具，因此决定采用该镜像进行安装。
2025-02-18 14:59:08
700
原创 2024年总结
我对程序开发有了不同的认识，我产生了约束大于规范的想法，有时候甚至会有点性能的牺牲，不再停留在文档的规范的约束，而是通过脚本生成代码，通过组件封装逻辑，比如，缓存组件的封装，基于cahe aside模式封装，把流程封装起来，让开发的人只关注业务逻辑，而忽略到底是先删除缓存，还是先删除持久化数据等。让我对团队建设也有了新的认识，规范化的流程有着重要的意义，虽然，有时候规范化的流程会带来时效性的损失，但是，规范化的流程带来了更可靠的代码的质量。在此，首先预祝各位，新的一年里，万事顺意，阖家欢乐！
2025-01-23 13:58:58
179
原创 单元测试在复杂业务逻辑开发中的重要性与实践
编写单元测试对于提高代码质量和开发效率具有重要意义。通过针对各个方法编写测试用例，我们可以迅速发现和修复问题，验证逻辑的正确性，并在代码重构时确保代码的稳定性。因此，我们应该在编写业务逻辑时养成良好的单元测试习惯，以更好地应对开发过程中的挑战。
2025-01-23 10:04:50
948
原创 接口鉴权方案
接口生成签名分两个逻辑，首先，对原始数据，过期时间，随机字符串组成的字符串明文进行加密，对这个密文进行加签，最后，把密文和签名编码生成最终的签名，在发送http请求时带上这个最终生成的签名。这个方案的设计思路主要是为了确保数据在传输过程中的保密性和完整性。secret通过这种设计，可以确保数据在传输过程中既不会被窃听（通过加密），也不会被篡改（通过签名验证）。同时，时间戳和随机字符串的使用也防止了重放攻击。
2025-01-16 09:22:25
397
原创 kafka-go:性能测试
在这篇文章中，由于kafka消息堆积引起的一些探索，上篇文章中遗留的问题，已经解决了消息堆积的问题，是通过打印日志的地方开启协程的方式解决了，但是，造成这个问题背后的原因还是值得探索探索。在实际测试过程中，通过pprof工具发现，这个地方context的会导致内存增长，且似乎没有下降的趋势，看着像是内存泄漏。这个问题很是令人困惑。这个问题，留待后续继续探索。今天，我们主要围绕着kafka-go这个组件探索展开。
2025-01-16 09:21:55
652
原创 kafka消费堆积问题探索
我们的商城项目用PHP写的，原本写日志方案用的是PHP的方案，但是，这个方案导致资源消耗一直降不下来，使用了20个CPU。后面考虑使用通过kafka的方案写日志，商城中把产生的日志丢到kafka中，在以go写的项目中消费kafka中的日志，并打印到控制台，最后，统一使用阿里sls抓取日志。我们kafka的分区有12个，go程序部署在k8s集群中，开启了弹性扩缩容，最多开启了8个pod进行消费，每秒产生的日志数量高峰在1500条左右，在这种情况下，依然产生了消息的堆积。
2025-01-11 11:40:17
1226
原创 golang:微服务架构下的日志追踪系统（二）
在使用Gin框架进行服务开发时，我们遇到了一个日志记录的问题。由于Gin的上下文（）实现了接口，在调用日志记录器的InfoWarnError等方法时，直接传递Gin的上下文通常不会导致编译错误。会导致我们在《》一文中定义的日志统计维度信息无法正确串联。为了解决这一问题，我们之前的解决方案是让业务方在使用日志记录器时，将Gin的上下文手动转换为。但这种方案带来了一个明显的弊端：它依赖于开发人员的主动转换，而开发人员往往会忘记进行这一步操作，直接传递Gin的上下文，从而导致日志并未按照预期格式打印。
2025-01-02 14:15:45
480
原创 golang:微服务架构下的日志追踪系统
为了把一个请求中所有的日志串联起来，我在日志中增加一个traceId的信息。》在这篇文章中，提供了第一个版本的解决方案。这个解决方案主要是解决单体服务架构下的日志串联问题。随着，我们分布式应用的发展，我们面临着需要一个能串联跨服务调用链路的日志系统。因此，我们在第一个版本上做了优化处理。主要是增加了日志的统计维度。
2025-01-02 13:51:35
1208
ASP.NET MVC 5高级编程 第5版（中文版）
2018-07-03
C#公共通用类
2018-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人