前一段时间借着组里的实习生学习交流的机会，又重新讨论了一次Paxos算法，颇有收获。本文整理记录几个我个人觉得比较有意义的问题，希望通过思考这几个问题，能够加深你对Paxos算法的理解。

本文假定读者已经对Paxos算法有一定了解（包括原理、正确性证明、执行流程），如果你还不了解Paxos，请移步这里。

Paxos算法流程

---

在思考问题之前，首先重温一下Paxos算法的流程，同时统一变量名称，方便后文讨论。

Prepare阶段：

1. Proposer选择proposal number n，并向acceptors发送Prepare(n)消息
2. Acceptor收到Prepare(n)：if n > minProposal then minProposal = n; return (acceptedProposal, acceptedValue)

Accept阶段：

1. 如果Proposer收到了超过多数派acceptors对于Prepare(n)的回复，如果回复中有包含acceptedValue，则选择acceptedProposal值最大的作为value，否则Proposer可以自行选择value
2. Proposer向所有acceptors发出Accept(n, value)消息
3. Acceptor收到Accept(n, value)：if n >= minProposal then acceptedProposal = n; acceptedValue = value，并回复AcceptAck(n)
4. Proposer收到来自多数派acceptors的AcceptAck消息，value已达成决议(chosen)

问题

---

在上述Paxos算法流程的基础上，仔细思考下面几个问题：

1. 为了保证算法在容灾（节点故障重启）场景下的正确性，Acceptor上需要持久化哪些信息？

2. 如果Acceptor不持久化acceptedProposal，在Prepare阶段的第2步中minProposal代替，有没有问题？

3. Accept阶段，Proposer不用n覆盖acceptedProposal，仍将其发送给Acceptor，Acceptor收到Accept(n, acceptedProposal, value)之后使用消息中的acceptedProposal而不是n来作为acceptedProposal，有没有问题？

4. 在5个节点的情况下，如果修改流程为Proposer要收到4个acceptor对Prepare(n)的回应才可以发送Accept消息，要收到2个acceptor对Accept(n, value)的回应才能确认决议，有没有问题？

5. 论文中提到Proposer选择proposal number要递增且不重复，这个要求是不是必要的？如果把Prepare阶段第2步中的>改为>=呢？

WARNING： 强烈建议花一些来仔细思考上面的问题，在得出自己的答案之后再继续往下看

继续阅读：→

想必每个接触过分布式系统的同学都没少看到过“一致性”这个词，但是我最近有一个越来越强烈的感觉：“一致性”这个词已经被严重的误用了，以至于当我看到这个词的时候，我甚至得花些功夫去思考这到底指的是哪个“一致性”，更严重的是，当别人在谈到“一致性”的时候，实际上他们在谈的完全是另一种东西。

无辜的Paxos

---

故事的起因来源于Paxos（没错，又是这货），网上对于Paxos的文献太多，而且质量参差不齐，在绝大多数的中文文档中，你都可以看到这样的描述：“Paxos是一个分布式强一致性协议”，不瞒你说，每次看到这样的表述的时候，我的内心是崩溃的…且听我慢慢道来。

问题的由来很大一部分原因在于英文对中文的翻译，因此我们必须将术语还原到英文进行讨论，『一致性』对应的英文名词应该是Consistency没错了，然后我们在Lamport大神的原始论文《Paxos Made Simple》中搜索关键词，你会发现：

没错，论文中一次都没有提到过Consistency，也就是说，Paxos和『一致性』根本半毛钱关系都没有啊！那Paxos究竟是什么呢？论文中写的很明确——”The Consensus Algorithm”。

PS：本文中所有使用中文“一致”均指Consistency，“共识”为Consensus。

继续阅读：→