CAP → Raft → ZAB → 选主与脑裂 追问链#

追问路径#

Q: 分布式系统为什么需要共识算法？
→ 多副本要对"数据/顺序/谁是主"达成一致,在节点宕机和网络分区下仍保持数据一致——这是CP系统的核心
  Q: Raft是怎么工作的？
  → 把共识拆成三块:Leader选举 + 日志复制 + 安全性;任期(term)单调递增,任一时刻最多一个Leader
    Q: Raft的Leader选举过程？
    → Follower超时未收到心跳→变Candidate自增term发起投票→获多数票(N/2+1)当选→定期心跳维持权威
      ├─ Q: Raft怎么保证日志一致？
      │  → Leader接收写请求追加日志→复制到多数节点才commit→应用到状态机;日志匹配+只投给日志更新的候选人保证安全
      │    Q: 为什么必须多数派(quorum)？为什么集群推荐奇数节点？
      │    → 多数派保证任意两次多数有交集→不会选出两个Leader;奇数节点容错性价比高(3节点容1、5容2,4节点也只容1)
      │      Q: 网络分区时Raft会脑裂吗？
      │      → 不会双主写:少数派分区选不出Leader(凑不齐多数)无法提交,只有多数派分区能继续服务,分区恢复后少数派回滚未提交日志
      │        Q: ZAB和Raft有什么区别？
      │        → ZAB是ZooKeeper的协议,思想类似(主+多数派);区别在ZAB有崩溃恢复阶段、用zxid(epoch+counter)、写后广播
      └─ Q: ZooKeeper常用来做什么？为什么适合？
         → 分布式锁/选主/配置中心/服务注册;因为它CP强一致+顺序节点+Watch通知,适合元数据这类一致性敏感场景
           Q: ZK做分布式锁比Redis好在哪？
           → 临时顺序节点天然防死锁(会话断自动删)、无需续期、Watch前驱节点避免惊群;但性能比Redis低一个数量级
             Q: 注册中心选CP还是AP？Eureka和Nacos怎么选？
             → 服务发现更看重可用性常选AP(Eureka/Nacos AP模式):分区时返回旧列表也比不可用强;配置/选主选CP

涉及知识点#

• CAP定理 — 一致性与可用性的根本取舍
• Raft协议 — 选举/日志复制/安全性三要素
• Zookeeper-ZAB协议 — ZAB崩溃恢复与原子广播
• BASE理论 — AP方向的最终一致实践
• 数据一致性方案 — 强一致与最终一致选型
• 一致性哈希 — 分布式数据分片与负载
• 分布式锁方案对比 — ZK锁 vs Redis锁
• 负载均衡算法 — 多节点流量分发

核心串联逻辑#

1. 共识的目标：在宕机和网络分区下让多副本对数据顺序和Leader达成一致,这是CP系统(ZK/etcd)的根基
2. Raft三要素：Leader选举(任期+多数票)、日志复制(多数commit才生效)、安全性(只投日志更新者)
3. 多数派防脑裂：任意两个多数派必有交集→不可能同时存在两个能提交的Leader;少数派分区无法服务,恢复后回滚
4. 奇数节点：3节点容1故障、5节点容2,4节点也只容1故障所以偶数不划算
5. ZAB vs Raft：思想相通(主+多数派),ZAB多了崩溃恢复阶段、用zxid保证全序广播,是ZooKeeper的底座
6. 代码示例：

   // Raft选举多数派门槛
   majority = N/2 + 1     // 3节点→2票当选,5节点→3票
   // ZK zxid结构(64位): 高32位epoch(任期/朝代) + 低32位counter(事务计数)
   //  epoch变化代表换主,counter保证单主内事务全序

   plaintext

面试回答串联#

30秒速答#

“共识算法解决多副本在宕机和分区下的数据一致,是CP系统的核心。Raft分选举、日志复制、安全性三块,任期单调递增、靠多数派N/2+1选主和提交日志。多数派保证不会脑裂双主——少数派分区凑不齐多数无法提交。ZAB是ZooKeeper的协议思想类似但多了崩溃恢复和zxid全序。ZK适合做锁、选主、配置这类CP场景,注册中心更常用AP。“

2分钟展开答#

“分布式系统需要共识算法是因为多个副本要对数据、操作顺序、谁是主节点达成一致,而且要在节点宕机和网络分区下依然保持一致,这是CP系统的核心诉求。Raft把共识拆成三部分:Leader选举、日志复制、安全性。每个任期term单调递增,任一时刻最多一个Leader。选举是Follower超时没收到心跳就变Candidate、自增term发起投票,拿到多数票N/2+1就当选,然后定期发心跳维持权威。日志复制是Leader接收写请求追加日志、复制到多数节点才commit再应用到状态机,靠日志匹配和’只投给日志比自己新的候选人’保证安全性。为什么必须多数派?因为任意两个多数派一定有交集,这就保证不可能同时选出两个能提交的Leader,所以网络分区时不会脑裂双写——少数派那边凑不齐多数选不出Leader也无法提交,只有多数派能继续服务,分区恢复后少数派回滚未提交的日志。集群推荐奇数节点是因为3节点容1故障、5节点容2,而4节点也只能容1,偶数不划算。ZAB是ZooKeeper的协议,思想和Raft相通都是主加多数派,区别是ZAB有专门的崩溃恢复阶段、用zxid(高32位epoch加低32位计数)保证全序广播。ZooKeeper因为CP强一致加顺序节点加Watch通知,适合做分布式锁、选主、配置中心,做锁比Redis好在临时顺序节点天然防死锁、不用续期、Watch前驱节点避免惊群,但性能低一个数量级。注册中心反而更看重可用性,所以Eureka和Nacos的AP模式更常用,分区时返回旧服务列表也比整个不可用强。“

相关追问链#

• MySQL事务-分布式事务-CAP追问链 — CAP在分布式事务中的体现
• 分布式锁-事务-一致性方案追问链 — ZK锁与Redis锁的对比
• Redis数据结构-单线程-集群追问链 — 哨兵选主用Raft、Cluster的Gossip
• 微服务注册-熔断-限流-链路追问链 — 注册中心的CP/AP取舍