Raft 是什么
Raft 是一致性共识算法，通过领导者选举、日志复制与安全性约束让多个节点对同一份日志达成一致。客户端请求由领导者追加到本地日志，复制到多数派后提交并应用到状态机，任期号与投票约束保证同一任期最多只有一个领导者。它的设计目标是可理解性，被 etcd、Consul、TiKV 等广泛实现，用于分布式协调、配置中心与元数据存储。
基本信息
| 角色 | Leader 领导者、Follower 跟随者、Candidate 候选者 |
|---|---|
| 关键机制 | 任期号、随机选举超时、多数派日志复制、成员变更 |
| 提交条件 | 日志被多数派节点持久化后即可提交并应用 |
| 容量规则 | 三节点容忍一台故障，五节点容忍两台，节点数应为奇数 |
| 常见实现 | etcd、Consul、TiKV、RethinkDB |
写入路径（领导者侧）
写入路径（领导者侧）
1. 收到写请求，追加到本地日志（未提交状态）
2. 并行复制日志条目给所有跟随者
3. 多数派确认后提交，并应用到本地状态机
4. 返回结果；跟随者随提交位置向前应用日志运维关注点
| 事项 | 说明 | 风险 |
|---|---|---|
| 节点数 | 通常部署 3 或 5 个投票节点 | 偶数节点不增加容错反而增加故障域 |
| 时钟与超时 | 选举超时随机化避免选票分裂 | 网络抖动频繁触发重新选举 |
| 快照 | 日志过大时压缩为快照 | 快照过慢导致追赶时间过长 |
| 成员变更 | 按单节点逐步变更 | 一次性替换多数节点可能丢失多数派 |
| 磁盘 | 日志持久化依赖 fsync | 磁盘抖动直接影响写入延迟 |
多数派是提交条件也是可用性边界：三节点集群失去两台后无法写入，这是设计上的正确行为而非故障。
跨越两个机房部署而多数派在同一机房，机房级故障时另一侧无法选出领导者，需按容灾目标安排节点分布。