研读《可靠消息最终一致性方案（独立消息服务）》

前言

在上一篇研读《可靠消息最终一致性方案（本地消息服务）》 我介绍了通过本地消息服务来实现分布式事务最终一致性，最后也说了一下这种实现方案的优缺点，现在就来介绍一下如何通过独立消息服务实现分布式事务最终一致性的解决方案。

正文

在分布式事务中，有很多诸如CAP，BASE等理论，还有2PC，TCC等解决方案，这些我都不会在这里讲，直接进入主题。

先假设一个场景，我们在下单买东西的时候，需要扣库存，比如说你买了一台电脑，则这台电脑在库存中的数量就应该减1，其实上现在分布式的事务很多都是不需强一致性的，只需要满足最终一致性，像这个场景满足最终一致性就可以了，你买了一台电脑，在一段时间内这台电脑的库存会减1，不要求你刚下单就要马上减库存。

按照微服务的尿性，上述场景涉及到订单服务的下单操作和库存服务扣库存操作，并且涉及到订单库和库存库这两个数据库，所以不能用本地事务解决问题。

下面祭出这张图，是我重新画的，在龙果的基础上加上了标号，这样子可以更好地去描述整个可靠消息最终一致性方案。其中可以把订单服务看作主动方应用系统，库存服务看作被动方应用系统。

1. 用户下单，主动方应用预发送消息给消息服务子系统。
2. 消息服务子系统存储预发送的消息。
3. 返回存储预发送消息的结果。
4. 如果第3步返回的结果是成功的，则执行业务操作，否则不执行。
5. 业务操作成功后，调用消息服务子系统进行确认发送消息。
6. 将消息服务库中存储的预发送消息发送，并更新该消息的状态为已发送（但不是已被消费）。
7. 消息中间件发送消息到消费端应用。
8. 消费端应用调用被动方应用服务。
9. 被动方应用返回结果给消费端应用。
10. 消费端应用向消息中间件ack此条消息，并向消息服务子系统进行确认成功消费消息，让消息服务子系统删除该条消息或者将状态置为已成功消费。
11. 消息恢复系统定时去查一下消息数据，看看有没有是已发送状态的超时消息，就是一直没有变成已成功消费的那种消息。
12. 主动方应用系统应该提供查询接口，针对某条消息查询该条消息对应的业务数据是否为处理成功的。
13. 如果业务数据是处理成功的状态，那么就再次调用确认并发送消息，即进入第6步。
14. 如果业务数据是处理失败的，那么就调用消息服务子系统进行删除该条消息数据。

如果出错的时候，这个系统是怎么保持一致性的，可以参考研读《可靠消息最终一致性方案（本地消息服务）》

总结起来其实就是只要消息数据持久化了，我就假设后面一定会被消费，就算后面挂了一堆东西，但是我们把挂掉的服务再全部启动，这条消息还是会被消费，不会丢失，可以保证最终一致性。

优点

1. 消息服务独立部署，独立维护，独立伸缩。
2. 消息存储可以按需选择不同的数据库集成实现。
3. 消息服务可以被相同的使用场景共用，降低重复建设消息服务的成本。
4. 从应用（分布式服务）设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖消息中间件，弱化了对消息中间件特性的依赖。
5. 降低了业务系统与消息系统间的耦合，有利于系统的扩展维护。

缺点

1. 一次消息发送需要两次请求。
2. 主动方应用需要提供比较多的查询接口。