先上图：
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,消息,一致性,接收 From： https://www.cnblogs.com/followers/p/16660237.html