分布式事务

系统A

commit

返回应答

本地事务

超时重查

上游系统和消息中间件之间是异步通讯，目的是为了提高并发度。消息中间件和下游系统之间采用同步通讯，是因为此时并发度的要求不高，同步通讯的话系统实现简单。

向下游投递失败

处理任务

投递消息Retry *N

基于可靠消息服务的分布式事务

处理任务B

span style=\

消息中间件

失败消息表

超过最大重试次数

消息中间件扮演着分布式事务协调者的角色。任务A完成到B完成之间存在时间差，此期间内系统数据不一致。但经过短暂的时间后，数据又会保持一致，满足BASE理论。

确认应答

TCC（二阶段型、补偿型）

本地消息表

任务处理A成功

此时系统又处于一致性状态，因为A任务和B任务都没有执行。

更多介绍请移步：https://juejin.im/post/5aa3c7736fb9a028bb189bca#heading-16

超时重传机制确保消息可靠投递。实际中，可设置重试次数和时间间隔，次数耗尽后转人工干预。

最大努力通知（定期校对）

发送消息

系统B

rollback

下游返回应答失败

超时重传

返回commit/rollback

上游系统向消息中间件发送消息失败：A）任务处理和插入本地消息表在同一个事务中完成。B）消息发送者多次重试仍失败，需人工介入，确定是上游系统本身的问题，还是消息中间件的问题，或是网络的问题等。C）

消息发送者

消息持久化

投递消息

X

任务处理A失败

普通流程

A系统须提供查询接口，返回3种结果：commit/rollback/processing超时询问能防止上游系统因传输中丢失commit/rollback信息而导致的数据不一致，并降低上游系统的阻塞时间，提升并发度。

定期校对

Try：尝试待执行的业务这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源Confirm：执行业务这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。Cancel：取消执行的业务若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。

      消息投递失败后，为什么不回滚消息，而是不断尝试重新投递？牵涉到分布式事务系统的实现成本问题。A commit后便去做其它事情了，如回滚，需要A预先提供接口，增加开发成本；A还要分出资源处理回滚；另外，系统A和消息中间件还耦合了；

任务处理A

消息中间件向下游系统投递消息失败：A）Retry次数和Retry间隔，超最大Retry次数后写入失败消息表。B）消息中间件提供失败消息查询接口，供下游系统查询并消费，即“定期校对”C）失败消息表增长很快，说明下游系统出问题，需人工介入

A任务失败流程

commit/rollback

插入本地消息表

commit和rollback都可能失败

消息直接丢弃

理想流程

Broker