分布式锁 → 事务 → 一致性方案 追问链#

追问路径#

Q: 分布式锁有哪些实现方案？
→ Redis(SET NX EX)、ZooKeeper(临时顺序节点)、MySQL(唯一索引/排他锁)
  Q: Redis分布式锁具体怎么实现？
  → SET key uniqueValue NX EX timeout + Lua脚本原子释放(判断value匹配再删)
    Q: 锁过期了业务没执行完怎么办？
    → Redisson看门狗：默认lockWatchdogTimeout=30s，后台每10s检查续期到30s；业务完成后取消
      ├─ Q: ZooKeeper分布式锁和Redis比有什么区别？
      │  → ZK用临时顺序节点+Watcher，不用设过期时间(但会话超时锁也会被释放)，CP强一致但性能比Redis低一个数量级
      │    Q: 分布式事务怎么选方案？
      │    → 强一致：2PC(XA)；最终一致：Seata AT(自动补偿、无侵入)/TCC(侵入大)/SAGA(长事务)/事务消息(推荐)
      │      Q: TCC的三个阶段具体怎么做？
      │      → Try:预留资源(冻结库存) → Confirm:提交(扣减冻结) → Cancel:回滚(释放冻结)；需要幂等+防悬挂
      └─ Q: CAP定理怎么理解？实际系统怎么选？
         → P(分区容错)必须保证；CP(ZK/金融场景)牺牲可用性；AP(Eureka/电商场景)牺牲强一致
           Q: BASE理论和CAP什么关系？
           → BASE是CAP中AP方向的实践落地：基本可用(降级) + 软状态(中间态) + 最终一致(异步补偿)

涉及知识点#

• 分布式锁方案对比 — Redis/ZK/MySQL三种方案优劣
• Redis分布式锁 — SET NX EX + Lua释放
• Redisson分布式锁实现 — 看门狗、可重入、公平锁
• Zookeeper-ZAB协议 — ZK的一致性协议基础
• 分布式事务方案 — 各方案全景对比
• 2PC与3PC — 两阶段/三阶段提交
• TCC事务模式 — Try-Confirm-Cancel
• SAGA事务模式 — 长事务编排与补偿
• Seata框架原理 — AT/TCC/SAGA/XA四种模式
• CAP定理 — 分布式系统根本约束
• BASE理论 — 最终一致性的理论基础
• 数据一致性方案 — 强一致 vs 最终一致的选型

核心串联逻辑#

1. 锁方案选型：Redis性能最高(10万+ QPS)但有主从切换丢锁风险；ZK强一致但性能低(~万级QPS)；MySQL最简单但性能最差
2. Redisson看门狗：解决”锁过期业务未完成”——后台线程定时续期，客户端宕机则不续期自动释放
3. 分布式事务谱系：强一致(2PC/XA) → 最终一致(Seata AT → TCC → SAGA → 事务消息)，越往后一致性越弱、吞吐越高；侵入性AT最低、TCC最高
4. CAP落地：CP选ZK/etcd(金融转账)，AP选Nacos临时实例/Eureka(电商服务发现)
5. 代码示例：

   // Redisson分布式锁用法
   RLock lock = redisson.getLock("order:" + orderId);
   try {
       if (lock.tryLock(5, TimeUnit.SECONDS)) { // 等待5s；不传leaseTime才启用看门狗
           // 看门狗自动续期，业务完成后unlock取消
       }
   } finally { if (lock.isHeldByCurrentThread()) lock.unlock(); }

   java

面试回答串联#

30秒速答#

分布式锁首选Redis(SET NX EX)配合Redisson看门狗续期，ZK强一致但性能低。分布式事务要强一致用XA，Seata AT无侵入但其实是最终一致，最终一致首选事务消息。CAP中P必选，根据业务选CP或AP，BASE是AP方向的落地实践。

2分钟展开答#

分布式锁三种方案：Redis用SET key NX EX加锁+Lua脚本原子释放，性能最高达10万+ QPS，但主从切换时有丢锁风险。Redisson通过看门狗机制解决锁过期问题——默认30s过期，后台每10s续期，客户端宕机则自然超时释放。ZooKeeper用临时顺序节点实现，不用设过期时间(不过会话超时了锁一样会被释放)且CP强一致，但性能低一个数量级。分布式事务方案从强到弱：2PC/XA全局锁定性能差，Seata AT通过undo log实现自动补偿比较轻量；TCC由业务实现Try/Confirm/Cancel三阶段侵入性大但灵活；事务消息通过半消息+本地事务+回查实现最终一致性，是大多数场景的首选。CAP定理中P(分区容错)必须保证，金融场景选CP保证一致性，电商场景选AP保证可用性。BASE理论是AP方向的实践落地——基本可用(降级服务)、软状态(允许中间态)、最终一致(异步补偿)。

相关追问链#

• MySQL事务-分布式事务-CAP追问链 — 从单机事务到分布式事务的演进
• Redis缓存问题-一致性-分布式锁追问链 — Redis分布式锁的深入实现
• MQ可靠性-顺序-积压-事务消息追问链 — 事务消息是分布式事务的最终一致方案