理解最大努力通知
最大努力通知也是一种分布式事务的方案。
账户充值：
交互流程：
- 账户系统调用充值系统接口。
- 充值系统完成支付处理向账户系统发起充值结果，若通知失败，则充值系统按策略进行重复通知。
- 账户系统接收到充值结果通知修改充值状态。
- 账户系统未接收到通知会主动调用充值系统的接口查询充值结果。
目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
- 有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
- 消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
最大努力通知与可靠消息一致性的不同
-
解决方案思想不同
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
-
两者的业务应用场景不同
可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。
最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
-
技术解决方向不同
可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。
最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）。
解决方案
采用MQ的ACK机制就可以实现最大努力通知。
流程：
-
发起通知方将通知发给MQ。使用普通消息机制将通知发给MQ。注意：如果消息没有发出去可由接收通知方主动请求发起通知方查询业务执行结果。
-
接收通知方监听MQ。
-
接收通知方接收消息，业务处理完成回应ACK。
-
接收通知方若没有回应ack则MQ会重复通知。
MQ会按照时间间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔（如果MQ采用Rocketmq，在broker中可进行配置），直到达到通知要求的时间窗口上限。
-
接收通知方可通过消息校对接口来校对消息的一致性。
方案二：
也是利用MQ的ACK机制，与方案1不同的是应用程序向接收通知方发送通知
交互流程：
-
发起通知方将通知发给MQ。
使用可靠消息一致中的事务消息保证本地事务与消息的原子性，最终将通知先发给MQ。
-
通知程序监听MQ，接收MQ的消息。
方案1中接收通知方直接监听MQ，方案2中由通知程序监听MQ。
通知程序若没有回应ack则MQ会重复通知。
-
通知程序通过互联网接口协议（如http、webservice）调用接收通知方案接口，完成通知。
通知程序调用接收通知方案接口成功就表示通知成功，即消费MQ消息成功，MQ将不再向通知程序投递通知消息。
-
接收通知方可通过消息校对接口来校对消息的一致性。
方案1和方案2的不同点：
- 方案1中接收通知方与MQ接口，即接收通知方案监听MQ，此方案主要应用与内部应用之间的通知。
- 方案2中由通知程序与MQ接口，通知程序监听MQ，收到MQ的消息后由通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知，例如支付宝，微信的支付结果通知。
最大努力通知方案是分布式事务中对一致性要求最低的一种，适用于一些最终一致性时间敏感度低的业务；
最大努力通知方案需要实现以下功能：
- 消息重复通知机制
- 消息校对机制。
标签：方案,最大,努力,通知,充值,MQ,消息,接收 来源： https://www.cnblogs.com/isfjh/p/16191812.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。