Raft和Multi-Paxos的具体流程

Raft和Multi-Paxos都是分布式共识算法，确保多个节点在某个值上达成一致。以下是它们达成共识的具体流程：

Raft算法流程

Raft将共识分解为三个子问题：领导选举、日志复制 和 安全性。

1. 领导选举

• 角色：Leader（领导者）、Follower（跟随者）、Candidate（候选人）
• 流程：
  1. 初始所有节点均为Follower
  2. Follower在选举超时（通常150-300ms）内未收到Leader心跳，则转为Candidate
  3. Candidate发起选举：
     • 递增当前任期号（term）
     • 给自己投票
     • 向其他节点发送RequestVote RPC
  4. 选举成功条件：
     • 获得多数派（N/2+1）投票
     • 同一任期内最多只有一个Leader
  5. 新Leader定期发送心跳维持权威

2. 日志复制

Client → Leader → Followers → Commit → Apply

1. 客户端请求：客户端向Leader发送命令
2. 日志追加：Leader将命令作为新日志条目加入本地日志
3. 并行复制：Leader通过AppendEntries RPC将日志发送给所有Followers
4. Followers确认：
   • 验证日志一致性（前一索引和任期匹配）
   • 追加日志并返回成功
5. Leader提交：
   • 收到多数派确认后提交该条目
   • 更新commit index
6. 通知Followers：后续心跳中携带commit index，Followers提交并应用到状态机
7. 响应客户端：Leader将执行结果返回客户端

3. 安全性机制

• 选举限制：Candidate必须包含所有已提交的日志条目
• 提交规则：Leader只能提交当前任期的日志条目

Multi-Paxos算法流程

Multi-Paxos通过选举稳定Leader来优化基础Paxos，避免每项提案都进行两阶段提交。

1. Leader选举（Prepare阶段）

1. Proposer选择提案号n：生成全局唯一递增编号
2. 发送Prepare请求：向所有Acceptors发送Prepare(n)
3. Acceptor承诺：
   • 若n > 已响应的最高提案号，则承诺不再接受编号<n的提案
   • 返回已接受的最高编号提案（如有）
4. 成为Leader：获得多数派响应后，Proposer成为事实Leader

2. 日志复制（Accept阶段 - 优化后）

Client → Leader → Acceptors → Learn → Apply

1. 跳过Prepare阶段：稳定期Leader直接进入Accept阶段
2. 分配日志索引：Leader为客户端命令分配连续日志槽位
3. 发送Accept请求：向Acceptors发送Accept(n, index, value)，n为提案号
4. Acceptor接受：
   • 若未对更高编号的Prepare作出承诺，则接受提案
   • 持久化存储(提案号n, 索引index, 值value)
5. 达成共识：
   • 收到多数派接受后，该位置值被选定
   • Leader通知Learners（可批量）
6. Learner学习：Learners获取选定值并应用到状态机

3. 故障处理

• Leader故障：新Proposer发起Prepare，使用更高提案号
• 日志空洞：新Leader通过Prepare阶段收集已接受提案，填补缺失条目

关键差异对比

方面	Raft	Multi-Paxos
领导权	强Leader，唯一写入口	弱Leader，可被推翻
日志连续性	强制连续，无空洞	允许空洞，需特殊处理
通信模式	心跳驱动，追加日志RPC	提案号驱动，两阶段优化
理解难度	易于理解实现	理论复杂，优化多样
实际应用	etcd, Consul等	Google Chubby等

共识保证

两者均满足：

1. 安全性：已提交的日志不可更改
2. 活性：最终能达成共识
3. 多数派原则：需N/2+1节点正常

Raft通过强Leader简化了系统状态，而Multi-Paxos提供了更灵活的优化空间。实际系统中，Raft因易于理解和实现而更流行，Multi-Paxos在特定高性能场景仍有优势。