先上图：
1. 首先会发送事务消息给MQ Server
2. MQ 会回复一个发送成功的消息，此时MQ Server并不能投递消息，因此还没有收到发送的确认
3. MQ发起方会执行本地事务。
4. 执行完以后就发送commit 或者Rollback 如果是commit的话就开始投递消息； 如果是Rollback，MQ Server 就会删除消息，不投递。
如果 执行完之后发送没有收到怎么办？
5. 未收到确认时候，MQ Serrver会回查事务状态。
6. MQ发送方会检查本地事务的状态。
7. 将本地事务状态进行Commit/Rollback消息给MQ Server。
这个方案的保障主要是通过RecketMQ 保证发送方的一致性。
最大努力通知方案：
先上图：
这个是方案1：接收方主动发起调用，保证自己获取消息
方案2：通过一个通知程序来通知接收通知方， 这样做是为了有些业务情况下（你作为接收通知方）,你不能去监控MQ，因此你就会尬住，只能通过另外一个程序来发送给你，而这个你也是需要主动发起并通知到发起通知方，让它再发一次。
目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
具体包括：
1、有一定的消息重复通知机制
因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
2、消息校对机制
如果尽最大努力通知也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
那最大努力通知和可靠消息一致性有什么不同？
1、解决方案思想不同
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到通知方，消息的可靠性关键由发起通知方保证。（发起通知方）
最大努力通知，发起通知方尽最大努力将业务处理结果通知为接收通知方，但是消息可能接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方，（可靠性关键在通知方）
2、业务应用场景不同
可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易（异步）
最大努力通知关注的是交易后的通知事务，将交易结果可靠的通知出去。
3、技术解决方向不同
可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。 （消息发出到接收的一致性）
最大努力通知无法保证消息从发出到接收的一致性，只是提供消息接收的可靠性机制。 最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息 (业务处理结果) 重点不是调用方是谁，而是通知方是谁
标签：发起,可靠消息,通知,最终,MQ,消息,一致性,接收 来源： https://www.cnblogs.com/followers/p/16660237.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。