分布式系统常见问题总结（三）- 一致性协议和算法

2PC协议：

两阶段提交协议，我们先根据下面的图来看一下它的整个执行过程，

阶段一：协调者向参与者发出Prepare请求，参与者执行事务但不提交，并根据自己执行情况回复YES或者NO。YES，则继续往下走，NO或者超时，则整个事务结束。

阶段二：协调者向参与者发出Commit请求，参与者提交事务，并根据自己的情况回复YES或者NO。YES则继续往下走，NO或者超时，则整个事务结束，需要回滚的参入这回滚事务。

2PC的缺点：

同步阻塞：协调者向所有的参与者发送Prepare请求后，需要等待所有的参与者回复YES后才能开始第二阶段，先执行的参与者需要等待后执行的参与者。

单点问题：协调者出现问题的话，这个过程不可用了，并且参入者还有可能一直处于事务锁定的状态（阶段一完成后，协调者挂了）。

数据不一致：第二阶段参与者一Commit了，参与者二由于网络原因或者协调者挂了，还没提交，这时候数据处于不一致的状态。大家可以自己看着图考虑在1-8步骤中，如果出现问题，数据是否会不一致。



3PC协议：

三阶段提交协议，我们先根据下面的图来看一下它的整个执行过程，

阶段一：协调者向参与者发出CanCommit请求，参与者根据自己执行情况回复YES或者NO。YES，则继续往下走，NO或者超时，则整个事务结束。

阶段二：协调者向参与者发出PreCommit请求，参与者根据自己的情况回复YES或者NO。YES则继续往下走，NO或者超时，则整个事务结束，需要回滚的参入这回滚事务。

阶段三：协调者向参与者发出doCommit请求，参与者根据自己的情况回复YES或者NO。YES则继续往下走，NO或者超时，则整个事务结束，需要回滚的参入这回滚事务。

3PC相对于2PC的优势：

降低参与者的阻塞范围：2PC的第二阶段，如果协调者挂了，参与者都会一直阻塞，并且不能释放共享资，3PC的第三阶段，如果协调者挂了，参与者会在等待超时后，继续执行事务。（因为3PC第二阶段已经通过了，第三阶段通过的概率会很大，参与者不会阻塞）

数据一致：2PC的第二阶段，如果一个参与者已经执行力，但是协调者挂了，后面的参与者收不到消息不能执行事务，会出现不一致的情况。3PC的第三阶段，协调者挂了，会继续执行，出现不一致的概率要小。（举个例子，3PC第三
4000
阶段，如果第一个参与者失败了，后面的参与者应该不执行，但是协调者挂了，后面的参与者还是会执行，导致数据不一致，但这种情况的概率很小，毕竟，3PC第二阶段，参与者都通过了）



Paxos算法：

我们先来确定一下几个概念：

提议者：提出提议的人

接受者：接受或者拒绝提议的人

提议：提出的方案或值，唯一的并且是递增的

我们再来看一下paxos算法的过程：

准备阶段：

a.提议者提出协议给所有的接收者

b.接受者比较自己保存的提议：1.如果自己没有保存协议，则接受并返回 2.如果自己保存的协议小，则接受并返回 3.如果自己保存的了协议，并且自己的协议大，则拒绝并返回 

c.如果自己提交的协议，有一半的接收者同意了，则进入接受阶段，否则根据接收者返回的提议，提交一个更新的提议。

接受阶段：

a.提议者提出接受的协议给所有的接受者

b.接受者比较自己保存的提议：1.如果自己保存的协议小，则接受并返回 2.如果自己保存的协议大，则拒绝并返回 

c.如果自己提交的执行协议，有一半的接收者同意了，则达到统一。

paxos算法下面几点需要注意：

a.半数通过

b.准备阶段和提交阶段是针对提议者的，接受者不会管你在什么阶段，只会按照自己的规则接受或者拒绝。

c.paxos协议效率不高，并且会出现死锁。效率不高的原因，在于多个提议者一起提议，先提出的协议会一直被拒绝，又会重新提议。死锁的情况，举一个例子，提议者A提出协议1，接受者A，B，C同意了，进入执行阶段，这时候提议者B提出协议2，接收者C，D，E同意了，进入执行阶段，协议1的执行失败了，因为C不会同意，协议者A只有提出协议3，接收者A，B，C同意了，协议2的执行阶段失败了，因为C不会同意，然后一直循环。

multi-paxos:

paxos两阶段变为一阶段，需要一个leader，leader是使用paxos算法选择出来的，只有leader能够提出提议，接受者只需要同意或者拒绝。