个人网站

前面讲了分布式锁的三种实现，这道题是面试高频追问——Redis 和 ZK 到底谁更好？面试官想听的可不是"Redis 更快"或"ZK 更稳"这种结论，他想听的是：你能不能从一致性模型、锁安全性、性能三个维度做深入对比，并给出场景化建议？

先说结论

维度	Redis	ZooKeeper
一致性模型	AP（最终一致）	CP（强一致）
锁安全性	可能不安全（极端情况）	安全（临时节点保证）
性能	极高（内存操作）	中等（磁盘 + 网络共识）
公平性	非公平（需改造）	公平（顺序节点）
可重入	需自己实现（Redisson支持）	需自己实现（Curator支持）
自动释放	过期时间（可能不准）	会话断开自动删除
运维成本	低	高（需维护 ZK 集群）

|一句话记住：Redis锁像"租房子"——快但租约可能出问题；ZK锁像"户籍登记"——慢但可靠"

核心差异：一致性模型

Redis 是 AP 模型：

主从同步是异步的：
客户端A加锁 → Master 写入成功 → 返回OK
此时 Master 挂了 → 锁数据还没同步到 Slave
Slave 提升为新 Master → 没有锁数据 👈
客户端B也能加锁 → 两个客户端同时持锁！

ZooKeeper 是 CP 模型：

写入必须过半节点确认：
客户端A加锁 → Leader 创建临时节点 → 过半Follower确认 → 返回OK
此时 Leader 挂了 → 新选举的Leader一定有锁数据（ZXID最大）
锁数据不会丢 👈

这就是 Martin Kleppmann 质疑 RedLock 的核心论点——Redis 的主从异步复制在故障切换时可能丢锁。

锁安全性对比

Redis 锁的三个风险

风险1：锁过期但业务没完

// 线程A加了30秒锁，但业务执行了40秒
// 第30秒锁自动释放，线程B获得锁 👈
// 线程A和B同时持锁！

解决：Redisson 看门狗续期。

风险2：误删别人的锁

// 线程A的锁过期释放
// 线程B获得锁
// 线程A执行完，把线程B的锁删了 👈
// 线程C也获得锁 → B和C同时持锁！

解决：Lua 脚本校验 value。

风险3：时钟跳变

// 服务器A时间快了5秒
// 30秒过期 → 实际只过了25秒就认为过期 👈
// 或者服务器时间倒退 → 锁永远不会过期

ZooKeeper 锁没有这些问题

• 不会过期：临时节点跟会话绑定，不是跟时间绑定
• 不会误删：每个客户端只删自己的节点
• 不受时钟影响：不依赖系统时间

性能对比

操作	Redis	ZooKeeper
加锁	~0.1ms	~3-5ms
解锁	~0.1ms	~3-5ms
吞吐量	10万+/秒	1万+/秒

Redis 快是因为纯内存操作，ZK 慢是因为每次写都要过半确认 + 磁盘持久化。

但在大多数业务场景下，3-5ms 的锁开销完全可以接受。只有极端高并发场景（QPS>5万）才有必要选 Redis。

怎么选

场景	推荐	原因
已有 Redis 没有 ZK	Redis	不用加新组件
强一致性要求（如金融）	ZK	不怕锁丢失
极高并发短任务	Redis	性能碾压
锁持有时间长	ZK	临时节点不依赖过期时间
需要公平锁	ZK	顺序节点天然公平
运维能力有限	Redis	ZK 集群运维复杂

Redis vs ZK 分布式锁全景

一致性
├── Redis —— AP，异步复制，故障可能丢锁
└── ZK —— CP，过半确认，故障不丢锁

安全性
├── Redis —— 三大风险（过期/误删/时钟）
│         └── Redisson逐一解决
└── ZK —— 无此风险（临时节点+会话）

性能
├── Redis —— 0.1ms级，10万+TPS
└── ZK —— 3-5ms级，1万+TPS

选型
├── 已有Redis → Redis + Redisson
├── 金融/强一致 → ZK + Curator
├── 极端高并发 → Redis
└── 长持有/公平锁 → ZK

口诀：Redis快但有风险，ZK稳但性能一般；
      AP可能丢锁数据，CP保证不丢失；
      高并发短任务选Redis，强一致长任务选ZK；
      大多数场景Redis够用，金融场景上ZK

回答技巧与点评

标准回答：Redis 锁和 ZK 锁的核心差异在一致性模型：Redis 是 AP（异步复制，故障切换可能丢锁），ZK 是 CP（过半确认，不丢锁）。Redis 有锁过期误删、时钟跳变三大风险，Redisson 逐一解决但非完美；ZK 用临时节点无此问题。性能上 Redis 远超 ZK（0.1ms vs 3-5ms）。选型：已有 Redis 或高并发场景选 Redis + Redisson，金融或强一致场景选 ZK + Curator。

加分回答

1. Martin Kleppmann vs Antirez 之争：Martin 质疑 RedLock 在时钟跳变和 GC 停顿下不安全，Antirez 回辩说 RedLock 的多节点设计已经考虑了这些问题。这场争论没有标准答案，核心是你要理解风险并选择合适方案
2. 实际生产建议：大多数互联网公司用 Redis + Redisson 就够了，因为极端情况（主从切换丢锁）概率极低。但如果你在做支付系统，那 ZK 或 etcd 更安心
3. etcd 的折中：基于 Raft 协议（类似 ZAB），保证强一致，同时性能比 ZK 好（Go 编写，更轻量），是 ZK 的现代替代品。Kubernetes 就用 etcd 做分布式锁

面试官点评

这道题考的是你的 技术选型能力。最忌讳的回答是"Redis 更好"或"ZK 更好"——面试官想听的是 对比维度和场景匹配。能从一致性模型讲起，说出 Redis 的三大风险和 ZK 的优势，再给出场景化建议，就是高分回答。

原文阅读

---

内容有帮助？点赞、收藏、关注三连！评论区等你 💪