分布式事务知识点

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次，最后不行就放弃。