分布式事务解决方案之四：最大努力通知

（自学笔记）

--------------------

6.1. 什么是最大努力通知

最大努力通知也是一种解决分布式事务的方案，下边是一个是充值的例子：

交互流程 :

1 、账户系统调用充值系统接口

2 、充值系统完成支付处理向账户系统发起充值结果通知

 

若通知失败，则充值系统按策略进行重复通知

3 、账户系统接收到充值结果通知修改充值状态。

4 、账户系统未接收到通知会主动调用充值系统的接口查询充值结果。

 

通过上边的例子我们总结最大努力通知方案的目标：

目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。

具体包括：

1 、有一定的消息重复通知机制。

因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。

2 、消息校对机制。

如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息

信息来满足需求。

最大努力通知与可靠消息一致性有什么不同？

1 、解决方案思想不同

可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知

方来保证。

最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接

收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。

2 、两者的业务应用场景不同

可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。

最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。

3 、技术解决方向不同

可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。

最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消

息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。

 

6.2. 解决方案

通过对最大努力通知的理解，采用 MQ 的 ack 机制就可以实现最大努力通知。

方案 1 ：

本方案是利用 MQ 的 ack 机制由 MQ 向接收通知方发送通知，流程如下：

1 、发起通知方将通知发给 MQ 。

使用普通消息机制将通知发给 MQ 。

注意：如果消息没有发出去可由接收通知方主动请求发起通知方查询业务执行结果。（后边会讲）

2 、接收通知方监听 MQ 。

3 、接收通知方接收消息，业务处理完成回应 ack 。

4 、接收通知方若没有回应 ack 则 MQ 会重复通知。

MQ 会 按照间隔 1min 、 5min 、 10min 、 30min 、 1h 、 2h 、 5h 、 10h 的方式，逐步拉大通知间隔 （如果 MQ 采用

rocketMq ，在 broker 中可进行配置），直到达到通知要求的时间窗口上限。

5 、接收通知方可通过消息校对接口来校对消息的一致性。

 

 

方案 2 ：

本方案也是利用 MQ 的 ack 机制，与方案 1 不同的是应用程序向接收通知方发送通知，如下图：

 

交互流程如下：

1 、发起通知方将通知发给 MQ 。

使用可靠消息一致方案中的事务消息保证本地事务与消息的原子性，最终将通知先发给 MQ 。

2 、通知程序监听 MQ ，接收 MQ 的消息。

方案 1 中接收通知方直接监听 MQ ，方案 2 中由通知程序监听 MQ 。

通知程序若没有回应 ack 则 MQ 会重复通知。

3 、通知程序通过互联网接口协议（如 http 、 webservice ）调用接收通知方案接口，完成通知。

通知程序调用接收通知方案接口成功就表示通知成功，即消费 MQ 消息成功， MQ 将不再向通知程序投递通知消

息。

4 、接收通知方可通过消息校对接口来校对消息的一致性。

 

方案 1 和方案 2 的不同点：

1 、方案 1 中接收通知方与 MQ 接口，即接收通知方案监听 MQ ，此方案主要应用与内部应用之间的通知。

2 、方案 2 中由通知程序与 MQ 接口，通知程序监听 MQ ，收到 MQ 的消息后由通知程序通过互联网接口协议调用接收

通知方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。