分布式系统中的Raft一致性算法

题目描述：
Raft是一种用于管理复制日志的一致性算法，旨在替代Paxos并更易于理解。面试中常要求解释Raft的核心机制、如何保证一致性，以及对比Paxos的优缺点。

解题过程：

1. Raft的设计目标

   • Raft通过分解问题（领导选举、日志复制、安全性）和强调状态机的一致性来简化理解。
   • 核心思想：所有节点初始状态相同，通过选举一个领导者（Leader） 统一接收客户端请求，管理日志复制，确保多个副本的状态机按相同顺序执行命令。

2. 节点角色与任期（Term）

   • 每个节点有三种角色：Leader（处理所有请求）、Follower（被动响应）、Candidate（选举中的临时状态）。
   • 任期：全局连续递增的编号（每个任期最多一个Leader），用于识别过时信息（如旧Leader的请求）。

3. 领导选举（Leader Election）

   • 触发条件：Follower在选举超时（如150-300ms）内未收到Leader心跳，则转为Candidate。
   • 选举过程：
     1. Candidate递增任期，向其他节点发送RequestVote RPC。
     2. 节点仅投票给第一个满足条件的请求（日志至少与自己一样新）。
     3. Candidate获得多数派（N/2+1） 投票后成为Leader，并立即发送心跳确立权威。
   • 选举安全：每个任期最多一个Leader（避免脑裂），通过随机化超时时间减少冲突。

4. 日志复制（Log Replication）

   • 流程：
     1. Client向Leader发送命令，Leader追加日志到本地（未提交）。
     2. Leader通过AppendEntries RPC将日志复制到多数派节点。
     3. 收到多数派确认后，Leader提交日志（应用状态机），并通知Follower提交。
   • 日志匹配特性：
     • 不同节点的日志中，相同索引和任期的条目内容相同，且前一个日志索引相同。
     • 冲突时（如Follower日志缺失），Leader强制覆盖Follower的日志（通过一致性检查回溯修正）。

5. 安全性（Safety）与脑裂处理

   • 约束：只有包含所有已提交日志的节点才能成为Leader（通过RequestVote RPC的日志比较保证）。
   • 提交规则：Leader只能提交当前任期的日志（间接提交旧日志），避免已提交日志被覆盖（见图2.8 in Raft论文）。
   • 脑裂场景：网络分区时，少数派分区无法选举出新Leader（无法获得多数派投票），旧Leader继续服务多数派分区；分区恢复后，少数派Leader自动退位。

6. 对比Paxos的优缺点

   • 优点：
     • 易于实现（如Etcd、Consul等直接使用Raft）。
     • 强领导制简化了日志复制流程。
   • 缺点：
     • 依赖Leader性能（单点瓶颈）；
     • 网络分区时可用性降低（需多数派存活）。

总结：Raft通过角色分离、任期机制和日志匹配规则，在保证一致性的同时降低了工程复杂度。理解其选举与复制流程的关键在于把握“多数派原则”和“日志连续性”。