分布式算法 - Raft算法

最新推荐文章于 2025-10-03 13:05:42 发布

原创最新推荐文章于 2025-10-03 13:05:42 发布 · 667 阅读

CC 4.0 BY-SA版权

文章标签：

42 篇文章

订阅专栏

机制	功能	关键细节
领导者选举	通过心跳超时触发选举，获得多数票的节点成为 Leader	任期（Term）递增保证选举唯一性
日志复制	Leader 将操作日志同步到多数节点后提交，确保一致性	日志条目包含 Term 和 Index 双重标识
安全性约束	Leader 必须包含所有已提交日志，防止数据丢失	通过选举限制（Leader Completeness）实现

选举超时：通常为 150-300ms，避免频繁选举。

对比维度	Raft	Paxos	ZAB
可理解性	模块化设计，易于实现	理论复杂，工程实现困难	专为 ZooKeeper 优化
领导者角色	强领导者模型，读写均通过 Leader	无固定领导者，角色动态切换	类似 Raft，但侧重恢复模式
典型应用	ETCD、Consul	Google Chubby	ZooKeeper

Raft 优势：

通过日志连续性简化冲突解决。
选举过程明确，故障恢复速度快。

# 选举超时调整（避免网络抖动误触发）  
-raft-election-timeout=500ms  

# 日志批量提交提升吞吐量  
-raft-batch-size=1000  

# 快照压缩减少日志存储压力  
-raft-snapshot-interval=3600s

注意事项：

增大心跳间隔可能降低故障检测灵敏度。
快照频率过高会影响性能。

Raft 通过 角色明确化 和 流程模块化 解决了 Paxos 的复杂性难题，成为分布式系统（如 K8s 的 ETCD）的首选共识算法。其设计平衡了理解成本与工程实用性，但在高吞吐场景需结合分片或 Multi-Raft 优化。

触发条件：跟随者超过选举超时时间未收到领导者心跳
流程步骤：
1. 跟随者转变为候选人，增加任期号
2. 向所有节点发送RequestVote RPC请求投票
3. 如果收到大多数节点的投票，则成为领导者
4. 新领导者开始向所有节点发送心跳维持领导地位

领导者处理客户端请求：
1. 接收客户端请求
2. 将请求作为新日志条目追加到自己的日志中
3. 向所有跟随者发送AppendEntries RPC请求复制日志
跟随者处理：
1. 检查日志一致性（通过前一个日志索引验证）
2. 如果一致则追加日志条目并返回成功
3. 如果不一致则返回失败
领导者处理响应：
1. 统计跟随者的响应
2. 当大多数跟随者确认后，提交该日志条目
3. 将已提交的日志应用到状态机
4. 返回响应给客户端