相比于晦涩难懂的 Paxos 协议，Raft 通过将分布式共识问题解耦为三个独立的子问题：领导者选举（Leader Election）、日志复制（Log Replication）与安全性（Safety），极大地提升了系统的工程可实现性与可推导性。Etcd、Consul 等顶级分布式服务注册与配置中心均基于 Raft 架构。在 Raft 集群中，任意节点处于三种角色之一：Leader、Follower 或 Candidate。系统以“任期”（Term）作为逻辑时钟驱动演进。选举安全性：当 Follower 的心跳超时计时器归零时，其身份转换为 Candidate，自增当前 Term，投自己一票，并向其他节点广播 RequestVote RPC。为了保证被选出的 Leader 必定包含所有已提交（Committed）的日志，投票规则要求：投票节点必须拒绝任何日志成熟度落后于自己的候选者（通过比较末尾日志的 Term 与 Index）。日志复制与多数派确认：Leader 接收客户端写请求后，将操作追加至本地日志，并通过 AppendEntries RPC 广播至各个 Follower。一旦该日志条目被超过半数（Quorum）节点成功写入，该条目即被标记为已提交，Leader 进而将该指令应用（Apply）至底层状态机，并将确认结果返回客户端。日志冲突修正：若网络分区导致 Follower 日志存在分叉与冲突，Raft 强制以 Leader 的日志为绝对真理。Leader 为每个 Follower 维护一个 nextIndex，在日志同步失败时逐步递减探测，直至找到两者一致的日志锚点，随后覆写 Follower 后续所有的冲突日志。