分布式事务
在分布式架构的情况下，将之前的关系型数据库提供的事务称之为本地事务，解决分布式系统中存在事务方案进而称之为分布式事务。
2PC、3PC方案实现的事务能保证强一致性，我们称之为刚性事务；TCC和可靠消息方案实现的事务只能保证最终一致性，那么我们称之为柔性事务。
刚性事务可以实现强一致性，但性能不高；柔性事务性能较高，但是只能实现弱一致性。
✈️向大佬们学习：
2PC 3PC（强一致性事务）
2PC（两阶段提交：准备-提交，Seata的AT模式就是2PC）
3PC（三阶段提交：询问-准备-提交）
总结：需要全局事务协调者，准备阶段就需要锁定各个参与者的资源；可以保持强一致性，但是性能大大降低！！
TCC（try-confirm-cancel）
TCC流程如下：
总结：最终保证数据一致性，在业务层实现事务控制，灵活性好。缺点是开发成本高，各业务需要实现try/confirm/cancel三个操作。
Ref：还不懂分布式事务：带你深入剖析TCC实现原理、 详解分布式事务解决方案之TCC机制
TCC电商场景介绍
可靠消息最终一致性方案（本地消息表、MQ事务消息）
可靠消息方案通过消息生产、消息存储、消息投递三个阶段的可靠性，实现最终数据一致性，这种方案又有两种实现方式，一种是基于本地消息表实现，另外一种是基于事务消息实现。其实这种本地消息表和消息队列方案不冲突，因为消息队列的消息能够100%投递不丢失也可以用本地消息表实现。
1. 本地消息表实现方案
本地消息表的核心思路就是将分布式事务拆解为本地事务和发送MQ消息，跟RocketMQ事务消息类型，不过实现起来更为简单，当然缺点就是数据延迟性更高。
Ref：分布式事务最简单的实现方案：一文详解本地消息表、 本地消息表的设计与实现
本地消息表实现流程：本地事务和下游业务（MQ异步）的一致性
本地消息表实现流程：本地事务和下游业务（rpc同步）的一致性
2. RocketMQ事务消息实现方案
事务消息和普通消息的区别在于，事务消息发送到消息队列中后处于prepared状态，是对消费者不可见的，等到事务消息的状态更改为可消费状态后，下游系统的消费者才可以消费到消息。
MQ事务消息实现流程如下：
Ref：分布式事务解决方案到底有哪些
📢 这两种方案上流程方向都是不可逆的，原则上 上游系统事务成功提交，下游系统的事务则也一定要成功，业务不能回滚，如果要是出现消息消费失败，则只能进行不断的重试，直到成功为止。
应用场景
场景1：针对交易内部的权益保障（如充值、购买、礼物赠送等）
场景2：权益中心给用户发放多个权益；比如ABC三个权益，先记三个发放操作记录init，同一事务 -> 分别调用rpc -> 更新记录success； 失败补偿：定时job 或 MQ通知。
