有序消息服务架构

Question

大家好，我需要创建一个服务，它可以从 FIFO 数据流接收消息并将消息按顺序发送到每个客户端服务器。

假设数据流包含A1、A2、A3、A4、B1、B2、B3、C1、C2等，那么我需要依次发送消息A1、A2、A3、A4到服务器A，消息B1 、B2、B3、B4 依次发送到服务器 B，依此类推。 每个客户端服务器必须按顺序接收消息。输入数据流保证是有序的。

要求：

1. 推送到数据流的消息数量每秒高达 10,000 条消息。
2. 不同客户端服务器的数量高达1,000,000个，并且还在不断增加。 （A、B、C、...）
3. 每个客户端服务器的消息序列数最多为 10 个序列消息。 （A1，A2，...，A10）
4. 客户端服务器需要近乎实时地接收消息（消息推送到数据流后不到 2 分钟）。

这是我遇到的问题：

客户端服务器很可能没有响应。在这种情况下，服务需要等待并停止向该客户端服务器发送消息，直到客户端服务器准备好接收消息。 （例如服务器 A 宕机了，那么服务应该停止向服务器 A 发送消息，但服务继续向其他未宕机的服务器发送消息）。

这是我当前的解决方案：

我正在考虑将输入数据流中的所有消息存储到数据库中。同时，有一个 cron 作业将从数据库中选择第一条消息，该消息不是按时间戳发送的。所选消息将异步发送到各自的客户端服务器。

但是，我在网上阅读了很多博客，他们并不建议将消息存储在数据库上（永远不要使用数据库作为消息队列），因此我正在寻找另一种架构建议，但找不到。

你们对此有什么架构建议吗？

允许任何第三方服务（AWS、GCP、Kafka、Ably 等）。

Answer 1

考虑到您提到的服务器可用性方面的限制，我会考虑一种每台服务器使用一个队列的解决方案。

基本上，您的应用程序从 FIFO 队列中读取数据，在内存中为每个服务器（例如服务器 A）累积 10 条消息，并将这些消息推送到仅由服务器 A 使用的专用队列中。

通过这种方式，您可以将数据传输模型从基于推送的模式切换为基于拉取的模式，并且您不必担心服务器 A 的可用性，因为如果它发生故障，消息将保留在其队列中，当它恢复时，它会重新启动。将以相同的顺序处理最新的消息。

当然，现在您需要 100 万个以上的队列。如果您使用 AWS SQS，它可以保证 FIFO 交付逻辑的排序，那么您可以为每个账户创建的队列数量没有限制，因此至少在技术上它应该可以工作。

对于那些类型的高吞吐量、低延迟用例，我不会使用数据库（尤其是关系数据库），因为它很快就会成为瓶颈。

相反，我会检查 Redis Streams 以查看它是否适合此用例。 有些人说它可以很好地处理 200K 流，我认为它可以毫无问题地达到 1M+。