本地音讯表机制会在数据库中寄存一个本地事务音讯表，在停止本地事务操作的同时将操作形状插入到本地事务音讯表。音讯插入成功后再调用其他效劳，假设调用成功就修正这条本地音讯的形状；假设调用失败则不停重试，下游接口需求保证幂等性。

本地音讯表机制是一种最大努力通知思想。

这里以支付效劳和会计效劳为例展开引见本地音讯表方案。大约流程：用户在支付效劳完成了支付订单支付成功后，此时会调用会计效劳的接口生成一条原始的会计凭证到数据库中。全体流程如图：

残缺流程：

在支付库中参加一张音讯表来记载支付音讯，即用户支付成功后往这张音讯表插入一条支付成功的音讯，形状为“发送中”。这里要保证了本地事务的强分歧性（支付逻辑和插入音讯表的音讯组成了一个强分歧性的事务，要么同时成功，要么同时失败）。

完成第1步的逻辑后，再向mq的PAY_QUEUE队列中投递一条支付音讯，这条支付音讯的内容跟保存在支付库音讯表的音讯内容分歧。

会计效劳监听到这条音讯了，会计效劳处置消费逻辑末尾生成会计凭证。

会计凭证生成后，再反向向mq投递一条消费成功的音讯到ACC_QUEUE队列。

支付效劳监听到会计效劳消费成功的音讯，将本地音讯表的音讯形状改为“已发送”。

音讯恢复系统每隔一段时间去本地音讯表中捞取形状为“发送中”的音讯，然后重新投递到mq的PAY_QUEUE队列中。

假设音讯恢复系统重新投递同一条音讯到达一定阈值，则记载报警和通知人工处置。

总结

本地音讯表机制的优点是树立成本比较低，但也存在两个缺陷：

本地音讯表与业务耦合在一同，很难完成通用性，无法独自运维管理。

本地音讯表是基于数据库来做的，在高并发下是有功用瓶颈的。

基于事务音讯机制

无论是2PC&3PC还是TCC、本地音讯事务，基本都遵守XA协议的思想。即这些方案本质上都是事务协调者协调各个事务参与者的本地事务的进度，使一切本地事务共同提交或回滚，最终达成全局已执行的特性。在协调的进程中，协调者需求搜集各个本地事务的以后形状，并依据这些形状收回下一阶段的操作指令。

但这些全局事务方案由于操作繁琐、时间跨度大，或许在全局事务时期会排他地锁住相关资源，使得整个散布式系统的全局事务的并发度不会太高。这很难满足电商等高并发场景对事务吞吐量的要求，因此互联网效劳提供商探求出了很多与XA协议背道而驰的散布式事务处置方案。其中应用音讯中间件完成的最终分歧性全局事务（事务音讯事务）就是一个经典方案。

基于事务音讯机制

普通音讯是无法处置本地事务执行和音讯发送的分歧性成绩的。由于音讯发送是一个网络通讯的进程，发送音讯的进程就有能够出现发送失败、或许超时的状况。超时有能够发送成功了，有能够发送失败了，音讯的发送方是无法确定的，所以此时音讯发送方无论是提交事务还是回滚事务，都有能够不分歧性出现。

处置这个成绩，需求引入事务音讯，事务音讯和普通音讯的区别在于事务音讯发送成功后，处于prepared形状，不能被订阅者消费，等到事务音讯的形状更改为可消费形状后，下游订阅者才可以监听到次音讯。

事务音讯的发送处置流程如下：

事务发起者预先发送一个事务音讯。MQ系统收到事务音讯后，将音讯耐久化，音讯的形状是“待发送”，并给发送者一个ACK音讯。

事务发起者假设没有收到ACK音讯，则取消本地事务的执行；假设收到了ACK音讯，则执行本地事务。

执行本地事务后，依据结果发送给MQ系统提交或回滚央求。

本地事务执行终了后，发给MQ的通知音讯有能够丧失。所以支持事务音讯的MQ系统有一个定时扫描逻辑，扫描出形状依然是“待发送”形状的音讯，并向音讯的发送方发起讯问，讯问这条事务音讯的最终形状如何并依据结果更新事务音讯的形状。因此事务的发起方需求给MQ系统提供一个事务音讯形状查询接口。

MQ系统收到音讯通知后，假设提交央求，则将音讯更改为“可消费”供订阅者消费；假设事务执行回滚，则删除该事务音讯。

假设事务音讯的形状是“可发送”，则MQ系统向下游参与者推送音讯，推送失败会不停重试。

下游参与者收到音讯后，执行本地事务，本地事务假设执行成功，则给MQ系统发送ACK音讯；假设执行失败或给MQ发送ACK的音讯丧失，则MQ系统会继续推送给音讯。

总结

基于事务音讯机制完成了最终分歧性，适用于异步更新的场景，并且对数据实时性要求不高的中央。

比照本地音讯表完成方案，不需求创立本地音讯表，也不需求依赖本地数据库事务了，所以这种方案更适用于高并发的场景。

RocketMQ可以直接支持消费环境运用基于事务音讯机制，其他音讯中间件（例如Kafka，RabbitMQ等）需求自研封装一个牢靠音讯效劳。

(责任编辑：admin)