分布式事务解决方案小结

1、Seata AT模式

优势：
1、业务无入侵，只需要在分布式事务开始的方法上加@GlobalTransactional注解即可.
2、一阶段直接提交事务，不会一直占用资源
缺陷：AT模式流程图如下：
一阶段
业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。核心在于对业务sql进行解析，转换成undo_log，并同时入库，流程图：

二阶段
分布式事务操作成功，则TC通知RM异步删除undolog

分布式事务操作失败，TM向TC发送回滚请求，RM 收到协调器TC发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。

由上面的流程图可以看出缺陷有以下几点：
1、一阶段时有多次数据库操作
2、当某个分支事务失败需要回滚时，会去检查 后置镜像，所以设计了一个全局锁，将该条记录锁住
3、当回滚失败时，系统会报错，需要手动补偿处理
4、仅支持关系型数据库
手动补偿处理方案：
1、查看undolog表，找到回滚失败的数据，手动更新业务数据
2、删除该条undolog表数据

Seata XA模式

优点:
1、不需要在微服务数据库创建undolog表
2、业务无入侵，只需要在分布式事务开始的方法上加@GlobalTransactional注解即可.
3、分支事务有每个微服务的RM自己管理
缺点：
1、一阶段未commit，会一直占用资源

Seata TCC模式

优点：
1、不会一直持有资源的锁,性能比AT高
2、支持非关系型数据库
3、自由度比较高，可以在commit和rollback接口中自定义实现，甚至可以在commit接口中做异步来削峰
缺点：
1、业务代码入侵较大，原本的一个接口要拆成三个接口
2、1.5.1 版本之前存在空回滚、幂等、悬挂等问题
空回滚、幂等、悬挂等问题解决方案：
1.5.1 版本之后：
@TwoPhaseBusinessAction注解中加入useTCCFence = true,用于解决TCC幂等，悬挂，空回滚问题，需增加日志表tcc_fence_log
其他的TCC实现方案如：Byte-TCC，TCC-Transation等实现思路基本一致

柔性事务 本地消息表

以新用户注册送优惠券为例,流程如下：

让用户信息与增加优惠券日志的操作在同一个事务中，再利用定时任务定时扫描日志表发送到MQ，通过保证MQ消息的可靠性保证优惠券一定发放成功。

柔性事务 事务消息

在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，解决Producer端的消息发送与本地事务执行的原子性问题。

执行流程如下 ：
Producer即MQ发送方，本例中是用户服务，负责新增用户。MQ订阅方即消息消费方，本例中是优惠券服务，负责新增优惠券。
1、Producer发送事务消息
Producer（MQ发送方）发送事务消息至MQ Server，MQ Server将消息状态标记为Prepared（预览状态），注意此时这条消息消费者（MQ订阅方）是无法消费到的。
2、MQ Server回应消息发送成功
MQ Server接收到Producer发送给的消息则回应发送成功表示MQ已接收到消息。
3、Producer执行本地事务（可以多插一张log表，回查的时候查询这张log表来确定本地事务是否执行成功）
Producer端执行业务代码逻辑，通过本地数据库事务控制。
本例中，Producer执行添加用户操作。
4、消息投递
若Producer本地事务执行成功则自动向MQ Server发送commit消息，MQ Server接收到commit消息后将“增加优惠券消息”状态标记为可消费，此时MQ订阅方（优惠券服务）即正常消费消息；
若Producer 本地事务执行失败则自动向MQ Server发送rollback消息，MQ Server接收到rollback消息后将删除“增加优惠券消息”。
MQ订阅方（优惠券服务）消费消息，消费成功则向MQ回应ack，否则将重复接收消息。这里ack默认自动回应，即程序执行正常则自动回应ack。
5、事务回查
如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问同组的其他Producer来获取事务执行状态，这个过程叫事务回查。MQ Server会根据事务回查结果来决定是否投递消息。
以上主干流程已由RocketMQ实现，对用户则来说，用户需要分别实现本地事务执行以及本地事务回查方法，因此只需关注本地事务的执行状态即可。

柔性事务 最大努力通知

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，是分布式事务中对一致性要求最低的一种，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。
最大努力通知型的实现方案，一般符合以下特点：
1、不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。
2、定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。
最大努力通知方案需要实现如下功能：
1、消息重复通知机制。
2、消息校对机制。
场景：比如公司内部实现了短信平台，所有的业务方都接入这个短信平台，来实现发送短信的功能。