为啥CoreOS没用Paxos，重新搞了Raft？

Posted 2021-04-17 Container技术日报

上图摘自Twitter，搜索#FeministHackerBarbie，可看到更多芭比作为极客程序媛的一面。

---

上周桂阳的文章《CoreOS 实战：剖析 etcd》，引起了大家的一个讨论：为啥CoreOS不直接用Paxos（Paxos是一个非常经典的分布式同步算法，Zookeeper的同步就使用了Paxos算法），而是重新搞了一个Raft?

七牛云存储联合创始人兼首席技术顾问徐立比较详细地解答了这个问题：Paxos 相比 Raft 比较复杂和难以理解。角色扮演和流程比 Raft 都要啰嗦。比如 Agreement 这个流程，在 Paxos 里边：Client 发起请求举荐 Proposer 成为 Leader，Proposer 然后向全局 Acceptors 寻求确认，Acceptors 全部同意 Proposer 后，Proposer 的 Leader 地位得已承认，Acceptors 还得再向Learners 进行全局广播来同步。而在 Raft 里边，只有 Follower/Candidate/Leader 三种角色，角色本身代表状态，角色之间进行状态转移是一件非常自由民主的事情。Raft虽然有角色之分但是是全民参与进行选举的模式；但是在Paxos里边，感觉更像议员参政模式。

Paxos 自 1989 年提出以来，已经25年了。Raft 才没几岁，但是被设计成更加 Understandability 所以必然能吸引大多数人。从机理来讲，也是更加 strong consistency & strong leadership.

不过公司内部平台都会基于组件来独立提供服务、用那个自己选择就好了、新项目和基础服务推荐etcd。比如Kafka或者其他Java应用、Zookeeper用起来也很欢快。

总之，Pasox算法太复杂，难以理解，难以实现，实现了难以除错。从使用的角度来说，两者区别很大：Zookeeper使用时，Client需要绑定特定的语言，Client渗入用户的应用实例，API的使用显得古板。etcd使用起来方便得多，都可以使用HTTP+json的形式来实现用户应用中的Client端。

最后，建议大家都去看看Paxos算法，比《星际穿越》要烧脑啊！