二阶段
sql操作，不提交
2.调用服务B
三方回调
补偿机制：做标识、做记录（通知的具体事项、或者需要执行的sql操作）
TM
8.关闭事务，通知TX-Manager
提交后反馈
预备提交
执行业务
TCCTry，Confirm，Cancel
定时任务
yes/no
做日志记录
比对日志文件和数据库，如果数据库中没有，那提交事件就会redo操作，向数据库里放
消息队列+事务表不适合数据量特别大的场景
提交
三方支付
订单系统
两阶段提交-2pc （不能保证一致性）
2-3 调用服务时，在http请求头部加入参数 GroupID
2-2 创建事务组
协调机制 本质：代理了DataSoure的机制。保持了请求和db链接的对应。（存储了DB的Connection链接，先不真正的Close，为了其他阶段的回滚可以找到其db链接）
1
支付系统
3.添加事务组、服务B
消息队列
xa：事务管理器TM、资源管理器RM
TM，RM都加了超时的机制
支付系统RM
。。。
1-1 启动TM
4-3将状态该为已处理
提交or回滚
代理连接：DataSourceAspect、LcnConnectionProxy
第二阶段：第一阶段都是yes才执行第二阶段成功后TM释放资源
3-2插入时间表
（RM）服务BTX-Client
4-1读取状态为已接收的记录
db
服务N、Tx-Client
真正提交
消息队列内容就是事件表的内容
刚性事务ACID柔性事务base
String messge = 消息来了try { 入库 mq.ack} catch () { mq.recovery();//下次消息还可以消费}
TM单点故障，会让程序失效：资源阻塞、性能降低(断网，导致RM没收到提交，一直占用资源)数据不一致（一个提交后TM挂了，或者网路不通)
4.调用N个服务
try都ok
redis存事务组补偿信息
插入：事务表（支付成功事件，状态：新建）
长连接
订单系统RM
Transaction Manager
undo反向操作、回滚
服务A、Tx-Client
第一阶段：询问查看是否都通
插入事务表状态：已接收
订单服务RM、TC
3-1 提交or回滚
三阶段提交-3pc（不能保证一致性）只是降低2pc的灾难概率
2-1分布式事务请求
第三阶段：第二阶段都是yes才执行第三阶段成功后TM释放资源
2-2更新事件表的状态为已发送
一阶段
事务没有提交那就会undo操作
要用分布式定时任务处理
设置ActiveMq的死信队列用监听死信队列，然后做补偿处理
2-3发送给消息队列
3-1监听消息
操作数据库，先要操作日志文件
支付流水记录更新更新：支付流水表
询问
3-2 通知RM/TC提交or回滚
支付服务RM、TC
Cance订单系统/支付系统逆操作
2-1查询状态为新建的事件
请求
db本地事务如何保证：锁、redo、undoACID：原子性、一致性、隔离性、持久性AD（日志文件）CI（锁）Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。 （要么都做，要么都不做。注重过程）Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。 （做完两件事后，数据是一致的。注重结果）Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）。Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
2-4 添加到事务组
消息消费者
支付流水：已支付
joiner，running
1-2启动RM/TC建立长连接
第二阶段：TM锁定资源
https://github.com/codingapi/tx-lcn
响应返回
4-2执行本地业务
6.服务N响应返回
统计
数据库redo
5.添加事务组、服务N
事务通知模块
有问题
三方回调过来：将三方数据保存下来
（TM）TX-Manager
Eureka
操作的原子性：2-1 db2-2 db2-3 发送（失败整体回滚）
自带事务中间件的 如：mysql，不用TCC，用LCN没必要，增加业务代码复杂性
物流系统
spring如何看源码：全局搜索注解：LcnTransaction
TX-Manager
第一阶段：TM锁定资源
3-3 ack
ResourceManager
LCNLock（锁定事务单元）、confirm（确认事务）、notify（通知事务）
通过 消息事件的id，主键约束，来保证消息重复消费的问题。
1.创建一个空的事务组，生成一个GroupID
（RM）服务ATX-Client
Try
定时任务：taskquartzschedule
修改订单已支付
Confirm订单系统/支付系统提交
发起者 startingcreate
更新订单表的记录
服务B、Tx-Client
TM事务协调者
第三方支付
积分系统
假关闭数据库连接
