一、消息发送一致性流程中的异常点
任何一个环节都可能会出问题！
二、消息发送一致性的异常情况分析
1、从主动方应用的角度来分析
一致性 | ||
预发送消息失败 | 消息未进存储，业务操作未执行（可能的原因：主动方应用、网络、消息中间件、消息存储） | 一致 |
预发送消息后，主动方应用没有收到返回消息存储结果 | (1)消息未进存储，业务操作未执行 | 一致 |
同上 | (2)消息已进存储（待确认），业务操作未执行 | 不一致 |
收到消息存储成功的返回结果，但未执行业务操作就失败 | 消息已进存储（待确认），业务操作未执行 | 不一致 |
2、消息发送一致性的异常情况分析
一致性 | ||
消息中间件没有收到主动方应用的业务操作处理结果 | (1)消息已进存储（待确认），业务操作未执行（或业务操作出错回滚了） | 不一致 |
同上 | (2)消息已进存储（待确认），业务操作成功 | 不一致 |
消息中间件收到业务操作结果（成功/失败），但处理消息存储中的消息状态失败 | (1)消息已进存储（待确认），业务操作未执行（或业务操作出错回滚了） | 不一致 |
同上 | (2)消息已进存储（待确认），业务操作成功 | 不一致 |
3、消息发送一致性的异常情况总结
一致性 | ||
消息未进存储，业务操作未执行 | 一致 | |
消息已进存储（状态待确认），业务操作未执行 | 不一致 | 确认业务操作结果，处理消息（删除消息） |
消息已进存储（状态待确认），业务操作成功 | 不一致 | 确认业务操作结果，处理消息（更新消息状态，执行消息投递） |
4、消息发送一致性的异常处理
三、MQ队列消息模型特点
1、队列消息模型的特点
消息生产者将消息发送到Queue中，然后消息消费者监听Queue并接收消息；
消息被确认消费以后，就会从Queue中删除，所以消息消费者不会消费到已经被消费的消息；
Queue支持存在多个消费者，但是对某一个消息而言，只会有一个消费者成功消费。
1.Producer生成消息并发送给MQ（同步、异步）；
2.MQ接收消息并将消息数据持久化到消息存储（持久化操作为可选配置）；
3.MQ向Producer返回消息的接收结果（返回值、异常）；
4.Consumer监听并消费MQ中的消息；
5.Consumer获取到消息后执行业务处理；
6.Consumer对已成功消费的消息向MQ进行ACK确认（确认后的消息将从MQ中删除）
2、与消息发送一致性流程的对比
常规MQ队列消息的处理流程无法实现消息发送一致性；
投递消息的流程其实就是消息的消费流程，可细化。
3、总结
常规MQ队列消息的处理流程无法实现消息发送一致性，因此直接使用现成的MQ中间件产品无法实现可靠消息最终一致性的分布式事务解决方案。
