分布式事务

协议规范

1 XA规范

此规范定义了TM，RM，AP，定义了它们之间交互的接口规范，大部分RDBMS如mysql都实现了XA规范，可作为RM使用
实现：具体交互细节在2pc 3pc协议中体现
2pc：prepare/commit，未收到commit一直等(资源独占的性能问题，阻塞，不一致，单点)
3pc：canCommit/preCommit/doCommit，多了询问和参与者超时机制，第三阶段参与者超时未收到commit/abort直接提交，解决了2pc的诸多问题
3pc是不是还有不一致问题？有，但是概率很低，即未收到abort直接提交-这种情况极少见，前面已经事先询问了，事务提交的概率是极大的，才敢直接提交

2 TCC

try：业务检查，资源预留
confirm ：业务执行，使用try阶段的资源
cancel：取消try阶段预留的资源
很像2pc，如果try全部成功，那么confirm(confirm失败重试)，如果有一个try失败，那么cancel(cancel失败重试)，即confirm/cancel需幂等设计
2pc在db资源上的锁定(阻塞)，tcc上升到业务层面上资源的预留
理解：我在try阶段对所有人都检查并预留了资源，那么我认为事务一定能成功，当然了有人挂了，所以confirm可能暂时失败，我会反复重试直到它起来并成功，有人检查都不通过，那我只能放弃，让大家把预留的资源释放了
上面理解可得，最终一致性，柔性事务
弊端：业务侵入大，需自己实现try/confirm/cancel，即业务能感知2个阶段
举例：冻结金额为资源，confirm是使用了资源，try是释放取消了资源，最后资源都是0
try：A大于30，冻结金额-30，B检查通过，冻结金额+30
confirm：A使用冻结金额-30(预留资源)金额改为70，冻结金额归0，B同理
try：A小于30，检查不通过，B检查通过，冻结金额+30
cancel：A，B冻结金额归0

3 SAGA

长事务分解成多个子事务来处理，执行方式：编排/协调
每个子事务Ti对应一个补偿动作Ci(用于撤销)，遇到任何一个子事务失败反向撤销之前的子事务，如下
T1, T2, T3, …, Tn
T1, T2, …, Tj, Cj,…, C2, C1，其中0 < j < n

实现

1 seta

seta不仅有xa，tcc，saga的模式，还有种at模式(auto transaction)，at对业务无入侵-注解实现

2 事务消息

本地消息表：实现事务消息的一种手段，rocketmq通过半消息实现事务消息（发半消息+发commit/rollback+反查接口）
保证了本地事务和发送消息的原子性，但下游不能保证一定能接到消息并事务成功，算是半个解决方案吧，
但如果我们能保证消息可靠性（投递成功一定能消费到）+ 本地事务失败的处理，那么下游就能和上游一致
消息可靠性（投递成功一定能消费到）：消息写入并同步到磁盘后+消息同步到其他副本节点后 才返回成功
本地事务失败的处理：
1 不ack/offset commit，那么无法往后消费了，不能这样
2 放本地内存重试-机器宕了咋办
3 mq隔断时间重试，如rocketmq的重试队列，推荐

3 最大努力通知

最终一致性，柔性事务，时间敏感度低，多用于内外部系统保持一致，如ac-bgw和外部系统，通过外部系统多次异步通知+内部系统主动查询，为了实现多次异步通知，外部系统弄了个mq