一、协调者
监听一个业务在处理过程中的全部操作，收集每一个操作的结果，如果全部通过就提交，出现异常就回滚。
二、XA规范
1、这三个角色的交互
2、什么是XA规范？
3、XA规范的实现
三、2PC提交协议
1、举例表示：西式婚礼
角色：牧师、新郎、新娘。
① 第一阶段
牧师主持，新郎新娘说誓言，说我愿意（表示执行相关业务逻辑），发送给牧师。
② 第二阶段
如果都愿意，牧师就主持交换戒指，俩人交换戒指（表示提交事务）。
如果有一个不愿意，牧师就主持回去考虑考虑（表示事务回滚）。
2、图例表示
① 第一阶段 分别执行业务逻辑，但是还不提交
② 第二阶段 提交或者回滚
3、2PC的缺点
① 单点故障
② 阻塞资源
③ 数据不一致
四、3PC提交协议
1、什么是3PC提交协议？
在2PC的执行逻辑中，如果服务A在执行的时候异常了，还需要事务协调者主持回滚，整体做了一次无用功，造成性能的浪费。
3PC在此基础上做了一个优化，只有服务判断自己可以执行业务时才开始做业务逻辑，减少了出错的步骤。
2、3PC提交协议的超时机制
每个参与者都有超时机制。
can commit：如果参与者超时后没接收到协调者的指令，那就什么都不做。
pre commit：如果执行了业务代码之后，超时没接收到下一步指令就回滚。
do commit：如果超时就自动提交。
五、TCC（Try | Confirm Cancel）解决方案
TCC表示两步操作：Try - 尝试操作，CC - 确认或取消。
如果确认 - 第二步提交操作。
如果取消 - 第二步操作应当是第一步操作的逆操作。
六、消息队列+本地事件表+定时任务解决方案
七、最大努力通知方案
在执行到第4步时，如果支付宝发现通知回调失败，就会触发重复通知机制，将同一个通知重复发送多次，达到设定的阈值后才停止发送。
如果最后实在通知不到我方支付系统，也预留了消息校对接口，我方支付系统可以主动调用该接口，确认是否支付成功了。
这里有两个方案搭配使用：重复通知机制、消息校对机制，尽最大努力通知给另一方。
