一、TCC
分布式事务的一种解决方案:
- Try :锁定资源或预留
- Confirm:正式执行资源
- Cancel:发生异常解冻资源
业务侵入性,每个操作需要改造成3个接口,进行处理。 cancel的处理通常会相当复杂
- 支付,交易的用相关;
二、可靠消息最终一致性
使用阿里的RocketMQ来实现消息事务。
1.A系统发送 pre消息
2.A系统执行本地事务,成功后发送confirm消息;失败回滚本地消息,并回滚刚刚那个 prepared消息
- 如果发送了confirm消息后,B就会获取到改消息
- mq 会⾃动定时轮询所有 prepared 消息回调你的接⼝,主动查询状态,是否需要confirm
- 如果系统B执行失败后,那就不断重试;如果 B 系统本地回滚后,想办法通知系统 A 也回滚;或者是发送报警由⼈⼯来⼿⼯回滚和补偿
三、2PC/XA
有一个事务管理器的概念,用来协调多个数据库(资源的)事务。事务管理器,先问每个数据库准备好了没有,如果数据都OK ,那么都统一执行。否则回滚事务。
适合单应用跨库解决方案;
TCC出现网络不通、XA一致性如何保存
四、最大努力通知方案
1.A系统执行完事务后,发送到MQ
2.会有个专⻔消费 MQ 的最⼤努⼒通知服务,这个服务会消费 MQ 然后写⼊数据库中记录 下来,或者是放⼊个内存队列也可以,不断重试调用B系统
3.如果B系统执行失败,那么就最大努力尝试,执行N次就放弃
五、本地消息表
大致处理流程:
1、A系统执行事务之后,往本地表插入一条数据消息
2、A系统将事务消息发送到MQ
3、B系统接收到消息,也会存储到本地消息表,并执行业务操作,如果已经处理过,就忽略
4、如果B系统执行成功之后,就会更新本地事务消息表,及 A消息表的状态;
5、如果B系统执行失败后,A系统会定时扫描待处理的消息,再次发送到MQ
但是这个严重依赖于数据库,不适合高并发场景。
参考《石杉架构笔记》