分布式事务
数据库事务的基本特性
我们知道事务有4个非常重要的特性，即我们常说的 ACID：
Atomicity（原子性）：是说事务是一个不可分割的整体，所有操作要么全部成功，要么全部失败；
Consistency（一致性）：是说事务执行前后，数据从一个状态到另一个状态必须是一致的，比如A向B转账（A、B的总金额就是一个一致性状态），不能出现A扣钱了，B却没收到钱的情况；
Isolation（隔离性）：多个并发事务之间互相隔离，不能互相干扰。这里的并发事务指的是两个事务操作了同一份数据的情况。而对于并发事务操作同一份数据的隔离性问题，则是要求不能出现脏读（事务A不能读取到事务B未提交的数据）、幻读（事务A读取数据进行更新操作时，不允许事务B先更新掉这条数据）的情况。而为了解决这个问题，常用的手段就是加锁了，对于数据库来说就是通过数据库的相关锁机制来保证；
Durablity（持久性）：事务完成后，对数据库的更改是永久保存的
什么是分布式事务
其实分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只是分布式事务相对于本地事务而言其表现形式有很大的不同
一致性协议 2PC
什么是 2PC
2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议.
两个阶段过程：
准备阶段（Prepare phase）：
事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交（Undo 日志是记录修改前的数据，用于数据库回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件）
提交阶段（commit phase）：
如果事务管理器收到了参与者的执行失败消息或者超时的时候，直接给每个参与者发送回滚（Rollback）消息；否则发送提交（Commit）消息；
参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中所使用的锁资源。注意，必须在最后阶段释放锁资源。
协议说明：
顾名思义，二阶段提交就是将事务的提交过程分成了两个阶段来进行处理。流程如下：
成功执行事务提交流程
阶段一:
事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
执行事务 (写本地的Undo/Redo日志)
各参与者向协调者反馈事务询问的响应
总结: 各个参与者进行投票是否让事务进行.
阶段二:
发送提交请求：
协调者向所有参与者发出 commit 请求。
事务提交：
参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
反馈事务提交结果：
参与者在完成事务提交之后，向协调者发送 Ack 信息。
完成事务：
协调者接收到所有参与者反馈的 Ack 信息后，完成事务
什么是 Ack
ACK 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误
中断事务流程
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务
阶段一:
事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
执行事务 (写本地的Undo/Redo日志)
各参与者向协调者反馈事务询问的响应
总结: 各个参与者进行投票是否让事务进行.
阶段二:
发送回滚请求：
协调者向所有参与者发出 Rollback 请求。
事务回滚：
参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
反馈事务回滚结果：
参与者在完成事务回滚之后，向协调者发送 Ack 信息。
中断事务：
协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
2PC 优缺点
优点：
原理简单，实现方便
缺点：
同步阻塞
二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题
协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致
假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit 请求之前自身发生了奔溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题
过于保守
如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话 这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
一致性协议 3PC
什么是 3PC
3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由 CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
阶段一：CanCommit
① 事务询问
协调者向所有的参与者发送一个包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
② 各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的包含了事务内容的 canCommit 请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈 Yes 响应，并进入预备状态，否则反馈 No 响应
阶段二：PreCommit
协调者早得到所有参与者响应后，会根据结果有两种操作的情况：执行事务提交 / 中断事务
执行事务提交
加入所有参与反馈的都是 Yes，那么就会执行事务预提交
执行事务预提交分为3个步骤：
① 发送预提交请求
协调者向所有参与者节点发出 preCommit 请求，并进入 prepared 阶段
② 事务预提交
参与者收到 preCommit 请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中
③ 各参与者向协调者反馈事务执行的结果
若参与者成功执行了事务操作，那么反馈 Ack
中断事务
若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务
中断事务分为2个步骤：
① 发送中断请求
协调者向所有参与者发出 abort 请求
② 中断事务
无论是收到来自协调者的 abort 请求或者等待协调者请求过程中超时，参与者都会中断事务
阶段三：do Commit
该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：
执行事务提交
① 发送提交请求
进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送 doCommit 请求
② 事务提交
参与者接收到 doCommit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源
③ 反馈事务提交结果
参与者在完成事务提交后，向协调者发送 Ack 响应
④ 完成事务
协调者接收到所有参与者反馈的 Ack 消息后，完成事务
中断事务
① 发送中断请求
协调者向所有的参与者节点发送abort请求
② 事务回滚
参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整 个事务执行期间占用的资源。
③ 反馈事务回滚结果
参与者在完成事务回滚后，向协调者发送Ack消息。
④ 中断事务
协调者接收到所有参与者反馈的Ack消息后，中断事务。
注意：一旦进入阶段三，可能会出现 2 种故障：
- 协调者出现问题
- 协调者和参与者之间的网络故障
如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交
2PC对比3PC
首先对于协调者和参与者都设置了超时机制
在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收 到参与者的消息则默认失败，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
通过 CanCommit、PreCommit、DoCommit 三个阶段的设 计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。
PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
注：3PC协议并没有完全解决数据不一致问题。