分布式一致性技术-乱弹

性能/SPOF(单点错误)/可用性 -> 多副本 -> 一致性 -> 性能

• Weak 弱一致性

• Eventually 最终一致性

• Strong 强一致性

• 1. 1PC(master-slave)
     master先写自己，再同步到slave；如果slave有一个没有被同步到，整个事物rollback
• 2. 2PC(2 Phase Commit)
     第一阶段，协调者向参与者发送询问请求，参与者都回复yes，则可以进入下一阶段
     第二阶段，协调者想参与者发送提交请求，参与者都回复写ok，Done

问题在于： a. 同步阻塞； b. 协调者如果在一些时候挂掉，整个系统不知所措会hang住

• 3. 3PC(3 Phase Commit)
     第一阶段，协调者向参与者发送询问请求，参与者都回复yes，则可以进入下一阶段
     第二阶段，协调者想参与者发送准备提交请求，参与者都回复yes，则可以进入下一阶段
     第二阶段，协调者想参与者发送提交请求，参与者都回复写ok，Done

3PC相对于2PC，制定了timeout的方针

• 4. Paxos算法
     Paxos的目的是让整个集群的结点对某个值的变更达成一致

这个算法有两个阶段（假设这个有三个结点：A，B，C）：

第一阶段：Prepare阶段

A把申请修改的请求Prepare Request发给所有的结点A，B，C。注意，Paxos算法会有一个Sequence Number（你可以认为是一个提案号，这个数不断递增，而且是唯一的，也就是说A和B不可能有相同的提案号），这个提案号会和修改请求一同发出，任何结点在“Prepare阶段”时都会拒绝其值小于当前提案号的请求。所以，结点A在向所有结点申请修改请求的时候，需要带一个提案号，越新的提案，这个提案号就越是是最大的。

如果接收结点收到的提案号n大于其它结点发过来的提案号，这个结点会回应Yes（本结点上最新的被批准提案号），并保证不接收其它<n的提案。这样一来，结点上在Prepare阶段里总是会对最新的提案做承诺。

优化：在上述 prepare 过程中，如果任何一个结点发现存在一个更高编号的提案，则需要通知 提案人，提醒其中断这次提案。

第二阶段：Accept阶段

如果提案者A收到了超过半数的结点返回的Yes，然后他就会向所有的结点发布Accept Request（同样，需要带上提案号n），如果没有超过半数的话，那就返回失败。

当结点们收到了Accept Request后，如果对于接收的结点来说，n是最大的了，那么，它就会修改这个值，如果发现自己有一个更大的提案号，那么，结点就会拒绝修改。

我们可以看以，这似乎就是一个“两段提交”的优化。其实，2PC/3PC都是分布式一致性算法的残次版本，Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。