分布式事务解决方案之消息发送一致性（可靠消息的前提保障）

本文主要参考龙果学院的微服务架构的分布式事务解决方案，深入理解分布式事务

---

消息一致性大体流程

消息一致性异常情况分析

分布式环境下，在任何环节都有可能出现问题。

从主动方应用角度分析

从消息中间件的角度来分析

异常情况总结

异常处理

---

消息最终一致性之本地消息服务

1.主动方业务操作和消息数据在同一个数据库，则业务操作和消息存储发送可以作为事务执行。
    a.执行成功，进入下一步。
    b.执行失败，则业务操作和消息存储都不会成功，可以进行重试，或其他错误处理。
2.消息进入MQ消息队列。
3.被动方系统消费消息，进行业务处理。
    a.执行成功，进入下一步。
    b.执行失败，调用主动方应用接口，进行数据回滚或者其他补救措施。
4.主动方消息确认，将数据库中的消息数据删除或者标记为已消费，该分布式事务完成。
tips：主动方应用会轮询的查询超时未消费的消息，并进行重发。所以，被动方接口要求是幂等性的。

优点

1.消息时效性比较高。
2.从应用设计开发的角度实现了消息数据的可靠性，
  消息数据的可靠性不依赖于MQ中间件，
  弱化了对MQ中间价特性的依赖。
3.方案轻量，容易实现。

缺点

1.与具体的业务场景绑定，耦合性强，不可共用。
2.消息数据与业务数据库同库，占用业务系统的资源。
3.业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限。

消息最终一致性之独立消息服务

参考文章：启发:从MNS事务消息谈分布式事务

• 消息状态确认子系统：轮询查询消息服务子系统，处理消息超时，未确认等情况。
• 消息恢复子系统：由于业务操作已经完成，消息一定需要被正确消费。因此在被动方未正确处理的情况下，进行重发。
• 与参考文章比较，其实上图中的消息服务子系统与实时消息服务（activemq等）就相当于阿里云的MNS服务，消息服务子系统是对实时消息服务的封装。
• 为了提升性能，发送业务操作结果（也就是确认发送消息）可以是异步的。因为就算发送消息失败了，也有轮询机制再次发送。
• 接口必须保证为幂等性的。参考：分布式高并发系统如何保证对外接口的幂等性？

---

实战演练

业务场景：现有订单服务和solr索引服务，用户创建订单，则需要更新solr索引。

流程

异常处理