Paxos：议会里的共识艺术#

共识算法的鼻祖是 Leslie Lamport 在 1990 年提出的 Paxos。Lamport 用一个虚构的希腊岛屿议会来比喻：议会里有提议者（Proposer）、接受者（Acceptor）和学习者（Learner）。整个过程可以分为两个阶段：

第一阶段（Prepare）：提议者向大多数接受者发送一个带编号的提案请求。接受者如果还没承诺过更高编号的提案，就回复「好的，我当前已经接受了编号为 N 的值 V」，并承诺不再接受比这个编号更低的提案。

第二阶段（Accept）：提议者收集到大多数接受者的回复后，选出其中编号最高的已接受值（如果有的话），作为自己的提案值，然后再次向大多数接受者发送请求要求他们接受。如果接受者没有违反承诺，就接受这个值。

整个设计最精妙的地方在于：即使有多个提议者同时发起提案，算法也能保证最终只有一个值被选定。而且无论多少台机器崩溃，只要大多数还活着，系统就能继续工作。

但 Paxos 也有个著名的问题：太难理解了。Lamport 1998 年发表的论文《The Part-Time Parliament》因为使用了大量希腊议会隐喻，审稿人都觉得「这写的啥玩意儿」，直到 2001 年才通过另一篇简化版的论文《Paxos Made Simple》被广泛接受。

Raft：为「可理解性」而设计#

2013 年，斯坦福大学的 Diego Ongaro 和 John Ousterhout 提出了 Raft 算法。他们的设计哲学非常直接：Paxos 当然正确，但它太难理解和实现了。与其让大家继续用各种简化版的 Paxos（每个实现都有些微妙的差异），不如从头设计一个更容易理解的算法。

Raft 把共识问题分解为三个相对独立的子问题：

• 领导者选举（Leader Election）：集群中只有一个是领导者，它负责接收客户端请求并复制日志。如果领导者挂了，其他节点通过超时机制触发新一轮选举，获得大多数选票的成为新领导者。

• 日志复制（Log Replication）：领导者把客户端请求追加到自己的日志中，然后向所有跟随者发送复制请求。当大多数节点确认后，这条日志被提交（committed），领导者再通知所有节点应用到状态机。

• 安全性（Safety）：Raft 通过「任期」（term）机制和选举限制来保证安全——只有拥有最新日志的节点才能成为领导者，防止已提交的日志被覆盖。

Raft 因为结构清晰、状态机明确，迅速成为业界实现分布式一致性的首选。etcd、Consul、TiKV 等知名项目都在用 Raft。

Paxos vs Raft 怎么选？#

简单来说：如果你在看论文、学理论，先搞懂 Raft 会轻松很多。等理解了 Raft 的选举与日志复制机制，再回头去看 Paxos，就能更好地理解 Multi-Paxos 和 Raft 之间微妙的相似与不同。

在工程实践中，几乎没人直接从零实现 Paxos——要么用 Raft，要么用基于 Paxos 的成熟框架。Raft 的「可理解性优先」哲学也深刻影响了后来分布式系统的设计思路：一个协议要先让人搞懂，才能让人实现对。

好啦，今天的分布式小课堂就到这里～下次想听 YuKi 聊什么？一致性哈希？分布式事务？CAP 定理？评论区告诉窝～ 🎀✨