分布式事务常用方案

XA：分布式事务基础协议：事务协调者和本地资源管理器

1.2pc提交协议（刚性事务，强一致性）

2pc两阶段提交协议基本过程：
1.准备阶段：（投票阶段）检查库存是否足够
2.提交阶段 ：根据参与者的准备阶段返回值进行判断是回滚还是提交事务

角色：
事务协调器+事务参与者

优缺点：

优点：
1.各事务参与者的事务由数据库自身实现，业务侵入少
缺点：
1.同步阻塞，需要等待其中参与者执行最长的事务时间，并发能力下降
2.事务管理器故障，导致整个分布式事务无法使用
3.网络问题可能导致事务协调器没有通知到所有事务参与者
4.占用比较高的资源

通信故障解决：

2pc事务协调者通信故障如何解决
1.协调者设定超时时间，超过时间默认参与者执行失败
2.协调者心跳机制，定期判断参与者是否存活
3.预备提交，参与者发送消息到协调者，如果协调者没有收到消息，默认失败通知参与者回滚
4.备份协调者，监控协调者状态
5.消息队列，参与者将消息写到mq，事务协调者去mq获取事务日志

2. 3PC三阶段提交

优化2PC：同步阻塞和单点故障问题

1.conCommit阶段：协调者通知每个参与者是否可以提交，都返回yes进入下一个阶段
2.preCommit阶段（预提交）：执行事务不提交，都成功则进入下一个阶段（写binlog）；协调者和参与者都引入了超时机制
3.doCommit阶段：提交或回滚阶段；此阶段失败会执行undolog；如果是网络问题超时参与者没有收到协调者的提交信息，也会被默认提交；

3.AT事务（基于2pc做了补偿）自动事务

工作流程：

第一阶段：此阶段生成before 快照->执行sql（写undolog relaylog）->after 快照->对数据行加行锁

第二阶段：成功

第二阶段：失败

优点：业务代码无入侵
缺点：
第二阶段事务失败可能会有脏数据，需要记录下来人为干预

4.TCC（try confirm cancel）

不会像2PC和3PC阻塞资源，引入补偿机制，把资源转换成业务逻辑形式提高系统性能

try阶段：对资源检测及锁定
comfirm阶段：执行真正的业务；失败后会进行重试；需要考虑幂等性
cancel：失败进行业务回滚；需要考虑幂等性

try阶段：
锁定资源：设置预备状态或冻结某一部分资源；如冻结库存，预增积分等

comfirm阶段：
提交：冻结库存清零，实际库存更改；预加积分进行实际累加

cancel阶段：
预备阶段的数据进行恢复：如冻结减库存进行回退；预增积分进行清零等

优点：性能高
缺点：实现复杂；每个步骤都需要代码实现

5.saga

思想：复杂的事务拆分成多个小事务

流程：

T1完成事务后会以事件方式通知下一个事务T2

实现方式：1.基于事件 2,基于命令的方式

5.1 基于事件：

回滚：某个服务失败，会生成一个回滚事件，其他执行完事务的服务监听并且进行补偿（程序员写代码）回滚；

优缺点：

优点：简单容易理解；各参与方无直接沟通，完全解耦。没有事务协调器；比较适合只有2-4个服务参与的分布式事务场景
缺点： 参与者较多时，容易比较失控。各个参与方可以随意监听对方的消息，以至于最后没人知道到底有哪些系统监听哪些消息。更严重的是，可能产生环形监听，如两个服务相互监听对方产生的事件；

基于命令的方式就出现了

5.1 基于命令：

特点：1 .定义一个协调器服务，2.不需要事件监听

6.最大努力通知
适用于外部系统，敏感度低的场景；
1.A向银行B发起扣钱请求
2.B扣钱
3.B扣钱成功后通知A扣钱成功