系统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
