Raft 共识算法

Raft 通过领导者选举、日志复制与安全性约束实现共识:客户端请求由领导者追加日志,复制到多数派后提交;任期号与投票约束保证同一任期只有一个领导者。

角色Leader、Follower、Candidate
关键机制任期(term)、随机选举超时、多数派日志复制、成员变更
实现etcd、Consul、TiKV、RethinkDB 等

写入路径(Leader 侧)

写入路径(Leader 侧)
1. 收到写请求,追加到本地日志(未提交)
2. 并行复制给 Follower
3. 多数派确认后提交,应用到状态机
4. 返回结果;Follower 随 commitIndex 向前应用
Raft 设计目标是可理解性,工程实现仍需处理快照、成员变更与网络分区恢复。

易错点

  • 把多数派复制理解为所有节点确认,写入延迟评估错误
  • 忽略成员变更流程,集群扩容期间出现双主

数据来源与参考

  • Diego Ongaro & John Ousterhout《In Search of an Understandable Consensus Algorithm》(USENIX ATC 2014)
  • etcd 官方文档
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌