理解分布式一致性协议Paxos

Make it Simple

Question：大名鼎鼎的Paxos协议是啥？Ansower：“分布式一致性协议”。
这么逼格的术语，就问你怕不怕？？能不能搞的中国话一点，简单一点，而不是翻译《Paxos Made Simple》呢？一直觉得Lesile Lamport的脑回路和常人不一样好伐。文章前面部分一眼都懂，后面的，眼睛瞄瞎都不一定看得懂。本文是Paxos的一些阅读总结。欢迎一起讨论。

解决什么问题

场景化的核心问题：成功的往分布式系统里面写入一个数据。Outline几个关键问题：

1. 数据写入模型是异步非阻塞，我们说的“同时”，都是指一次写入未Finish的情况下就开始下一次的写入；
2. 各节点的数据一致，保证是最终一致；
3. 失败处理的两个关键问题：失败了是否会重试、重试的时候是否会增加ID，文中对失败处理没有太多的描述；
4. 保证数据顺序写入，一旦一个写入成功，后续就不会有ID更小的数据写入成功。但并不是每一个“同时”的写入操作都会写成功，也不保证ID大的就一定会成功。

怎么解决问题

我们循序渐展开思考解决之法。主要路径是;

1. All，写入所有节点
2. Quorum，写入过半节点
3. Rules， 竞争规则
4. Same Value，等值情况怎么应对
5. Uncertainty，结果的非确定性
6. Two Phase， 为什么要两阶段提交

All

最直观的，往所有节点写成功就算成功。是一个过程艰辛的正确答案。多个写操作并行时，部分节点是value=A，部分节点value=B，到底是A还是B呢？

Quorum

好解决。咱们投个票，少数服从多数。关于投票，既然投票，拿了过半的选票数就算胜利了。如果总票数为偶数，那势必需要在一个票上相互争取。既然是争取就得定个输赢的规矩。

Rules

最简单的输赢规矩是先到先得，占坑。OK，至此，基本道理咱们都了解了。咱们对着协议来说说怎么玩的。首先给proposal编号，可以理解为一个Proposal就是一次写入的申请，有了全局编号意味着就有了顺序。如果一个节点（协议成为Accepter）收到了两个ID的Proposal：

Same Value

如果两个写入者写入的是同一个值，比如之前提到的数据重发场景。要想达到重发数据也成功的效果，节点就要求可以接收多个Proposa。对应于协议里面就如果Acceptor发现Proposal的value和已经接受的一致，但是ID比已经接受的大，就也接受这个ID。应该也适用于非重发，但是同时写入的Value一致的场景。

Uncertainty

同时写入A和B两个数据，其中A的ID小于B的ID。结果到底是A还是B呢？按照前面的描述，其实不确定。如果A已经拿到了半数的选票，B就会失败。但是这种情况对应用来说并非最佳选择，毕竟有个先后顺序。

Two Phase

这块是最难以理解的，大家都会说有两个阶段。但从不解释为啥要拆分成两个阶段（Prepare和 Accept）。我简述下我的理解，（如果有其他理解或者权威资料的请你通知我）：

1. 给ID更大的Proposal多一次机会。第一阶段拿到拿到过半票数后，也有可能被ID更大的消息抢走选票；
2. 事先询问。别一股脑去写入，先问下是否具备写入条件。如果ID大的哥们已经拿到了过半选票，你还去写入剩余的一些戳，其实是没有必要的，写了大家也不认，还要再改写。
3. 协助达成所有节点的数据一致，如果ID大的Proposal未被accept，他可以改变自己Proposal的值，发向其他的节点。算法本身并没有说明这一点。咱们也不去讨论如果ID大的写入失败了，业务层重新写入数据的情况，我理解又是一次算法的全过程了。
4. 类似Zookeeper，这种同时写入，更多的是去解决多Master同时存在的情况，通过ID的增加，可以识别出新旧master，从而拒绝旧Master的请求。这种玩法的极端情况情况下，新的Master如果是Prepare成功，Accept失败，是需要重试的。