可靠消息最终一致（异步确保型）

前言

一致性设计在分布式系统中是一个重要问题。若是一个系统同时使用多个子数据系统来存储与读取数据，就必须设计知足功能需求的一致性定义。若是系统对不一样数据子系统进行操做的结果不一致，不但可能会使用户困惑，更可能引起更严重的数据问题或系统错误。一致性有多种级别，适用于不一样的业务场景。对于金融等对数据一致性要求较高的行业，传统的事务能够提供较高的一致性保证。对于分布式系统等对性能（performance）和可用性（availability）要求较高的场景，牺牲必定的强一致性来换取更好的用户体验也可接受。

在以前写过一次关于TCC事务的笔记，也了解了分布式事务产生的缘由，以及部分解决方案，此次一块儿跟你们总结下最终一致性方案设计思路的相关内容；

场景

消息发送一致性的概念：是指产生消息的业务动做与消息发送的一致。

也就是说，若是业务操做成功，那么由这个业务操做所产生的消息必定要成功投递出去，不然就丢消息

最终一致性可使用在相似以下功能场景当中：

• 对应支付系统会计异步记帐业务
• 普通的积分帐户增长积分的服务

也就是说：采用最终一致性的数据系统一般不要求数据操做失败时执行回滚（rollback）。用户或系统日志将得知操做失败，但在另外一次成功的操做以前，数据的不一致问题并不会被自动修复。

ps:确定会有小伙伴有疑问，我执行程序的时候代码报错了致使最终一致性的方案不成功怎么办？？？小朋友你是否是有不少？？？

若是是代码报错，自己说明了你的业务代码有问题，而不是最终一致性方案的锅~~。

实现流程

最终一致性能够借助消息中间件，消息队列等工具实现，须要根据本身的业务去定制不一样的技术方案；

我们要介绍的是基于RabbitMq实现的一个可靠消息服务系统来完成事务的执行，具体流程以下图：

1. 主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；
2. 消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；

3. 消息中间件返回消息持久化结果（成功/失败），主动方应用根据返回结果进行判断如何进行业务操做处理：

   • 失败：放弃业务操做处理，结束（必要时向上层返回失败结果）；
   • 成功：执行业务操做处理；
4. 业务操做完成后，把业务操做结果（成功/失败）发送给消息中间件；

5. 消息中间件收到业务操做结果后，根据业务结果进行处理；

   • 失败：删除消息存储中的消息，结束；
   • 成功：更新消息存储中的消息状态为“待发送（可发送）”，紧接着执行消息投递；
6. 被动方应用监听并接收“待发送”状态的消息，执行业务处理；
7. 业务处理完成后，向消息中间件发送ACK，确认消息已经收到（消息）中间件将从队列中删除该消息）

除了以上几个流程，消息系统还应该提供ackMsg消息确认服务、消息状态查询服务。

异常的处理流程

主动方角度

从中间件的角度

异常状况的总结处理

方案落地

消息系统组成

1. 消息服务子系统：

是最重要的一个子系统，它接收并存储预发送的消息，并提供进一步的确认功能。通常须要实现如下接口服务。

• 存储预发送消息（主动方应用系统）
• 确认并发送消息（主动方应用系统）
• 查询状态确认超时的消息（消息状态确认子系统）
• 确认消息已被成功消费（被动方应用系统）
• 查询消费确认超时的消息（消息恢复子系统）

1. 消息管理子系统：

提供一个可视化的管理界面，对可靠消息服务系统中的数据，进行查询和管理。好比可查看已死亡的消息，可经过界面手工重发等

1. 消息状态确认子系统：

提供对异常状况的处理。当消息服务子系统收到并保存预发送消息，但因异常状况，没有收到确认发送消息时，这种消息不可能一直留存在数据库中。这种状况的数据，就须要消息状态确认子系统按期捞取这些待确认超时的数据，去调用主动方应用系统中的业务查询接口进行核对确认。根据核对结果决定是发送消息仍是删除数据。

1. 消息恢复子系统：

若是消息数据已经接收到业务确认，这种通过业务确认的消息，就必定要发送到MQ，并被消费方成功消费，毫不能丢。消息恢复子系统按期捞取那些状态是“发送中”，而没有被消费确认的超时消息，进行从新发送。

1. 实时消息服务子系统（MQ）：

消费方监听程序，接收MQ消息，成功处理后调用消息服务子系统的接口，确认消息已被成功消费，能够删除。

总体流程

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

谢谢观赏

---

本文是学习过程当中的笔记整理，若是有不对的地方请你们联系我，及时纠正，避免误导童鞋们，谢谢各位童鞋的耐心观看，但愿本文会帮助到您~后期计划在Hyperf中写一个demo，感兴趣的能够留意个人GitHub。