重读 《Paxos Made Simple》

重读 《Paxos Made Simple》

当带着一些问题去阅读，就会注意到很多细节。本次的总结不会整体解读，而是顺着文章去抓重点和细节，所以会标注来源的章节。需要完整看协议的同学，很建议拿着原文一起讨论。

2.1 The Problem

细节：Safety vs liveness

Safety 是 Something bad will never happen，Liveness 是Something good will must happen。

很抽象也很直观，什么是Bad or Good 取决于设计目标。

2.2 Chosing a Value

简单方案的弊端

1. 单Acceptor 的单点问题
2. 多Acceptor 情况下，谁先竞争得到Majority就胜出的方式如果节点异常有可能抉择不出Majority。例如下图中，因为n3 crashed了，其他node已经accept值的情况下如果不能再accept其他值，就不能形成Majority。

n1=a

n2=a

n3-crashed

n4=b

b5=b

解决问题的方向

采用多Acceptor模式，每个Acceptor能accept多个值的情况下，如何选出一个被Majority的Accepted的值。重点是选值，而不是选一个Proposal id。

Proposal number的提出

文中提到了引入Proposal number是为了让proposal trackable，其实在协议里面非常关键。

P2 的目的

Acceptor能同时accept多值时，就会形成多个Majority，如果多个Majority的值不同，就会形成冲突。P2的目的是避免这种冲突。

如果有多个不同值的Proposal产生，选中任何一个值都OK，让没有被选中的进入到next Round就可以了，怎么进入到Next Round 并不在Paxos协议范围内。（Round指一次协议过程）

P2 的递进

P2中的P2a -> P2b -> p2c 是一层层递进的关系，需要实现P2a时，我们只需要满足P2b，以此类推。

P2a 递进 P2b

P2a 要求如果一个value v被chosen，后面的acceptor只能accept值为 v 的Proposal。

被chosen只需要被过半accepted，并不意味着每个acceptor都accept了v。可能存在acceptor a-n 还没有收到消息，并且它还没有意识到 v 已经被chosen。如果此时有proposal向a-n 发送任何值的proposal，它是不能拒绝的。于是只限定acceptor的行为不够，需要更强的限制：P2b 。

P2b 递进 P2c

P2b要求如果有值被chosen 的情况下，后续Proposal 发送的值也是该值。文中有一段话阐述了一个观点。如果我们满足P2b，假设某个proposal m 被chosen且值为v，当前要发送的Proposal 编号为n，n > m，则意味着存在过半集合C：

• C 中的acceptor，如果accept了 m … (n-1)的Proposal，则这些Proposal 值一定为v

那我们可以通过P2c 使n 满足P2b，即Proposal n 的值也为v：

• Proposal n issues的条件是：随意找一个Majority的集合S，询问S中已经accepted 的 highest-number 的值，如果存在，则issue 这个值，否则随便issue。

问题：为什么采用highest-numbrt？

highest-number 存在两个明显的特征：

1. 并表示一定被chosen了；
2. S 的highest-number 也不一定是全局的highest-number。

那么采用S 中 的highest-number呢？假设某个Proposal m被chosen 了，因为majority 有交集的原因，那么Proposal m + 1在issue 的时候通过highest-number 就会采用m的值，依此类推n 采用highest-number 时，如果已经有Proposal 被chosen，则会采用被chosen 的值。

P2c 递进到协议

从P2c 到协议还有一个过渡到过程，主要解决的是P2c中的一个问题：

• 判定一个值已经被chosen 容易，但是判定一个值即将被chosen 难，它可能就差一个node就能过半，并且消息已经在路上了。

与其判定某个proposal是否会成为majority，不如直接断了这个Proposal 的念想，发送Prepare 消息获取被accepted 的highest-number proposal值时，让Acceptor 不再accept比自己编号更小的Proposal。

P2c的效果

1. 已经被accepted的值会被新的proposor issue，值还是会被chosen;
2. 哪怕只有一个node accepted 值后proposor crashdown了，也会被后续的Proposor 接替让值被chosen 这一点相比于抢占majority更加的鲁棒。

2.4 Progress

这里提出了一种无法选择值的情况：proposor 增加id 导致两个proposor 交替竞争无法达到一致的场景。建议的是集群中只有一个单独的Proposer，但是Paxos协议却可以保证在Proposer leader选举失败的情况下也Safety。通常情况下proposor id的产生也会加上机器的信息等，会避免这种情况产生。

为什么不能用原来的id进行重发

Progress章节里面提到了消息重发，但是为什么不能同id重发？说下自己的理解，如果失败是因为其他higher的prepare导致，则重发就没有意义，一定会被抛弃。

其他

理解Round会非常有助于理解协议，容易将协议和我们通常意义上的数据写操作关联起来。单Leader的情况下，也很容易将Paxos晋升为Multi-paxos，减少流程，直接发送Acceptor消息，只是携带不同的round编号。