分布式一致性算法 2PC 3PC Paxos

分布式一致性算法的目的是为了解决分布式系统

一致性算法可以通过共享内存（需要锁）或者消息传递实现，本文讨论后者实现的一致性算法，不仅仅是分布式系统中，凡是多个过程需要达成某种一致的场合都可以使用。

本文讨论无论2PC、3PC和Paxos，均无法彻底解决分布式一致性问题。解决一致性问题，唯有Paxos。

Paxos算法是保证在分布式系统中写操作能够顺利进行，保证系统中大多数状态是一致的，没有机会看到不一致，因此，Paxos算法的特点是一致性>可用性。

vector clock向量时钟是另外一种保证复制的算法，其特点是可用性>一致性，但是，一旦发生冲突，不像Paxos能自行解决，需要人工干预编写代码解决。

Paxos算法和Vector Clock都是由Leslie Lamport提出。

2PC (Two-Phase Commit 二阶段提交协议)

2PC，二阶段提交协议，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。

阶段1：准备阶段
　　1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
　　2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
　　3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

阶段2：提交阶段
　　此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。
　　所有参与者均反馈YES时，即提交事务。
　　任何一个参与者反馈NO时，即中断事务。

提交事务：（所有参与者均反馈YES）
　　1、协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
　　2、参与者执行Commit请求，并释放整个事务期间占用的资源。
　　3、各参与者向协调者反馈Ack完成的消息。
　　4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交

附如下示意图：

中断事务：（任何一个参与者反馈NO）
　　1、协调者向所有参与者发出回滚请求（即Rollback请求）。
　　2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
　　3、各参与者向协调者反馈Ack完成的消息。
　　4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。

附如下示意图：

2PC的缺陷

　　1、同步阻塞：最大的问题即同步阻塞，即：所有参与事务的逻辑均处于阻塞状态。
　　2、单点：协调者存在单点问题，如果协调者出现故障，参与者将一直处于锁定状态。
　　3、脑裂：在阶段2中，如果只有部分参与者接收并执行了Commit请求，会导致节点数据不一致。
　　由于2PC存在如上同步阻塞、单点、脑裂问题，因此又出现了2PC的改进方案，即3PC。

3PC (Three-Phase Commit 三阶段提交协议)

3PC，三阶段提交协议，是2PC的改进版本，即将事务的提交过程分为CanCommit、PreCommit、do Commit三个阶段来进行处理。

阶段1：CanCommit
　　1、协调者向所有参与者发出包含事务内容的CanCommit请求，询问是否可以提交事务，并等待所有参与者答复。
　　2、参与者收到CanCommit请求后，如果认为可以执行事务操作，则反馈YES并进入预备状态，否则反馈NO。

阶段2：PreCommit
　　此阶段分两种情况：
　　1、所有参与者均反馈YES，即执行事务预提交。
　　2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
 
　　事务预提交：（所有参与者均反馈YES时）
　　1、协调者向所有参与者发出PreCommit请求，进入准备阶段。
　　2、参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。
　　3、各参与者向协调者反馈Ack响应或No响应，并等待最终指令。
 
　　中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
　　1、协调者向所有参与者发出abort请求。
　　2、无论收到协调者发出的abort请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段3：do Commit
 　　此阶段也存在两种情况：
　　1、所有参与者均反馈Ack响应，即执行真正的事务提交。
　　2、任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务。
 
　　提交事务：（所有参与者均反馈Ack响应时）
　　1、如果协调者处于工作状态，则向所有参与者发出do Commit请求。
　　2、参与者收到do Commit请求后，会正式执行事务提交，并释放整个事务期间占用的资源。
　　3、各参与者向协调者反馈Ack完成的消息。
　　4、协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
 
　　中断事务：（任何一个参与者反馈NO，或者等待超时后协调者尚无法收到所有参与者的反馈时）
　　1、如果协调者处于工作状态，向所有参与者发出abort请求。
　　2、参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
　　3、各参与者向协调者反馈Ack完成的消息。
　　4、协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
 
　　注意：进入阶段三后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的do Commit请求或abort请求。此时，参与者都会在等待超时之后，继续执行事务提交。

附示意图如下:

3PC的优点和缺陷

　　优点：降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
 
　　缺陷：脑裂问题依然存在，即在参与者收到PreCommit请求后等待最终指令，如果此时协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

Paxos

Paxos是一种基于消息传递的分布式一致性算法，由Leslie Lamport（莱斯利·兰伯特）于1990提出。是目前公认的解决分布式一致性问题的最有效算法。

现实中Paxos的实现以及成为一些世界级软件的心脏，如Cassandra, Google的 Spanner数据库, 分布式锁服务Chubby。

要解决的问题及应用场景

　　Paxos算法要解决的问题，可以理解为：一个异步通信的分布式系统中，如何就某一个值（决议）达成一致。
　　而此处异步通信是指，消息在网络传输过程中存在丢失、超时、乱序现象。
 
　　其典型应用场景为：
　　在一个分布式系统中，如果各节点初始状态一致，而且每个节点执行相同的命令序列，那么最后就可以得到一个一致的状态。为了保证每个节点执行相同的命令序列，即需要在每一条指令上执行一致性算法（如Paxos算法），来保证每个节点指令一致。

概念定义

　　Proposal：为了就某一个值达成一致而发起的提案，包括提案编号和提案的值。
 
　　涉及角色如下：
　　Proposer：提案发起者，为了就某一个值达成一致，Proposer可以以任意速度、发起任意数量的提案，可以停止或重启。
　　Acceptor：提案批准者，负责处理接收到的提案，响应、作出承诺、或批准提案。
　　Learner：提案学习者，可以从Acceptor处获取已被批准的提案。

约定

　　Paxos需要遵循如下约定：
　　1、一个Acceptor必须批准它收到的第一个提案。
　　2、如果编号为n的提案被批准了，那么所有编号大于n的提案，其值必须与编号为n的提案的值相同。

算法描述

　　阶段一：准备阶段
 
　　1、Proposer选择一个提案编号n，向Acceptor广播Prepare(n)请求。
　　2、Acceptor接收到Prepare(n)请求，如果编号n大于之前已经响应的所有Prepare请求的编号，那么将之前批准过的最大编号的提案反馈给Proposer，并承诺不再接收编号比n小的提案。否则不予理会。
 
　　阶段二：批准阶段
 
　　1、Proposer收到半数以上的Acceptor响应后，如果响应中不包含任何提案，那么将提案编号n和自己的值，作为提案发送Accept请求给Acceptor。否则将编号n，与收到的响应中编号最大的提案的值，作为提案发送Accept请求给Acceptor。
　　2、Acceptor收到编号为n的Accept请求，只要Acceptor尚未对编号大于n的Prepare请求做出响应，就可以批准这个提案。

死循环问题

　　如果Proposer1提出编号为n1的提案，并完成了阶段一。与此同时Proposer2提出了编号为n2的提案，n2>n1，同样也完成了阶段一。于是Acceptor承诺不再批准编号小于n2的提案，当Proposer1进入阶段二时，将会被忽略。同理，此时，Proposer1可以提出编号为n3的提案，n3>n2，又会导致Proposer2的编号为n2的提案进入阶段二时被忽略。以此类推，将进入死循环。
 
　　解决办法：
 
　　可以选择一个Proposer作为主Proposer，并约定只有主Proposer才可以提出提案。因此，只要主Proposer可以与过半的Acceptor保持通信，那么但凡主Proposer提出的编号更高的提案，均会被批准。

Learner

　　一旦Acceptor批准了某个提案，即将该提案发给所有的Learner。为了避免大量通信，Acceptor也可以将批准的提案，发给主Learner，由主Learner分发给其他Learner。考虑到主Learner单点问题，也可以考虑Acceptor将批准的提案，发给主Learner组，由主Learner组分发给其他Learner。

---

参考

https://blog.51cto.com/11821908/2058651

https://blog.51cto.com/11821908/2058996

https://www.cnblogs.com/hugb/p/8955408.html

https://www.jianshu.com/p/89c92bfc48f4

https://baike.baidu.com/item/Paxos%20%E7%AE%97%E6%B3%95

https://www.jdon.com/artichect/paxos.html

https://github.com/oldratlee/translations/tree/master/paxos-made-simple