从 CAP 角度解释 Redis 和 Zookeeper 锁架构¶
一、CAP 回顾¶
- C 一致性：所有节点看到相同数据。
- A 可用性：每个请求都有响应。
- P 分区容忍：网络分区时还能运行。
分布式系统只能三选二。
二、Redis 锁：AP¶
Redis 主从¶
- 异步复制。
- 主节点挂了，从节点提升，锁可能丢。
- 牺牲一致性换可用性。
RedLock¶
向 N 个独立节点加锁，多数成功。
- 提高了一致性概率。
- 但还是 AP：网络分区时，少数派节点仍能响应加锁请求。
特点¶
- 高可用（任何节点可用就能加锁）。
- 弱一致（极端情况可能两个客户端同时持有）。
三、Zookeeper 锁：CP¶
ZAB 协议¶
- Zookeeper 用 ZAB，过半节点写成功才返回。
- Leader 挂了，选主期间不可用。
临时节点 + Watcher¶
加锁：
1. 在 /locks/lock 下创建临时顺序节点。
2. 判断自己是不是最小的。
3. 不是，watch 前一个节点。
释放： - 客户端挂了，临时节点自动删除。 - watcher 通知下一个节点。
特点¶
- 强一致（过半写成功）。
- 主从切换期间不可用（CP）。
- 锁不会丢（临时节点会话结束自动清）。
四、对比¶
| Redis 锁 | Zookeeper 锁 | |
|---|---|---|
| CAP | AP | CP |
| 一致性 | 弱 | 强 |
| 可用性 | 高 | 中（选主期间不可用） |
| 性能 | 高 | 中 |
| 故障 | 可能丢锁 | 不丢锁 |
| 实现 | SET NX | 临时节点 + Watcher |
五、怎么选¶
- 性能优先，能容忍小概率失效：Redis。
- 正确性优先，不能丢锁：Zookeeper / etcd。
- 金融、库存、分布式事务：ZK。
- 业务、缓存、限流：Redis。
面试要点
Redis 是 AP，Zookeeper 是 CP。不是谁好谁坏，是取舍。