一致性协议-2PC，3PC，Paxos

一致性协议

2PC

2PC即二阶段提交，是计算机网络尤为是在数据库领域内，为了使基于分布式系统架构下的全部节点在进行事务处理过程当中可以保持原子性和一致性而设计的一种算法。
协议说明：二阶段提交协议是将事务的提交过程分红两个阶段来进行处理。
阶段一：提交事务请求
投票阶段
阶段二：执行事务提交

执行阶段

优缺点

优势：原理简单，实现方便
缺点：同步阻塞、单点问题、脑裂、太过保守

同步阻塞

在二阶段提交的执行过程当中，全部参与该事务操做的逻辑都处于阻塞状态

单点问题

协调者的角色在整个二阶段提交协议中起到了很是重要的做用，是单点的。

数据不一致

在二阶段提交协议的阶段二，即执行事务提交的时候，commit请求并未发送到全部的参与者。

太过保守

若是在协调者指示参与者进行事务提交询问的过程当中，参与者出现故障而致使协调者始终没法获取到全部参与者的响应信息的换，这时协调者只能依靠自身的超时机制来判断是否须要中断事务，这样的策略显得比较保守。换句话说，二阶段提交协议没有涉及较为完善的容错机制，任意一个节点的失败都会致使整个事务的失败。

3PC

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

阶段一：CanCommit

1. 事务询问
2. 各参与者向协调者反馈事务询问的响应

阶段二：PreCommit，两种状况
执行事务预提交：协调者从全部的参与者得到的反馈都是yes响应，那么就会执行事务预提交。

1. 发送预提交请求
2. 事务预提交
3. 各参与者向协调者反馈事务执行的响应

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

1. 发送中断请求
2. 中断事务

阶段三：doCommit，两种状况

执行提交：

1. 发送提交请求
2. 事务提交
3. 反馈事务提交结果
4. 完成事务

中断事务

1. 发送中断请求
2. 事务回滚
3. 反馈事务回滚结果
4. 中断事务

须要注意，一旦进入阶段三，可能会存在如下两种故障。

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

不管出现那种状况，最终都会致使参与者没法及时接受到来自协调者的doCommit或者abort请求，针对这样的异常状况，参与者都会在等待超时以后，继续进行事务提交。

优缺点

优势：相较于2PC，3PC最大的有点就是下降了参与者的阻塞范围，而且可以在单点故障后继续达成一致。
缺点：容易出现数据不一致性

Paxos

分布式一致性协议是一种基于消息传递且具备高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。
Paxos算法须要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致性，而且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

问题描述

假设有一组能够提出提案的进程集合，那么对于一个一致性算法来讲须要保证如下几点：

• 在这些被提出的提案中，只有一个会被选定
• 若是没有填被提出，那么就不会有被选定的提案
• 当一个提案被选定后，进程应该能够获取被选定的提案信息

对于一致性来讲，安全性需求以下：

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

从总体来讲，Paxos算法的目标就是要保证最终有一个提案会被选定，当提案被选定后，进程最终也能获取到被选定的提案。

有三种参与角色，咱们用Proposer，Acceptor和Learner来表示

假设不一样参与者之间能够经过收发消息来进行通讯，那么：

• 每一个参与者以任意的速度执行，可能会由于出错而中止，也可能会重启。同时，即便一个提案被选定后，全部的参与者也都有可能失败或重启，所以除非那些失败或重启的参与者能够记录某些信息，不然将没法肯定最终的值。
• 消息在传输过程当中可能会出现不可预知的延迟，也可能会重复或丢失，可是消息不会损坏，即消息内容不会被篡改

推到过程

P1：一个Acceptor必须批准它收到的第一个提案。


由于以上两种状况，在P1的基础上，再加上一个提案
被选定须要由半数以上的Acceptor批准的需求暗示着一个Acceptor必须可以批准不止一个提案。

咱们使用一个全局的编号来惟一标识每个被Acceptor批准的提案，当一个具备某Value值的提案被半数以上的Acceptor批准后，咱们就认为该Value被选定了，此时咱们也认为该提案被选定了。

P2：若是编号为M0、Value值为V0的提案被选定了，那么全部比编号M0更高的，且被选定的提案，其Value值必须也是V0.
一个提案要被选定，其首先必须被至少一个Acceptor批准，所以咱们能够经过知足以下条件来知足P2。
P2a：若是编号为M0、Value值为V0的提案被选定了，那么全部比编号M0更高的，且被Acceptor批准的提案，其Value值必须也是V0。

P2b：若是一个提案【M0,V0】被选定后，那么以后任何Proposer产生的编号更高的提案，其Value值都为V0。
由于一个提案必须在被Proposer提出后才能被Acceptor批准，所以P2b包含了P2a，进而包含了P2。
论证P2b成立。

P2c：对于任意的Mn和Vn，若是提案【Mn，Vn】被提出，那么确定存在一个由半数以上的Acceptor组成的集合S，知足一下两个条件中的任意一个。

• S中不存在任何批准过编号小于Mn的提案，其中编号最大的那个提案其Value值是Vn。

Proposer生整天
Proposer选择一个新的提案编号Mn，而后向某个Acceptor集合的成员发送请求，要求该集合中的Acceptor作出以下回应。

• 向Proposer承诺，保证再也不批准任何编号小于Mn的提案
• 若是Acceptor已经批准过任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于Mn但为最大编号的哪一个提案的值。

Acceptor批准提案

• Prepare请求：Acceptor能够在任什么时候候响应一个Prepare请求
• Accept请求：在不违背Accept现有承诺的前提下，能够任意响应Accept请求。

算法优化

尽量地武略Prepare请求

算法陈述

阶段一

1. Proposer选择一个提案编号Mn，而后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。
2. 若是一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的全部Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案做为响应反馈给Propser，同时该Acceptor会承诺不会在批准任何编号小于Mn的提案。

阶段二

1. 若是Proposer收到来自半数以上的Acceptor对于其发出的编号Mn的Prepare请求的响应，那么它就会发送一个针对[Mn，Vn]提案的Accept请求给Acceptor。
2. 若是Acceptor收到这个针对[Mn，Vn]提案的Accept请求，只要该Acceptor还没有对编号大于Mn的Prepare请求作出响应，它就能够经过这个提案。