- 博客(233)
- 资源 (5)
- 收藏
- 关注
RSS订阅原创 企业知识库解决方案调研文档（模板）
企业知识库解决方案调研摘要 为构建安全高效的企业SOP知识库，调研对比了四类方案： SaaS方案（如HelpLook）：部署快但数据在第三方云端，隔离性低； 二开/私有化方案（如Confluence+AI）：数据本地化，需开发支持； 开源方案（如FastGPT）：自主可控但技术门槛高； 完全自研：安全性最优但研发成本极高。 核心权衡：数据隔离（安全）与实施成本。建议短期试点B/C类方案验证效果，长期视需求逐步转向自研或开源架构。优先保障机密数据安全，同时平衡开发资源与效率。
2025-12-23 11:15:48
302
原创 基于券类型路由的渐进式重构：函数式选项模式与管道模式的完美结合
本文介绍了电商系统中优惠券订单处理的重构实践。原有CreateCouponOrder函数膨胀至200+行，存在代码臃肿、难以测试和扩展等问题。重构采用函数式选项模式与管道模式相结合的策略，通过按券类型路由实现双逻辑并存：高德券走新管道逻辑，其他券保持原有处理。路由层CreateCouponOrderWithRoute识别券类型并分发请求，同时通过选项函数传递已查询数据避免重复操作。原有函数改造后返回选项函数，支持数据复用。管道模式处理高德券时，通过上下文结构传递状态，各步骤实现独立接口，确保业务连续性和风险
2025-12-17 16:54:39
1055
原创 解耦与提效：券订单系统重构全方案（策略+工厂+管道）
本文针对餐饮O2O系统中订单与券管理耦合度过高的问题，提出了一套系统重构方案。原有系统存在逻辑强耦合、流程混乱、事务一致性难保障和扩展性差四大痛点。通过采用策略模式+管道模式+事务策略的混合架构，实现了业务解耦和流程优化。方案包含清晰的分层设计（API/Service/Domain/Model/Enum层）、核心设计模式组合（策略模式封装券逻辑、管道模式编排流程）以及完整的基础定义实现（订单状态、券类型等枚举和请求响应结构体）。重构后系统显著提升了可维护性和扩展性，为多平台券接入提供了标准化解决方案。
2025-11-27 18:10:22
613
原创 基于GMP模型分而治之思想：实现Slice无锁化并发写操作的实践
本文探讨了Go语言中高并发场景下的Slice无锁化写入方案。通过借鉴GMP调度模型的"分而治之"思想，为每个goroutine预分配独立的数组写入位置，避免了传统加锁方式带来的性能瓶颈。方案具有完全无锁、内存安全、高性能等特点，适用于批量数据获取和并行计算等场景。基准测试显示，相比传统加锁方式，无锁化方案性能提升显著。该技术实现简单却效果显著，是解决并发写操作的优雅方案。
2025-11-19 10:19:21
1078
原创 高效批量数据写入：PostgreSQL COPY 协议实战指南
PostgreSQL COPY协议批量数据写入实战指南 摘要：针对PostgreSQL批量写入大量数据时遇到的参数数量限制问题，本文介绍了使用COPY协议的高效解决方案。COPY协议采用二进制格式直接传输数据，避免了SQL解析开销，可实现百万级数据无分片写入，同时保持事务安全和低内存占用。文章详细讲解了COPY协议原理，并提供了Go语言实现代码和完整测试用例，包括数据验证、事务管理和性能对比。相比传统分批插入，COPY协议在20000条数据测试中展现出显著性能优势，具备更低的内存占用和更少的网络请求次数。
2025-11-19 09:04:35
650
原创 分布式事务：可靠事件队列、TCC和SAGAS事务
本文探讨了分布式系统中解决事务一致性的三种方案：可靠事件队列、TCC和SAGA事务。可靠事件队列通过消息中间件实现最终一致性；TCC采用预留资源的方式保证隔离性，但实现复杂；SAGA更适合外部系统场景，将大事务拆分为可补偿的子事务。特别指出SAGA与事件溯源(ES)存在深刻的内在联系：SAGA的事务步骤可建模为不可变事件，其补偿逻辑与ES的"回溯"机制同构。这种架构融合为复杂分布式事务提供了健壮、透明的解决方案，尤其在涉及外部系统时展现出独特优势。
2025-11-12 16:33:23
935
原创 企业微信消息推送系统设计：基于ES(事件溯源思想)解耦规则与任务架构
本文介绍了一种基于事件溯源(Event Sourcing)思想设计的企业微信消息推送系统架构。系统通过将规则与执行任务解耦，采用"任务只增不改"原则，有效解决了传统方案中状态管理复杂、并发冲突等问题。核心设计包含规则管理器、规则调度器和任务调度器三大组件，通过规则表、任务表和发送日志表实现消息推送全流程管理。系统支持立即发送、定时发送和周期发送三种模式，采用乐观并发控制降低分布式锁复杂度，提升了系统的可靠性和可扩展性。数据库表结构中，任务表承担了"事件存储"角色，完整
2025-11-12 13:59:04
857
原创 优雅地Mock时间：gomonkey实现time.Now()替换的原理与实践
文章摘要：gomonkey库通过函数地址替换实现在单元测试中对time.Now()的无侵入Mock，解决了时间依赖问题。其核心原理是修改函数机器指令，将标准库函数跳转到自定义mock函数。具体实现包括：构建跳转指令、备份原指令、修改机器码。该方案无需改动业务代码，使测试更加稳定可靠，适用于需要控制时间的测试场景。
2025-11-11 14:37:32
174
原创 架构权衡与实践：基于“约束大于规范”的缓存组件封装
文章摘要：本文介绍了一个基于业务需求封装的Redis缓存组件，重点讨论了延时双删机制的应用场景与实现细节。该机制通过两次删除操作（立即删除+延迟删除）应对主从同步延迟导致的数据一致性问题。组件采用缓存穿透防护（设置特殊占位符）、并发控制（singleflight）、指数退避重试等策略，并支持随机化过期时间避免缓存雪崩。代码示例展示了双删策略、错误处理和缓存操作的核心实现，同时探讨了架构设计中复杂度与可靠性的平衡考量。
2025-10-24 16:56:58
378
原创 从golang从GMP模型到分布式架构：无锁化思想的高并发实践
摘要：本文探讨如何借鉴Go语言GMP模型的无锁化思想应对高并发场景。核心思想是通过数据分片和本地缓存将全局竞争转化为局部操作，如将库存分散到多个数据库实例或应用本地内存。针对分布式环境下的扩缩容和故障恢复问题，提出两种方案：中心调度器模式和基于分布式缓存的共享池模式。最终通过分层设计实现高效与可靠的统一，体现了"分而治之"的并发处理智慧。（149字）
2025-10-24 16:17:00
1110
原创 K8s日志查看与程序更新验证指南
本文探讨了在Kubernetes集群中查看Go程序日志和验证服务更新的问题。针对控制台输出不可见的问题，指出应该使用kubectl logs命令而非直接进入容器shell查看。对于验证服务更新，建议通过检查Pod镜像标签、强制重启Deployment、对比程序版本信息等方式确认。文章提供了具体命令示例和排查思路，帮助开发者解决K8s环境下的日志查看和版本验证问题。
2025-08-20 08:48:44
772
原创 Kubernetes 负载均衡现象解析：为何同一批次请求集中于单个 Pod
在Windows本地Kubernetes集群中，通过Traefik和Kubernetes Service实现负载均衡时，发现循环请求会集中路由到同一Pod，间隔后才切换。这主要是由于Kubernetes Service默认启用会话亲和性和HTTP长连接复用机制：1）同一TCP连接内的请求会被固定到同一Pod；2）Traefik仅转发到Service的NodePort，实际负载均衡由Kubernetes Service完成。解决方案需调整会话亲和性或强制新建连接来实现请求均匀分布。
2025-08-20 08:44:08
698
原创 Kubernetes 常用命令
本文介绍了在Windows环境下使用Kind创建本地Kubernetes集群并集成Traefik进行负载均衡后，如何进入集群容器内部的操作方法。通过kubectl命令获取服务对应Pod名称，使用kubectl exec进入容器控制台进行调试，并提供了常用Kubernetes命令，包括查看集群信息、节点状态、Pod详情和日志等。文章详细说明了如何通过标签筛选Pod、进入容器内部的操作步骤及注意事项，为开发者提供了实用的集群管理和问题排查指南。
2025-08-19 09:42:04
870
原创 在 Windows 上使用 Kind 创建本地 Kubernetes 集群并集成Traefik 进行负载均衡
本文记录了在Windows环境下使用Kind创建本地Kubernetes集群并部署Go服务的完整流程。通过Go1.17环境安装Kind工具，创建集群后，独立运行Traefik作为Ingress控制器。详细说明了构建Go服务镜像、加载到Kind集群、配置Deployment/Service/Ingress等步骤，并解决了Traefik独立运行与集群服务的连接问题。最终通过配置共享网络和动态路由，实现了外部访问(hello.local)的负载均衡，验证了流量分发到多个Pod的功能。
2025-08-19 09:03:30
1197
1
原创 评论父子级关系的高效删除方案：避免递归
本文提出了一种基于路径存储的高效多级评论删除方案。通过在创建评论时记录完整的评论链路路径（如"1,2,3,4"），取代传统递归删除方式。当删除某条评论时，只需使用LIKE条件匹配该路径前缀即可批量标记删除（软删除）目标评论及其所有子评论。该方案显著提升了删除效率，避免了递归查询的性能损耗，同时采用软删除机制保证数据完整性。方案实现包括创建时生成路径、删除时批量更新等核心逻辑，适用于层级较深或数据量大的评论系统场景，兼具性能和可维护性优势。
2025-08-15 08:48:38
337
原创 gorm:全局禁用默认带有deleted_at IS NULL查询条件
GORM默认启用软删除功能，对含deleted_at字段的模型查询会自动添加deleted_at IS NULL条件。本文解释了该机制的原理，并提供了三种解决方案：1）全局取消软删除过滤，通过注册查询钩子强制所有查询返回全部数据；2）单次查询使用Unscoped()方法；3）模型层面移除软删除特性。这些方法可帮助开发者在需要时灵活控制软删除行为。
2025-08-15 08:45:32
499
原创 营业数据多维度统计系统设计：解决跨期去重与精准分析难题
摘要：为解决多维度统计分析中的性能瓶颈和跨期数据去重问题，本文提出基于MySQL的预计算方案。采用星型/雪花模型构建数据体系，通过ETL四层架构（ODS→DWD→DWS→ADS）实现数据分层加工。方案创新性使用bitmap技术处理跨期去重，存储用户ID集合并通过位运算实现高效聚合。针对客单价、留存率等核心指标设计专门计算逻辑，建立会员消费时间序列中间表支持跨周期分析。性能测试显示，bitmap并集计算平均耗时469ms，内存消耗30MB，满足实时查询需求。该方案在保证查询效率的同时，解决了传统预计算方法面临
2025-07-17 14:46:16
1264
原创 巧用 Golang 函数特性实现单元测试中的数据库操作 Mock
本文介绍了一种基于Golang函数特性的Mock方案，用于解决单元测试中数据库依赖问题。通过将数据库操作封装为函数变量，在测试时重新赋值这些变量来模拟数据库行为，实现测试与数据库的解耦。该方法利用Golang函数作为"一等公民"的特性，无需引入复杂框架即可实现简洁高效的Mock功能。示例代码展示了如何模拟数据库查询结果和并发场景测试。该方案优势包括：消除数据库依赖、简化测试数据准备、提升测试效率、便于模拟特殊场景，同时保持代码简洁性，特别适合业务逻辑复杂、数据库操作频繁的项目场景。
2025-07-17 14:41:13
628
原创 docker设置镜像加速
在使用 Docker 拉取镜像时，我首先按照官方指引尝试配置阿里云镜像加速器。然而，多次操作后仍无法正常使用，怀疑是个人账号没有权限拉取镜像，但经过多轮权限检查与配置核对，始终未能定位问题根源，这一步的尝试最终以失败告终。为突破镜像拉取的瓶颈，我转向网络上的第三方解决方案，筛选了多个公开的镜像加速器资源后，选择了其中一个进行配置修改。具体操作包括更新 Docker 的 daemon.json 配置文件，添加新的加速器地址并重启 Docker 服务。完成这些步骤后，再次尝试拉取镜像。
2025-07-11 08:55:30
563
原创 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
1130
原创 上线文档模板
变更项变更内容简述变更影响范围变更风险评估[配置文件路径1][如修改数据库连接地址][影响用户认证模块][低风险，验证后生效][配置文件路径2][如调整日志级别][影响系统日志输出][中风险，可能丢失部分调试信息]变更类型变更对象变更内容简述变更影响范围回滚方案表结构变更[表名1][如新增字段age][用户信息模块][执行SQL脚本回滚新增字段]数据迁移[表名2][如历史数据格式转换][订单统计模块][备份原数据，异常时恢复]脚本类型脚本路径/名称。
2025-07-09 08:37:33
872
原创 技术方案设计模板
示例：用户提交积分兑换请求→后端校验用户积分是否充足→校验商品库存→创建兑换订单→扣减积分→通知物流系统发货。1.重点描述需求的边界，比如，由于某些原因，某些功能这一期无法实现或者降级实现。2.如果是修改的逻辑，需要重点描述兼容性等问题，描述改动前后的影响。比如：积分扣减的原子性（模拟并发场景，避免超扣 / 漏扣）用文字或流程图描述需处理的核心流程（最好附上流程图）：。接口测试整个业务流程。
2025-07-09 08:35:03
539
原创 多维度缓存一致性挑战：Cache-Aside模式下的解决方案精要
针对多维度缓存场景下缓存删除遗漏的问题，提出了四种解决方案：1）集中式缓存键管理器统一管理实体缓存键；2）缓存标签机制通过标签批量删除关联键；3）事件驱动解耦业务与缓存清理；4）测试与监控机制兜底保障。核心思路是将多维度缓存关联关系从分散转为集中管理，建议根据场景特点选择方案：键管理器适合简单场景，标签机制灵活性高，事件驱动适合分布式系统，测试监控作为通用兜底方案。这些方案可有效解决缓存不一致问题，降低开发维护成本。
2025-07-08 11:43:26
1100
原创 深度排查 benchstat 无输出问题：编码格式引发的 “隐形故障”
本文分析了Golang benchstat工具无输出的问题。通过源码分析发现benchstat严格依赖UTF-8编码解析基准测试文件，当文件采用GBK等非UTF-8编码时，会触发utf8.RuneError导致解析终止。验证测试表明，将文件转换为UTF-8无BOM编码后问题解决。建议规范基准测试文件的生成流程，确保统一使用UTF-8编码保存，以避免此类"隐形约束"导致的工具异常。
2025-07-04 08:32:44
525
原创 使用Process Monitor定位benchstat工具执行过程
摘要：在Windows11系统Go1.21.0环境下使用benchstat工具比较基准测试结果时遇到问题。通过ProcessMonitor工具捕获分析，确认benchstat已成功读取目标文件(20_runs_bench.txt)。使用官方示例文件(D:\Go\pkg\mod\golang.org\x\perf@v0.0.0-20250605212013-b481878a17be\benchproc\testdata)测试成功，证明工具本身运行正常。
2025-07-02 16:47:28
483
原创 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
852
原创 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
342
原创 缓存和数据库一致性问题
直接更新缓存方案虽能减少缓存穿透风险并确保数据一致性，但仍存在主从延迟和并发一致性问题。更优方案是采用Cache-Aside模式（更新数据库后删除缓存），配合SingleFlight解决缓存穿透，并通过延迟双删或Binlog监听应对主从延迟。该模式在并发场景下数据不一致概率极低，建议封装缓存组件隐藏底层实现，仅暴露数据库操作接口。
2025-06-27 11:18:01
1228
原创 基于开闭原则优化数据库查询语句拼接方法
这两种方案都遵循了开闭原则，使得代码在添加新的查询条件时更加灵活，同时减少了修改现有代码的风险。策略模式适合条件逻辑复杂、需要多维度扩展或复用的场景，通过接口化设计提升代码规范性。函数切片则以更轻量的方式实现条件解耦，适合快速开发或条件相对固定的场景。无论选择哪种方案，核心目标都是将查询条件的 “修改” 操作转化为 “扩展” 操作 —— 新增条件时无需触碰原有逻辑，从架构层面降低人为失误导致的风险。
2025-04-29 11:52:54
560
原创 误在非开发分支上开发解决方案
在新功能开发时，通常会创建独立的开发分支（如feature/new-feature），完成后合并到联调分支（如dev）。但有时会忘记切回开发分支，直接在dev分支上继续开发并提交代码，直到推送前才发现分支错误。此时若尚未执行git push，可通过以下步骤修复，避免污染dev分支。
2025-04-29 11:51:15
597
原创 ShardingSphere-Proxy数据隔离方案：不同用户操作不同的数据库
在分布式数据库架构中，实现多项目间的数据隔离是核心安全需求。不同业务模块需仅访问其专属数据库实例中的表结构，例如用户中心仅操作用户相关表，图文社区仅访问内容相关表。
2025-04-27 11:06:01
1156
原创 优化 Go 语言函数传参设计，提升代码可读性与可维护性
控制参数数量：尽量将参数数量保持在 3 - 5 个以内。若参数过多，优先考虑使用结构体封装必需参数，或采用选项模式处理可选参数。规范命名：参数名应具有明确的描述性，能够准确传达参数的含义，避免使用含义模糊的名称。确定参数顺序：在 Go 语言中，通常将作为函数的第一个参数。常用于控制请求的生命周期，传递请求范围内的数据，将其前置有助于统一代码风格，提升可读性。选择传递方式：根据实际需求选择合适的参数传递方式。若函数需要修改传入的参数值，应使用指针传递；
2025-04-27 11:05:11
404
原创 golang不使用锁的情况下，对slice执行并发写操作，是否会有并发问题呢？
golang的slice不是线程安全的对象，那么，是否只要slice类型的对象在多线程中就需要加锁呢？
2025-03-26 13:55:04
1395
原创 诡异的服务重启原因探索
通过模拟服务器运行程序的方式，终于找到了问题所在。原因，就是我一开始思考的方向，服务器分配的资源限制导致了程序重启。事后，我们运行本地程序，通过任务管理器发现，内存也暴涨了3G左右，只是，一开始没有想到会这么消耗内存，加之Grafana的误导，使得我绕了一大圈。我做了进一步测试，通过协程并行获取15万的数据，内存消耗增长到了230M左右，这其实符合我们的预期。导致内存暴涨竟然是写Excel文件，写15万的数据，内存涨了3G左右，有点夸张。
2025-03-25 16:26:38
897
原创 寻找一个合适的并发平衡点
奇怪的是，增加连接池数量，耗时时长并没有发生改变，这个有时间再寻找背后的原因。通过实际测试，最适合是20的并发，单次查询100条，这种情况下，虽然耗时稍微长了一点，但是，没有单次查询耗时比较长的情况。没有十全十美的解决方案，世间万物都要有取舍，所以，仓央嘉措问：世间安得两全法，不负如来不负卿？都是顾了这头，丢了那头。而这就是我们的机会，要么取舍，要么极致，都有机会，人生又何尝不是这样的呢？
2025-03-25 16:25:45
843
原创 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
728
原创 ShardingSphere：压测计划及结果分析
为深入了解系统在特定使用场景下的边界能力，并为实际部署所需资源提供可靠的数据支撑，我们特此制定本压测计划。本次压测将在 100 万数据量、分表数为 8 的环境下展开，分别对 100 的并发写入以及 500 的并发查询（包含含分表键查询和不含分表键查询两种情况）进行测试。
2025-03-19 15:33:43
922
原创 ShardingSphere：java.lang.NullPointerException报错原因
数据源定义的别名是ds,在规则中引用时写成了ds1,导致数据源名称与实际规则中引用的名称不一致导致了这个报错。获取存储单元时，因名称不匹配返回。
2025-03-12 15:30:44
813
ASP.NET MVC 5高级编程 第5版（中文版）
2018-07-03
C#公共通用类
2018-09-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人