1. 主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；
2. 消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；
3. 消息中间件返回消息持久化结果（成功/失败），主动方应用根据返回结果进行判断如何进行业务操作处理：
失败：放弃业务操作处理，结束（必要时向上层返回失败结果）；
成功：执行业务操作处理；
4. 业务操作完成后，把业务操作结果（成功/失败）发送给消息中间件；
5. 消息中间件收到业务操作结果后，根据业务结果进行处理；
失败：删除消息存储中的消息，结束；
成功：更新消息存储中的消息状态为“待发送（可发送）”，紧接着执行消息投递；
6. 前面的正向流程都成功后，向被动方应用投递消息；
实现思路
与上面的方案相比独立实现了消息服务子系统
主动发应用发送预发送消息，消息服务子系统 存储预发送消息状态未预发送，并返回操作结果
主动发应用在预发送消息成功的前提下开始进行业务操作
主动发应用发送业务操作结果给消息系统
消息系统确认并发送消息，并设置消息状态为发送中
MQ将消息转发到其他业务系统
消息状态确认子系统 查询消息服务子系统中状态还是预发送的超时消息，并查询此消息在主动方应用系统的处理情况。如果主动发业务操作失败则删除该消息。如果主动方业务操作成功则修改状态为待发送，且将信息发送到MQ
消息恢复系统：用来查询那些超时未处理状态的消息并设置延时发送
优点:
消息服务独立部署、独立维护、独立伸缩
消息存储可以按需选择不同的数据库来集成实现
消息服务可以被相同的使用场景公用，降低重复建设消息服务的成本
从应用（分布式服务）设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖与MQ中间件，弱化了对MQ中间件特性的依赖
降低了业务系统与消息系统间的耦合，有利于系统的扩展维护
