常见的分布式事务四大解决方案:2PC、TCC、可靠消息最终一致性、最大努力通知。前三种解决方案我们都分别从理论和实战两个维度做了讲解。今天我们来说说最大努力通知这个解决方案的理论部分。
1. 什么是最大努力通知
先来看看下面这个充值的例子:
交互流程如下:
(1)账户系统调用充值系统接口发起支付请求。
(2)充值系统完成支付处理向账户系统发起充值结果通知。若通知失败,则充值系统按策略进行重复通。
(3)账户系统接收到充值结果通知修改充值状态。
(4)账户系统未接收到通知会主动调用充值系统的接口查询充值结果。
通过上边的例子我们总结最大努力通知方案的目标是:发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括以下两点:
(1)有一定的消息重复通知机制:因为接收通知方可能没有接收到通知,此时要有一定的机制对消息重复通知。
(2)消息校对机制:如果尽最大努力也没有通知到接收方,或者接收方消费消息后要再次消费,此时可由接收方主动向通知方查询消息信息来满足需求。
2. 和可靠消息一致性的不同点
(1)解决方案思想不同
可靠消息一致性,发起通知方需要保证将消息发出去,并且将消息发到接收通知方,消息的可靠性关键由发起通知方来保证。
最大努力通知,发起通知方尽最大的努力将业务处理结果通知为接收通知方,但是可能消息接收不到,此时需要接收通知方主动调用发起通知方的接口查询业务处理结果,通知的可靠性关键在接收通知方。
(2)两者的业务应用场景不同
可靠消息一致性关注的是交易过程的事务一致,以异步的方式完成交易。
最大努力通知关注的是交易后的通知事务,即将交易结果可靠的通知出去。
(3)技术解决方向不同
可靠消息一致性要解决消息从发出到接收的一致性,即消息发出并且被接收到。
最大努力通知无法保证消息从发出到接收的一致性,只提供消息接收的可靠性机制。可靠机制是:最大努力的将消息通知给接收方,当消息无法被接收方接收时,由接收方主动查询消息(业务处理结果)。
3. 解决方案
通过对最大努力通知的理解,我们很容易就想到使用MQ的ack机制来实现最大努力通知。
3.1 方案1
流程如下:
(1)发起通知方使用普通消息将通知发给MQ。
(2)接收通知方监听 MQ,并接收消息,业务处理完成回应ack。
(3)接收通知方若没有回应ack则MQ会重复通知。(RocketMQ会按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式,逐步拉大通知间隔,直到达到通知要求的时间窗口上限。)
(4)接收通知方可通过消息校对接口来校对消息的一致性。
3.2 方案2
流程如下:
(1)发起通知方将通知发给MQ。(使用可靠消息一致方案中的事务消息保证本地事务与消息的原子性,最终将通知先发给MQ)
(2)通知程序监听 MQ,接收MQ的消息。(若通知程序若没有回应ack则MQ会重复通知)
(3)通知程序通过互联网接口协议(如http、webservice)调用接收通知方案接口,完成通知。(通知程序调用接收通知方案接口成功就表示通知成功,即消费MQ消息成功,MQ将不再向通知程序投递通知消
息。)
(4)接收通知方可通过消息校对接口来校对消息的一致性。
3.3 两个方案的不同点
(1)方案1中接收通知方与MQ接口,即接收通知方案监听 MQ,此方案主要应用与内部应用之间的通知。
(2)方案2中由通知程序与MQ接口,通知程序监听MQ,收到MQ的消息后由通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知,例如支付宝、微信的支付结果通知。