6

我正在研究基本上是一个高度可用的分布式消息传递系统。系统通过 HTTP 或 TCP 从某个地方接收消息，对其执行各种转换，然后将其发送到一个或多个目的地（也使用 TCP/HTTP）。

系统要求发送到给定目的地的所有消息都是有序的，因为某些消息建立在先前消息的内容之上。这限制了我们按顺序处理消息，每条消息大约需要 750 毫秒。因此，例如，如果有人每 250 毫秒向我们发送一条消息，我们将被迫将消息排在彼此后面。这最终在高负载下的消息处理中引入了无法容忍的延迟，因为每条消息可能必须等待数百条其他消息被处理才能轮到它。

为了解决这个问题，我希望能够在不破坏我们按顺序发送它们的要求的情况下并行化我们的消息处理。

我们可以轻松地横向扩展我们的处理。缺少的部分是一种确保即使消息被无序处理，它们也会被“重新排序”并按照接收顺序发送到目的地的方法。我正在努力寻找实现这一目标的最佳方法。

Apache Camel 有一个叫做 Resequencer 的东西可以做到这一点，它包括一个漂亮的图表（我没有足够的代表直接嵌入）。这正是我想要的：接收乱序消息并将它们排序的东西。

但是，我不希望它是用 Java 编写的，而且我需要高可用性的解决方案（即能够抵抗崩溃或系统重启等典型系统故障），我认为 Apache Camel 不提供这种解决方案。

我们的应用程序是用 Node.js 编写的，使用 Redis 和 Postgresql 进行数据持久化。我们将Kue库用于我们的消息队列。尽管 Kue 提供了优先队列，但对于上述用例来说，功能集太有限了，所以我认为我们需要一种替代技术来与 Kue 协同工作来重新排序我们的消息。

我试图在网上研究这个话题，但我找不到我预期的那么多信息。这似乎是那种会有大量文章和实现的分布式架构模式，但我看不到那么多。搜索诸如“消息重排序”、“乱序处理”、“并行消息处理”等内容的解决方案大多只是放松基于分区或主题等的“有序”要求。或者，他们谈论单台机器上的并行化。我需要一个解决方案：

  • 可以以任何顺序同时处理多条消息。
  • 将始终按照它们到达系统的顺序发送消息，无论它们是按什么顺序处理的。
  • 可从 Node.js 使用
  • 可以在 HA 环境中运行（即它的多个实例同时在同一个消息队列上运行而不会出现不一致。）

我们目前的计划对我来说很有意义，但我无法在网上任何地方找到它的描述，它是使用 Redis 来维护按到达时间排序的正在进行和准备发送的消息集。大致来说，它是这样工作的：

  1. 当收到一条消息时，该消息将放在进行中的集上。
  2. 消息处理完成后，该消息将放入准备发送集。
  3. 只要在进行中和准备发送集的前面都有相同的消息，则可以发送该消息并且它会按顺序排列。

我会编写一个小型 Node 库，使用原子 Redis 事务通过优先级队列式 API 实现此行为。但这只是我自己想出来的，所以我想知道：是否还有其他技术（最好使用我们已经使用的 Node/Redis 堆栈）来解决重新排序无序消息的问题? 或者我可以将这个问题用作研究关键字的其他术语吗？谢谢你的帮助！

4

1 回答 1

3

这是一个常见的问题，所以肯定有很多可用的解决方案。这也是一个比较简单的问题，也是分布式系统领域一个很好的学习机会。我建议你自己写。

你会遇到一些问题，即

2：Exactly-once delivery
1：有保证的消息顺序
2：Exactly-once delivery

您已经找到了 1 号，并且您正在通过在 redis 中重新排序它们来解决这个问题，这是一个不错的解决方案。但是，另一个没有解决。

看起来你的架构不适合容错，所以目前，如果服务器崩溃，你重新启动它并继续你的生活。这在按顺序处理所有请求时效果很好，因为根据最后一次成功完成的请求，您可以准确地知道崩溃的时间。

您需要的是找出您实际完成了哪些请求以及哪些请求失败了的策略，或者是在发生故障时向您的客户发送一封写得很好的道歉信。

如果 Redis 没有分片，那么它是强一致的。如果该单个节点崩溃，它将失败并可能丢失所有数据，但您不会遇到乱序数据或数据突然出现和退出存在的任何问题。因此，单个 Redis 节点可以保证，如果将消息插入到 to-process-set，然后再插入到 done-set，则没有节点将在 done-set 中看到该消息，而该消息也位于 to-流程集。

我会怎么做

使用 redis 似乎太模糊了，假设消息不是很大，如果进程崩溃，丢失它们是可以的，并且多次运行它们，甚至同时运行单个请求的多个副本不是问题。

我建议设置一个主管服务器，它接收传入的请求，将每个请求分派给随机选择的从属服务器，存储响应并在发送它们之前再次将它们重新排序。你说你预计处理需要 750 毫秒。如果从服务器在 2 秒内没有响应，则在 0-1 秒内将其再次随机分派到另一个节点。第一个响应的是我们要使用的那个。谨防重复响应。

如果重试请求也失败，则将最大等待时间加倍。在大约 5 次失败之后，每次等待的时间是前一次的两倍（或任何大于一的倍数），我们可能会遇到永久性错误，因此我们可能应该要求人工干预。该算法称为指数退避，可防止请求突然激增而导致整个集群瘫痪。不使用随机间隔，并且在 n 秒后重试可能会导致每 n 秒发生一次 DOS 攻击，直到集群死亡，如果它得到足够大的负载峰值。

失败的方式有很多，因此请确保该系统不是唯一存储数据的地方。但是，这可能会在 99+% 的时间内工作，它可能至少与您当前的系统一样好，并且您可以用几百行代码来实现它。只需确保您的主管使用异步请求，以便您可以处理重试和超时。Javascript 本质上是单线程的，所以这比正常情况要复杂一些，但我相信你可以做到。

于 2016-08-31T09:08:21.103 回答