⼀致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR超详
细解析
背景
在常见的分布式系统中，总会发⽣诸如机器宕机或⽹络异常（包括消息的延迟、丢失、重复、乱序，还有⽹络分区）等情况。
⼀致性算法需要解决的问题就是如何在⼀个可能发⽣上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成⼀致，并且保证不论发⽣以上任何异常，都不会破坏整个系统的⼀致性。
CAP 定理
CAP 理论告诉我们，⼀个分布式系统不可能同时满⾜⼀致性（C:Consistency)，可⽤性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满⾜其中的2个。创业孵化器
Ba 理论
BASE：全称：Basically Available(基本可⽤)，Soft state（软状态），和 Eventually consistent（最终⼀致性）。
Ba 理论是对 CAP 中⼀致性和可⽤性权衡的结果，其来源于对⼤型互联⽹分布式实践的总结，是基于 CAP 定理逐步演化⽽来的。其核⼼思想是：既是⽆法做到强⼀致性（Strong consistency），但每个应⽤都可以根据⾃⾝的业务特点，采⽤适当的⽅式来使系统达到最终⼀致性（Eventual consistency）。
解释⼀下：什么是软状态呢？相对于原⼦性⽽⾔，要求多个节点的数据副本都是⼀致的，这是⼀种 “硬状态”。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可⽤性，即允许系统在多个不同节点的数据副本存在数据延时。
2PC
安静的近义词Two-Pha Commit，事务的提交过程分成了两个阶段来进⾏处理。
2PC 阶段⼀
1.事务询问
协调者向所有的参与者询问，是否准备好了执⾏事务，并开始等待各参与者的响应。
1.执⾏事务
各参与者节点执⾏事务操作，并将 Undo 和 Redo 信息记⼊事务⽇志中
1.各参与者向协调者反馈事务询问的响应
如果参与者成功执⾏了事务操作，那么就反馈给协调者 Yes 响应，表⽰事务可以执⾏；如果参与者没有成功执⾏事务，就返回 No 给协调者，表⽰事务不可以执⾏。营销思路
2PC 阶段⼆
数码摄像机在阶段⼆中，会根据阶段⼀的投票结果执⾏ 2 种操作：执⾏事务提交，中断事务。
执⾏事务提交步骤如下：
·发送提交请求：协调者向所有参与者发出 commit 请求。·事务提交：参与者收到 commit 请求后，会正式执⾏事务提交操作，并在完成提交之后释放整个事务执⾏期间占⽤的事务资源。·反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。·协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
中断事务步骤如下：
·发送回滚请求：协调者向所有参与者发出 Rollback 请求。·事务回滚：参与者接收到 Rollback 请求后，会利⽤其在阶段⼀种记录的Undo 信息来执⾏事务回滚操作，并在完成回滚之后释放在整个事务执⾏期间占⽤的资源。·反馈事务回滚结果：参与者在完成事务回滚之后，想协调者发送 Ack 信息。·中断事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
从上⾯的逻辑可以看出，⼆阶段提交就做了2个事情：投票，执⾏。
举个例⼦：
⼆阶段提交看起来确实能够提供原⼦性的操作，但是不幸的事，⼆阶段提交还是有⼏个缺点的：
1、同步阻塞问题。执⾏过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三⽅节点访问公共资源不得不处于阻塞状态。
杭州财经大学
2、单点故障。由于协调者的重要性，⼀旦协调者发⽣故障。参与者会⼀直阻塞下去。尤其在第⼆阶段，协调者发⽣故障，那么所有的参与者还都处于锁定事务资源的状态中，⽽⽆法继续完成事务操作。（如果是协调者挂掉，可以重新选举⼀个协调者，但是⽆法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不⼀致。在⼆阶段提交的阶段⼆中，当协调者向参与者发送commit请求之后，发⽣了局部⽹络异常或者在发送commit请求过程中协调者发⽣了故障，这回导致只有⼀部分参与者接受到了commit请求。⽽在这部分参与者接到commit请求之后就会执⾏commit操作。但是其他部分未接到commit请求的机器则⽆法执⾏事务提交。于是整个分布式系统便出现了数据部⼀致性的现象。
4、⼆阶段⽆法解决的问题：协调者再发出commit消息之后宕机，⽽唯⼀接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产⽣了新的协调者，这条事务的状态也是不确定的，没⼈知道事务是否被已经提交。
由于⼆阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷，所以，研究者们在⼆阶段提交的基础上做了改进，提出了三阶段提交。
3PC
三阶段提交（Three-pha commit），也叫三阶段提交协议（Three-pha commit protocol），是⼆阶段提交（2PC）的改进版本。
与两阶段提交不同的是，三阶段提交有两个改动点。
·引⼊超时机制。同时在协调者和参与者中都引⼊超时机制。·在第⼀阶段和第⼆阶段中插⼊⼀个准备阶段。保证了在最后提交阶段之前各参与节点的状态是⼀致的。
也就是说，除了引⼊超时机制之外，3PC把2PC的准备阶段再次⼀分为⼆，这样三阶段提交就有CanCommit、PreCommit、DoCommit 三个阶段。
CanCommit阶段
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执⾏事务提交操作。然后开始等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其⾃⾝认为可以顺利执⾏事务，则返回Yes响应，并进⼊预备状态。否则反馈No
PreCommit阶段
协调者根据canCommit阶段参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。
幼儿园早操儿歌
假如协调者在CanCommit阶段从所有的参与者获得的反馈都是Yes响应，那么就会执⾏事务的预执⾏。
1.发送预提交请求 协调者向参与者发送PreCommit请求，并进⼊Prepared阶段。
2.事务预提交 参与者接收到PreCommit请求后，会执⾏事务操作，并将undo和redo信息记录到事务⽇志中。
3.响应反馈 如果参与者成功的执⾏了事务操作，则返回ACK响应，同时开始等待最终指令。
假如canCommit阶段有任何⼀个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执⾏事务的中断。
1.发送中断请求 协调者向所有参与者发送abort请求。
最霸气的帝王诗
2.中断事务 参与者收到来⾃协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执⾏事务的中断。
doCommit阶段
该阶段进⾏真正的事务提交，也可以分为以下两种情况。
执⾏提交
1.发送提交请求 协调接在preCommit阶段收到参与者发送的ACK响应，那么他将从预提交状态进⼊到提交状态。并向所有参与者发送doCommit请求。
2.事务提交 参与者接收到doCommit请求之后，执⾏正式的事务提交。并在完成事务提交之后释放所有事务资源。
3.响应反馈 事务提交完之后，向协调者发送Ack响应。
肉炒青豆4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。
