共识不是“大家网络通了就投票”，而是在节点崩溃、消息重复和延迟下，正确节点仍不能对同一位置决定不同值。Paxos 给出核心安全思想，Raft 用 Leader、任期和日志把工程过程拆得更清楚。
Table of contents
Open Table of contents
从一个日志槽位开始
Paxos 中，提议者提交带编号的值，接受者承诺不再接受更小编号的提案。两个法定人数必然相交，交点携带之前可能被选定的值，因此后续轮次不能随意覆盖它。Multi-Paxos 在稳定 Leader 下复用准备阶段，连续决定日志槽位。
Raft 把时间划分为任期（term）。Follower 超时后成为 Candidate，请求选票；获得多数票后成为 Leader。Leader 复制日志，某条当前任期日志被多数派保存后才推进提交位置。每个节点按提交顺序把命令应用到同一个确定性状态机。
客户端命令 → Leader 日志 → 多数派复制 → commitIndex 前进 → 状态机应用 → 响应相同输入必须得到相同状态
状态机代码不能直接读取随机数或本地当前时间，否则副本会分叉。需要随机值时，由 Leader 把选定值写进日志；外部副作用则用幂等键隔离重放。
成员变更也不能直接把 3 节点配置替换为另一组 3 节点。安全协议会使用联合配置或等价机制，确保新旧法定人数在过渡期存在约束。快照用于压缩已提交日志，但快照安装也必须带上最后日志位置与任期。
共识没有解决什么
共识不自动解决客户端重复请求、跨系统事务、磁盘永久损坏、拜占庭恶意节点或错误业务命令。多数派测试只展示集合交叉，不是 Raft 实现：
mvn -Dtest=DistributedMechanismsTest#snowflakeIdsIncreaseAndQuorumRequiresMajority test阅读 Raft 论文与可视化资料时，按选举安全、日志匹配、Leader 完整性和状态机安全四个性质核对实现。
下一步
继续阅读08-08 ShardingSphere-JDBC 分片实战，把一致性知识用于数据库水平拆分。