分布式一致性算法学习

二阶段提交(2PC)

阶段一：提交事务请求

1. 事务询问。协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
2. 执行事务：各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中
3. 各参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。

上述内容在形式上近似是协调者组织各参与者对一次事务操作的投票表态过程，因此二阶段提交协议阶段一也被称为“投票阶段”，即各参与者投票表明是否要继续执行接下去的事务提交操作

阶段二：执行事务提交

阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务提交操作，正常情况下，包含以下两种可能。
执行事务提交
假如协调者从所有参与者获得的反馈都是Yes响应，那么就会执行事务提交。

1. 发送提交请求：协调者向所有参与节点发出Commit请求
2. 事务提交：参与者收到Commit请求后，会正式执行事务提交操作，并完成提交之后释放在整个事务执行期间占用的事务资源
3. 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送Ack消息
4. 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务
   

中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送回滚请求：协调者向所有参与者节点发送Rollback请求；
2. 事务回滚：参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源
3. 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息
4. 中断事务：协调者接收到所有参与者反馈的Ack消息后，完成事务中断
   

优缺点：

• 优点：原理简单，实现方便
• 缺点：同步阻塞、单点问题、数据不一致(脑裂)、太过保守

1. 同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作
2. 单点问题：协调者的角色在整个二阶段提交协议中起到了非常重要的作用，一旦协调者出现问题，那么二阶段提交流程将无法运转，更为严重的是，如果协调者在阶段二中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
3. 数据不一致(脑裂)：在二阶段提交协议的阶段二，即执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求。于是，这部分收到了Commit请求的参与者就会进行事务的提交，二而其他没有收到Commit请求的参与者则无法进行事务提交，于是整个分布式系统便出现了数据不一致现象。
4. 太过保守：如果在协调者指示参与者进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，这样的策略显得太过保守。

三阶段提交(3PC)

三阶段提交是2PC的改进版，将二阶段提交协议的“提交事务请求”过程一分为二，形成了由CanCommit、PreCommit和 do Commit三个阶段组成的事务处理协议。

阶段一：CanCommit

1. 事务询问：协调者向所有参与者发送一个包含事务内容的CanCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 参与者向协调者反馈事务询问的响应：参与者在接收到来自协调者的CanCommit请求后，正常情况下，如果自身认为可以顺利执行事务，那么就反馈给协调者Yes响应，进入预备状态，否则反馈No响应。

阶段二：PreCommit

在阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，包含两种可能：
执行事务预提交
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务预提交。

1. 发送预提交请求：协调者向所有参与者节点发出PreCommit请求，并进入Prepared阶段；
2. 事务与提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中；
3. 各参与者向协调者反馈事务执行的响应：如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交(commit)或中止(abort)。

中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送中断请求：协调者向所有参与者节点发送abort请求；
2. 中断事务：无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。

阶段三：doCommit

该阶段将进行真正的事务提交，会存在以下两种可能的情况。
执行提交

1. 发送提交请求：进入这一阶段，假设协调者处于正常的工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送doCommit请求；
2. 事务提交：参与者收到doCommit请求后，会正式执行事务提交操作，并完成提交之后释放在整个事务执行期间占用的事务资源
3. 反馈事务提交结果：参与者在完成事务提交之后，想协调者发送Ack消息
4. 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务

中断事务
进入这一阶段，假设协调者正处于正常工作状态，并且有任意一个参与者向协调者反馈了No响应，或者等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1. 发送中断请求：协调者向所有参与者节点发送abort请求；
2. 事务回滚：参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源
3. 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息
4. 中断事务：协调者接收到所有参与者反馈的Ack消息后，完成事务中断

需要注意的是，一旦进入阶段三，可能会存在以下两种故障：

• 协调者出现问题；
• 协调者和参与者之间的网络出现故障

无论出现那种情况，最终会导致参与者无法接收到来自协调者的doCommit或者abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务的提交。

优缺点
优点：相较于二阶段提交协议，三阶段提交协议最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致；
缺点：三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。

Paxos算法

一致性算法需要保证一下几点：

• 在这些被提出的提案中，只有一个会被选定；
• 如果没有提案被提出，那么就不会有被选定的提案；
• 当一个提案被选定后，进程应该可以获取被选定提案信息；

一致性的安全性需求：

• 只有被提出的提案才能被选定；
• 只能有一个值被选定；
• 如果某个进程认为某个提案被选定了，那么这个提案必须是真的被选定的那个；

一致性算法中的角色：

• Proposer: 接收客户的请求，代表客户向Acceptor发起提案
• Acceptor: 监听来自Proposer的提案，并决定是否接受和回复
• Learner: 提案被接受后，提交并执行提案的内容

提案选定的假设：
Proposer向一个Acceptor集合发送提案，同样，集合中每个Acceptor都可能会批准(Accept)该提案，当有足够多的Acceptor批准这个提案的时候，我们就认为该提案被选定了。那么，什么是足够呢？

• 假定足够多的Acceptor是整个Acceptor集合的一个子集，并且让这个集合大得可以包含Acceptor集合中的大多数成员，因为任意两个包含大多数Acceptor的子集至少有一个公共成员；
• 另外再规定，每一个Acceptor最多只能批准一个提案，那么就能保证只有一个提案被选定了。

推导过程：

• P1: 一个Acceptor必须批准它接收到的第一个提案
• P2: 如果编号M₀、Value值为V₀的提案(即[M₀, V₀])被选定了，那么所有比编号M₀更高的，且被选定的提案，其Value值必须也是V₀。
• P2a: 如果编号为M₀、Value值为V₀的提案(即[M₀, V₀])被选定了，那么所有比编号M₀更高的，且被Acceptor批准的提案，其Value值必须也是V₀。
• P2b: 如果一个提案[M₀, V₀]被选定后，那么之后任何Proposer产生的编号更高的提案，其Value值都为V₀。
• P2c: 对于任意的M_n和V_n，如果提案[M_n, V_n]被提出，那么肯定存在一个由半数以上的Acceptor组成的集合S，满足一下两个条件中的任意一个：(1) S中不存在任何批准过编号小于M_n的提案Acceptor；(2) 选取S中所有Acceptor批准的编号小于M_n的提案，其中编号最大的那个提案其Value值是V_n。

S为任何包含半数以上的Acceptor集合

提案产生的条件：

• 要么S中没有Acceptor批准过编号小于M_n的任何提案；
• 要么S中的所有Acceptor批准过的所有编号小于M_n的提案中，编号最大的那个提案的Value值为V_n。

Proposer生成提案

1. Proposer选择一个新的提案编号M_n，然后想某个Acceptor集合的成员发送请求，要求改集合中的Acceptor做出如下回应：(1)向Proposer承诺，保证不再批准任何小于M_n的提案；（2）如果Acceptor已经批准过任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于M_n但为最大编号的那个提案的值。(成为编号为M_n的提案的prepare请求)
2. 如果Proposer收到了来自半数以上的Acceptor的相应结果，那么它就可以产生编号为M_n、Value值为V_n的提案，这里的V_n是所有相应中编号最大的提案的Value值。当然还存在另一种情况，就是半数以上的Acceptor都没有批准过任何提案，即响应中不包含任何的提案，那么此时V_n值就可以由Proposer任意选择。

Acceptor批准提案
Acceptor可能会接收到来自Proposer的两种请求，分别是prepare请求和Accept请求

1. Prepare请求：Acceptor可以再任何时候响应一个Prepare请求；
2. Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求

Paxos算法陈述：
综合以上，结合Proposer和Accept对提案的处理逻辑，可以得到如下类似于两阶段提交的算法执行过程。
阶段一

1. Proposer选择一个提案编号M_n，然后向Acceptor的某个超过半数的子集成员发送编号为M_n的Prepare请求；
2. 如果一个Acceptor收到一个编号为M_n的Prepare请求，且编号M_n大于该Acceptor已经响应的所有Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于M_n的提案

举个例子来说，假定一个Acceptor已经响应过所有Prepare请求对应的提案编号分别为1、2、…、5和7，那么该Acceptor在接收到一个编号为8的Prepare请求后，就会将编号为7的提案作为响应反馈给Proposer

阶段二

1. 如果Proposer收到来自半数以上的Acceptor对于其发出的编号为M_n的Prepare请求的响应，那么它就会发送一个针对[M_n, V_n]的提案Accept请求给Acceptor。注意，V_n的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么它就是任意值。
2. 如果Acceptor收到这个针对[M_n, V_n]提案的Accept请求，只要该Acceptor尚未对编号大于M_n的Prepare请求做出响应，它就是可以通过这个提案。

paxos继续学习：https://www.cnblogs.com/shaohef/p/4499881.html