分布式事务
两阶段提交协议
分布式事务是指会涉及到操作多个数据库的事务，在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调
xa就是x/open dtp定义的交易中间件与数据库之间的接口规范，交易中间件用它来通知数据库事务的开始、结束已经提交、回滚等。
xa接口函数由数据库厂商提供
二阶段提交(tow-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。
通常，二阶段提交也被称为是一种协议。在分布式系统中，每个节点虽然可以知晓自己的操作成功或失败，却无法知道其他节点的操作是成功或是失败。当一个事务跨越多个节点时，为了保持事务的acid特性，需要引入一个作为协调者的组件来统一掌控所有节点的操作结果，并最终指示这些节点是否要把操作结果进行真正的提交
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交还是终止
准备阶段
事务协调者给每个参与者发送准备消息，每个参与者要么直接返回失败，要么在本地执行事务，写本地的日志，但不能提交
提交阶段
如果协调者收到了参与者的失败消息或超时，直接给每个参与者发送回滚消息；否则，发送提交消息；
参与者根据协调者的指令执行或者回滚操作，释放所有事务处理过程中使用的锁资源
缺点
- 同步阻塞问题：执行工程中参与节点都是事务阻塞型的
- 单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去
- 数据不一致：在提交阶段时，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，导致只有一部分参与者接收到了commit请求。于是整个分布式系统便出现了数据一致性的问题
- 数据状态不确定：协调者发出commit消息后宕机，而唯一接受到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否已经提交
三阶段提交协议
三阶段提交协议(three-phase commit)，是二阶段提交的改进版
与二阶段提交不同的是：
- 引入超时机制，同时在协调者和参与者中都引入超时机制
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。也就是说，处理引入超时机制之外，3pc把2pc的准备阶段一分为二
CanCommit阶段
协调者向参与者发送commit请求，参与者如果可以提交就返回yes响应，否则返回no响应
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以继续进行
- 如果协调者从所有的参与者获得的反馈都是yes响应，那么就会执行事务
- 如果有任意一个参与者向协调者发送no响应，或者等待超时之后，那么执行事务中断
doCommit阶段
该阶段进行真正的事务提交，主要包含
- 协调者发送提交事务请求
- 参与者提交事务
- 参与者响应反馈
- 协调者确认完成事务
柔性事务
在分布式领域基于cap理论以及base理论，有人就提出了柔性事务的概念
CAP理论
- 一致性
- 可用性
- 分区容忍性
BASE理论
- 基本可用
- 柔性状态
- 最终一致性
柔性事务分类
- 两阶段型：分布式事务两阶段提交，对应技术上的xa、jta/jts。这时分布式环境下事务处理的经典模式
- 补偿型：ttc(try/confirm/cancel)型事务可用归为补偿型。服务器a发起事务，服务器b参与事务，服务器a的事务如果执行顺利，那么事务a就先提交，如果b也执行顺利b也提交，整个事务就算完成。但b执行失败，b本身回滚，这时a已经提交，所以需要一个补偿操作，将已经提交的任务a进行反操作
- 异步确保型：通过将一系列同步的事务操作变为基于消息执行的异步操作，避免了分布式事务中的同步阻塞操作的影响
- 最大努力通知型：这时分布式事务中要求最低的一种，也可以通过消息中间件实现，与签名异步确保型操作不同的一点是，在消息由mq server投递到消费者之后，允许在达到最大重试次数后正常结束事务
