乐趣区

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

jiezi

前言

一致性设计在分布式系统中是一个重要问题。如果一个系统同时使用多个子数据系统来存储与读取数据，就必须设计满足功能需求的一致性定义。如果系统对不同数据子系统进行操作的结果不一致，不但可能会使用户困惑，更可能引发更严重的数据问题或系统错误。一致性有多种级别，适用于不同的业务场景。对于金融等对数据一致性要求较高的行业，传统的事务可以提供较高的一致性保证。对于分布式系统等对性能（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。

退出移动版