分布式锁的实现，选Redis还是ZooKeeper？
一、问题场景：为什么测试工程师需要关注分布式锁？
在分布式系统中，库存超卖、定时任务重复执行、数据覆盖等典型缺陷，往往源于分布式锁失效。例如：
测试环境中，两个服务节点同时判定库存为1并完成扣减
定时任务在集群多节点重复触发导致数据混乱
这些场景的底层根源，正是分布式锁的互斥性或可靠性不足。
二、核心机制对比：Redis与ZooKeeper的实现原理
（1）Redis分布式锁
实现方式
# 原子化加锁（SETNX + EXPIRE 二合一） SET lock_key unique_id NX PX 30000 # 解锁Lua脚本（校验唯一ID防误删） if redis.call("get",KEYS) == ARGV then return redis.call("del",KEYS) end关键特性
AP模型优先：高可用但弱一致性（主从切换可能丢锁）
看门狗机制：Redisson客户端自动续期避免业务未完成锁过期
（2）ZooKeeper分布式锁
实现方式
graph LR A[创建临时有序节点] --> B[获取/lock下所有子节点] B --> C{当前节点是否最小？} C -- 是 --> D[获得锁] C -- 否 --> E[监听前序节点删除事件] E --> D关键特性
CP模型保障：强一致性（ZAB协议）
临时节点：会话断开自动释放锁（防死锁）
顺序监听：避免"惊群效应"
三、测试评估维度：可靠性、性能与可观测性
（1）可靠性验证清单
故障场景 | Redis表现 | ZooKeeper表现 |
|---|---|---|
节点宕机 | 依赖RedLock多实例部署 | 临时节点自动释放 |
网络分区 | 可能双写（脑裂） | 少数分区停止服务（CP保证） |
GC停顿导致超时 | 锁过期被抢占（需看门狗） | 会话超时释放（默认60s） |
（2）性能压测数据参考
| 方案 | 平均耗时 | QPS（单节点） | 集群扩展性 | |------------|----------|---------------|------------| | Redis | 0.8ms | 12,000+ | ★★★★☆ | | ZooKeeper | 5ms | 2,000 | ★★★☆☆ |注：Redis性能优势明显，适合高频短事务场景
（3）可观测性对比
Redis锁：
痛点：锁状态无实时监控，依赖日志回溯
方案：通过
redis-cli --hotkeys间接分析
ZooKeeper锁：
优势：
zkCli实时查看节点状态，监听事件可追踪工具：ZooInspector可视化节点树
四、测试工程师的选型决策树
是否要求100%强一致性？ ├── 是 → 选择ZooKeeper（金融/交易系统） └── 否 → 进入下一层判断 并发量是否超过5000QPS？ ├── 是 → 选择Redis + 补偿机制（如：异步对账） └── 否 → 根据运维成本选择（Redis部署更简单）五、典型测试用例设计
场景1：Redis主从切换锁丢失
步骤：
线程A在Master加锁成功
触发主从切换（模拟Master宕机）
线程B在新Master加锁成功
预期：线程A操作应中断并回滚
场景2：ZooKeeper会话超时
步骤：
线程A持有锁后主动断开网络
等待会话超时（默认60s）
验证线程B能否自动获得锁
预期：锁释放后B立即接管
六、结论：没有银弹，只有场景适配
选择Redis当：
系统容忍极低概率锁失效（如：秒杀允许少卖）
性能瓶颈优先于绝对一致性
选择ZooKeeper当：
锁失效会导致资金损失或安全事件
业务逻辑执行时间不可预测（避免锁过期设置难题）
测试建议：在混沌工程中注入网络延迟、节点故障，验证锁的恢复能力。