Raft 参数
| 项目 | 值 |
|---|
| 心跳间隔 | 250ms |
| 选举超时 | 500-1000ms —— leader 故障后会在此窗口内发起新一轮选举 |
| 节点数 | 3 或 5(在加载配置时强制校验 —— 其他数值一律拒绝启动) |
| 节点 ID | 其(cluster_self)在 cluster_peers 列表中的位置 —— 这也是为什么列表顺序在每个节点上必须完全一致 |
| 引导启动 | 启动后 500ms,每个节点都以相同的成员关系初始化 —— 若加入的是已初始化的集群,则会被忽略 |
| 日志存储 | 内存中(易失)—— 重启的节点通过复制/快照恢复 |
| Lease 过期检测 | leader 每 100ms 检查一次,并通过共识提交 Expire |
wait 超时粒度 | 等待超时(T)也是在同一个 100ms 周期上决定的 —— 最多可能晚到 100ms |
为什么是 3 或 5 个节点
提交需要多数派。偶数节点配置只会增加成本,却不能提升容错能力, 因此服务器拒绝以偶数节点启动。
| 节点数 | 多数派 | 可容忍的并发故障数 |
|---|
| 2 | 2 | 0 —— 单个故障就会使集群停止服务。并不比单机模式更好 |
| 3 | 2 | 1 |
| 4 | 3 | 1 —— 与 3 节点相同,只是成本更高 |
| 5 | 3 | 2 |
故障行为总结
| 情况 | 行为 |
|---|
| 客户端向非 leader 节点发送请求 | M(leader 地址),若 leader 未知则返回 E no_leader |
| Leader 故障 | 在 500-1000ms 内选出新 leader。此窗口期内的请求会收到 E no_leader → 客户端重试 |
| Leader 变更期间 | 待处理的获取请求会以 M/E no_leader 清空,客户端向新 leader 重试 |
| 节点重启 | 以空状态启动 → 通过对端的日志复制/快照追赶进度 |
| 多数派丢失 | 提交变得不可能 → 停止写入(安全第一),多数派恢复后自动继续 |
术语
- 多数派 (quorum) —— 超过全部节点半数(3 个中的 2 个,或 5 个中的 3 个)。 由于任何决策都需要多数派同意,两个被分区的组永远不可能同时提交相互冲突 的决策。
- 选举超时 (election timeout) —— follower 在未收到心跳的情况下等待多久 才断定 leader 已挂掉并发起选举。每个节点上的具体时长是随机化的, 以减少同时发起候选的情况。