分布式-事务
一、协调者
监听一个业务在处理过程中的全部操作，收集每一个操作的结果，如果全部通过就提交，出现异常就回滚。
二、XA规范
AP：Application
TM：协调者 - 事务管理器
RM：资源管理器（DB）
1、这三个角色的交互
2、什么是XA规范？
X/Open DTP定义的：事务协调者与数据库之间的接口规范（即接口函数），事务协调者用它通知数据库事务的开始、结束、提交、回滚等。
XA接口函数由数据库厂商提供。
类似于JDBC，大家都遵守这个规则。
3、XA规范的实现
分布式集群的情况下，一般加一层代理来充当TM，实现对事务的支持。
二阶段提交协议（2PC）和三阶段提交协议（3PC）就是根据这一思想衍生出来的。
2PC主要保证了分布式事务的原子性。
三、2PC提交协议
1、举例表示：西式婚礼
角色：牧师、新郎、新娘。
① 第一阶段
牧师主持，新郎新娘说誓言，说我愿意（表示执行相关业务逻辑），发送给牧师。
② 第二阶段
如果都愿意，牧师就主持交换戒指，俩人交换戒指（表示提交事务）。
如果有一个不愿意，牧师就主持回去考虑考虑（表示事务回滚）。
2、图例表示
① 第一阶段 分别执行业务逻辑，但是还不提交
② 第二阶段 提交或者回滚
如果都成功，就提交事务，释放资源。
释放占用的数据库连接资源。
如果有一个异常，那么就回滚
3、2PC的缺点
① 单点故障
问题描述：事务协调者掉线会出问题
解决办法：协调者需要做集群。
② 阻塞资源
问题描述：占用数据库连接，降低相响应效率。需要等待分布式事务提交后才能释放连接。
解决办法：核心思想是不占用数据库连接实现回滚。可以先保留操作之前的数据，直接提交。如果接收到协调者发送的提交指令，就什么都不做，如果收到回滚指令，就使用之前保留的数据覆盖新数据。这也是seata对2PC的优化。
③ 数据不一致
问题描述：在事务提交阶段如果有一部分业务提交失败了，就会导致数据不一致。
解决办法：核心思想是修正错误数据。可以使用可复用的脚本检查数据异常，发现异常就回滚或者向前走一步，保持数据对齐。
四、3PC提交协议
1、什么是3PC提交协议？
在2PC的执行逻辑中，如果服务A在执行的时候异常了，还需要事务协调者主持回滚，整体做了一次无用功，造成性能的浪费。
3PC在此基础上做了一个优化，只有服务判断自己可以执行业务时才开始做业务逻辑，减少了出错的步骤。
can commit：检查是否可执行，只有所有服务都返回yes才能开始做业务逻辑。
pre commit：开始执行业务逻辑。
do commit：提交 / 回滚。
can commit 的结果
1、成功 - 走pre commit
所有服务都返回yes。
2、失败 - 走abort commit
有参与者返回no。
协调者等待超时。
参与者没接收到协调者的指令。
2、3PC提交协议的超时机制
每个参与者都有超时机制。
can commit：如果参与者超时后没接收到协调者的指令，那就什么都不做。
pre commit：如果执行了业务代码之后，超时没接收到下一步指令就回滚。
do commit：如果超时就自动提交。
五、TCC（Try | Confirm Cancel）解决方案
TCC表示两步操作：Try - 尝试操作，CC - 确认或取消。
如果确认 - 第二步提交操作。
如果取消 - 第二步操作应当是第一步操作的逆操作。
六、消息队列+本地事件表+定时任务解决方案
通过以上这三个组件，可以实现将一个大的分布式事务拆分成多个小的单体事务，分散了业务处理逻辑，如果异常就降低了回滚的代价，同时缩短了对用户的响应时间。
七、最大努力通知方案
在执行到第4步时，如果支付宝发现通知回调失败，就会触发重复通知机制，将同一个通知重复发送多次，达到设定的阈值后才停止发送。
如果最后实在通知不到我方支付系统，也预留了消息校对接口，我方支付系统可以主动调用该接口，确认是否支付成功了。
这里有两个方案搭配使用：重复通知机制、消息校对机制，尽最大努力通知给另一方。