一、前言
随着业务体量扩大、架构复杂度提升，单一 Redis 锁已经无法覆盖全部场景：高吞吐弱一致、金融级强一致、顺序任务、读写混合等诉求并存。很多企业开始采用 Redis + ZooKeeper 混合锁架构 分场景使用；同时为了统一编码规范、屏蔽底层组件差异、降低业务开发成本，会基于 Redis 原生能力或 Redisson 二次封装自研统一锁 SDK。
本篇围绕两大核心方向展开：混合锁架构分层设计与落地规则、自研 SDK 整体架构、模块拆分、代码封装、兼容性处理，最后配套专业压测方案与极限调优手段，实现功能、性能、规范性三位一体。
二、Redis+ZooKeeper 混合锁架构分层设计
2.1 混合架构设计初衷
Redis 锁优势：性能高、吞吐大、延迟低 ，适配绝大多数高并发业务；短板：异步复制存在一致性风险。 ZooKeeper 锁优势：强一致、天然防死锁、公平性好；短板：性能偏弱、延迟更高、资源开销大。
混合架构核心思路：按业务一致性等级、并发量级做分层分流，各司其职，不强行用一种组件承载所有场景。
2.2 分层分流规则（生产落地标准）
第一层：高并发、弱 / 中等一致性业务 → 统一使用 Redis 锁
适用场景：商品查询、活动限流、定时任务、普通接口互斥、后台作业。 选型方案：Redisson 标准可重入锁、读写锁、联锁。 架构要求：主从 + 哨兵 / Redis Cluster，搭配幂等兜底，追求高吞吐。
第二层：强一致、低并发、顺序类业务 → 统一使用 ZK 锁
适用场景：资金对账、流程审批、顺序任务队列、分布式配置抢占、核心状态流转。 选型方案：Curator 公平锁、排他锁。 架构要求：ZK 集群独立部署，保证集群稳定性，利用其强一致性与天然公平特性。
第三层：超高一致、零容忍核心交易 → Redis 红锁 + 双重校验
适用场景：支付、退款、大额资金扣减、核心库存。 选型方案：Redis RedLock 红锁作为主锁，业务层叠加状态机 + 唯一索引双重兜底，不依赖 ZK 降低链路复杂度。
第四层：跨服务全局调度、分布式选主 → ZK 临时节点 + 锁
适用场景：集群主节点选举、定时任务单点执行、服务注册中心锁竞争。 利用 ZK 临时节点特性，节点下线自动释放锁，天然实现故障转移。
2.3 混合架构部署与访问规范
- 集群物理隔离 Redis 集群、ZK 集群独立部署，不混部服务器 / 容器，避免资源争抢相互影响。
- 客户端隔离 业务服务按需引入对应客户端，高吞吐服务仅依赖 Redis，强一致服务按需接入 ZK。
- 调用边界约束 禁止同一业务流程内同时嵌套 Redis 锁与 ZK 锁，极易引发跨组件死锁。
- 监控独立拆分 两套锁体系分开监控指标、日志、告警，便于故障定位。
2.4 混合架构优缺点总结
- 优点：兼顾性能与一致性，场景适配灵活，架构容错能力更强；
- 缺点：技术栈变复杂，学习与运维成本上升，需要团队同时掌握两套组件；