分布式事务-最大努力通知方案

概述

什么是最大努力通知

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

交互流程

1. 账户系统调用充值系统接口。
2. 充值系统完成支持处理向账户系统发起结果通知。
   若通知失败，则充值系统按策略进行重复通知。
3. 账户系统接收到充值结果通知修改充值状态。
4. 账户系统未收到通知会主动调用充值系统的接口查询充值结果。

通过上边的例子我们总结最大努力通知方案的目标：
目标：发起通知方通过一定机制最大努力将业务处理结果通知到接收方。
具体包括：

• 有一定的消息重复通知机制。
  因为接收方可能没有接收到通知，此时要有一定的机制对消息重复通知。
• 消息校对机制
  如果尽最大努力也没有通知到接收方，或者接收方消费消息后再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。

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

1. 解决方案思想不同
   可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收方，消息的可靠性关键有发起方来保证。
   最大努力通知，发起通知方尽最大努力将业务处理结果通知给接收方，但是可能消息接收不到，此时需要接收方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
2. 两者的业务应用场景不同
   可靠消息一致性关注的是交易过程的事务一致性，以异步的方式完成校验。
   最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
3. 技术解决方向不同
   可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。
   最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠机制。可靠机制是，最大努力将消息通知给接收方，当消息无法被接收时，由接收方主动查询消息（业务处理结果）。

解决方案

通过对最大努力通知的理解，采用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中接收方与MQ接口，即接收方监听MQ，此方案主要应用于内部应用之间的通知。
• 方案2中由通知程序与MQ接口，通知程序监听MQ，收到MQ的消息后由通知程序通过互联网接口协议调用接收方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。