分布式基石｜最难 paxos 和最易 raft？，一起看看这些大厂面试真题查漏补缺吧

这种状态机的应用模式可不仅限于存储服务。

到这，我相信童鞋们已经很豁然开朗了，只要我们通过 paxos 来产生分布式一致的有序的操作日志，加上状态机的配合，实现一个分布式存储服务必然不是问题。

通过不停的确定一个个值，形成一个有序的操作系列，配合状态机的应用，这，就是 paxos 的工程化方向。

4 活锁的问题怎么解决？

对于 paxos 来说，Proposer 和 Acceptor 角色是可以重叠的，每个节点既可以是 Proposer，也可以是 Acceptor ，或者两者都是。

这带来了非常大的灵活，每一个 Proposer 都可以递交协议（写入数据），但由于最终只能确定一个值，那么这会导致非常多的无效功，这期间是使用类似乐观锁来解决那些冲突的提议。

比如说，A 刚递交一个提案，B 就递交一个新提案导致 A 的提案被否定了，然后 A 又迅速递交一个提案，形成了一种类似活锁的状态，这时间就浪费了呀。

怎么解决？

问题根因在于可以提案的点太多，大家都是平等的。那么统一声音才能解决这个问题。于是Leader就应运而生。通过某种方法指定一个节点为 Leader ，只有一个节点能递交提案，这样就解决了混乱问题，效率提随之提升（这就是 Multi-Paxos ）。

5 paxos 工程化小结

小结一下，如果要将一个 paxos 工程化落地，衍生了哪些东西：

1. paxos 本质是确定一个值，把参与确定这个值的角色打包称为一组实例（ paxos instance ）；2.不同实例之间决议互不干扰。多组 paxos 实例确定多个值，形成一组操作序列，也是就日志 ；

2. 日志 + 状态机 可以成为任何有意义的工程系统；

3. 为了解决递交提案混乱可能引发的效率问题（比如活锁），可以通过指定 Leader 角色来解决；

慢着，这个工程化方向咋这么眼熟呢？

这不就是 raft ！

raft 协议

终于到了 raft 协议，raft 的论文开篇就是这么一段话：

Raft is a consensus algorithm for managing a replicated log. It produces a result equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is different from Paxos;

raft 证明和 paxos 等价，raft 是一种日志复制的一致性算法。

看懂了吗？raft 的着眼点就是 日志+状态机 的方向。

划重点：raft 天生就是 paxos 协议工程化的一种样子。

如下图：

图里交代了关键模块：

1. 客户端（ Client ）：就是用户嘛，写入数据的就是它喽；

2. 一致性模块（ Consensus Module ）：负责写入 log，并且把 log 复制到其他节点；

3. 状态机（ State Machine ）：输入 log ，推进变更系统状态；

raft 确实比 paxos 简单啊，因为它已经把实现程序交互的样子都画