1、分布式事务的实现
- XA方案
- TCC方案(部分严格一致性场景)
- 本地消息表
- 可靠消息最终一致性方案(推荐)
- 最大努力通知方案
2、两阶段提交方案/XA方案
XA方案即两阶段提交,有一个事务管理器的概念,负责协调多个数据库的事务。
第一阶段:事务协调器要求每个设计到事物的数据库预提交此操作,并反映是否可以提交;
第二阶段:事务协调器要求每个数据库提交数据。
比较适合单个应用,由于严重依赖于数据库层面来搞定复杂的事务,效率很低,不适合高并发的场景。
这个方案很少使用,一般微服务内部不允许操作别的服务的库。
3、TCC方案
Try阶段:这个阶段是对各个服务的资源做检测以及对资源进行锁定或者预留;
Confirm阶段:这个阶段是在各个服务中执行实际的操作;
Cancel阶段:如果任何一个服务的业务方法执行出错,进行补偿,对于成功执行的业务进行回滚操作。
一般在需要严格保证分布式事务全部成功的场景使用,但是严重依赖于写代码来回滚和补偿,而且需要各个业务执行时间都比较短。
4、本地消息表
1)在本地事务操作同时,插一条数据到消息表
2)A系统将这个消息发送到MQ
3)B系统接受到消息后,在一个事务里往自己本地消息表里插一条数据,同时执行其他业务,如果消息已经被处理过了,事务会回滚
4)B系统执行成功后会更新自己的本地消息表及A系统消息表状态
5)如果B系统处理失败,就不会更新消息表状态,A系统会定时扫描自己的消息表,如果有未处理的消息,会再次发送到MQ中
6)保证最终一致性,A系统会不断重试,直到B系统成功为止。
5、可靠消息最终一致性方案
直接基于MQ来实现,比如RocketMQ
1)A系统先发送一个prepared消息到MQ,prepared消息发送失败那么就直接取消执行;
2)如果消息发送成功就执行本地事务,执行成功则通知MQ发送确认消息,否则通知MQ回滚消息;
3)B系统接收到确认消息,执行本地事务;
4)MQ会定时轮询所有prepared消息,如果A系统没有发送确认的消息,是继续重试还是回滚。这里可以避免本地事务执行成功,确认消息发送失败的情况;
5)系统B事务失败则会不断重试直到成功;如果是资金类重要业务要进行回滚,则会通知A进行回滚,或者发送报警由人工处理。
6、最大努力通知方案
1)系统A本地事务执行完后,发送消息到MQ;
2)有个专门消费MQ的最大努力通知服务,这个服务会消费MQ然后写入数据库中记录或者放入内存队列,然后调用B系统接口;
3)系统B执行成功就ok,如果执行失败,最大努力通知服务会定时尝试调用系统B,反复N次,最后不行就放弃。