2PC, 3PC 分布式提交协议简述

事务

这里主要是指狭义一点的事务即数据库事务，事务一般含有以下一些特点

原子性（Atomicity）: 事务全部被执行或不被执行

一致性（Consistency）：事务在执行事务前后，数据库处于一致性状态

隔离性（Isolation）：指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务所打断

持久性（Durablity）：事务一旦提交，则对数据库状态的变更是永久的

分布式事务

指的是事务的参与者，支持者的服务器，资源服务器以及事务管理器分别位于分布式系统的不同几点之上。

CAP定理

一个分布式系统不可能同时满足一致性（C），可用性（A），分区容错性（P）

一致性：指的是数据在多个副本中是否能够保持一致的特性

可用性：系统提供的服务必须处于可用的状态，对于用户的每一个请求总要在有限的时间内返回结果

分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务

BASE理论

基本可用 （Basically Avaliable）：在分布式系统中出现不可预知故障的时候，允许损失部分可用性

弱状态 （Soft state）：允许系统中的数据存在中间状态，并认为该中间状态不会印象系统的整体可用性

最终一致性 （Eventually consistent）：系统中所有的副本，在经过一段时间的同步后，最终能够达到一个一致的状态。五种变种：因果一致性、读己之所写、会话一致性、单调一致性、单调读一致性

2PC与3PC

在分布式系统中，每一个机器节点虽然都能够明确知道自己在进行事务操作过程中的结果是成功还是失败，但是却无法直接获取到其他分布式节点的操作结果

2PC 二阶段提交

阶段一：提交事务请求

事务询问

协调者向所有的参与制发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应

执行事务

各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中

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

如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行，反之，反馈No响应

阶段二：执行事务提交

协调者根据参与者的反馈情况决定是否进行事务提交操作。有两种可能性

执行事务提交

如果协调者从所有的参与者获得的反馈都是yes响应，那么就会执行事务提交

发送提交请求

协调者向所有参与者节点发出Commit请求

事务提交

参与者接受到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占 用的事务资源

完成事务

协调者接收到所有参与者反馈的Ack消息后，完成事务

中断事务

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

发送回滚请求

协调者向所有参与者节点发出Rollback请求

事务回滚

参与者接受到Rollback请求后，会利用其在阶段一种记录的Undo信息来执行事务回滚操作，并在完成回滚后释放在整个事务执行期间占用的资源

反馈事务回滚结果

参与者在完成事务回滚之后，向协调者发送Ack消息

中断事务

协调者接收到所有参与者反馈的Ack消息后，完成事务中断

优缺点：

优点：原理简单，实现方便

缺点： 同步阻塞，单点问题，脑裂（数据不一致），太过保守

同步阻塞（所谓‘同步’,意思是在发出一个信息之后，等待有回应才返回，同理可推‘异步’；而阻塞是指程序在等待消息结果时的状态，消息结果没返回，那么当前线程就会被吊起，同理可推‘非阻塞’）

在二阶段提交的执行阶段，所有参与该事务的操作的逻辑都处于阻塞状态

单点问题

在二阶段中，如果协调者出现问题，那么整个流程将无法运转。更为严重的是，如果协调者是在阶段而中出现问题，那么其他事务参与者将一直处于锁定事务资源的状态中。

数据不一致

在执行事务提交的时候，出现了局部网络异常或者协调者在尚未发送完Commit请求之前吱声发生了崩溃，导致只有部分参与者收到了Commit请求。一些参与者完成事务的提交，一些无法进行事务的提交，整个系统出现不一致情况

太过保守

如果某些参与者出现故障而导致协调者出现无法获取所有的响应信息，那么协调者就可能会依据超时机制判断是否需要中断事务。缺少了容错机制，一个节点错误导致整个事务失败