可靠的Webhook调度系统

Question

我很难为webhook调度系统找到一个可靠的、可伸缩的解决方案。

当前系统使用RabbitMQ，并为webhooks提供队列(让我们称其为events)，这些let钩子被消耗和分派。这个系统运行了一段时间，但现在有几个问题：

• 如果系统用户生成过多的事件，它将占用队列，导致其他用户在很长一段时间内不接收web钩子。
• 如果我将所有事件拆分成多个队列(通过URL哈希)，就会减少第一个问题的可能性，但当非常繁忙的用户碰到同一个队列时，仍然会发生这种情况。
• 如果我试图将每个URL放入它自己的队列中，那么所面临的挑战就是动态地为这些队列创建/分配使用者。就RabbitMQ文档而言，API在过滤非空队列或没有分配使用者的队列方面非常有限。
• 就Kafka而言，我从阅读有关它的所有内容中了解到，在单个分区的范围内，情况是一样的。

因此，问题是-是否有更好的办法/制度来实现这一目的？也许我错过了一个非常简单的解决方案，可以让一个用户不干扰另一个用户？

提前感谢！

Answer 1

所以，我不知道这是否解决这个问题的正确方法，但这是我想出来的。

先决条件:带有去重叠插件的RabbitMQ

所以我的解决方案包括：

• g:events队列-让我们称它为parent队列。此队列将包含需要处理的所有child队列的名称。可能可以用其他机制(比如Redis排序集或其他机制)来代替它，但是您必须自己实现ack逻辑。
• g:events:<url> --这里有child队列。每个队列只包含需要发送到该url的事件。

当向RabbitMQ发布webhook有效负载时，您可以将实际数据发布到child队列，然后将child队列的名称附加到parent队列中。重复插件将不允许同一个child队列发布两次，这意味着只有一个用户可以接收到该child队列进行处理。

所有的消费者都在使用parent队列，在收到消息之后，他们就开始使用消息中指定的child队列。在child队列为空后，您将确认parent消息并继续前进。

此方法允许非常精细地控制允许处理哪些child队列。如果某些child队列花费太多时间，只需将parent消息重新发布到parent队列的末尾即可。

我知道这可能不是最有效的方法(经常向parent队列投递也有一些开销)，但事实就是如此。

Answer 2

您可以尝试几个rabbitmq特性来缓解您的问题(而不完全删除它)：

• 使用公共随机交换将事件拆分到多个队列中。它将减轻大量事件的激增，并将工作分派给几个消费者。
• 将一些TTL政策设置到队列中。这样，如果处理的不够快，Rabbitmq可以将事件重新发布到另一组队列(例如通过另一个私有随机交换)。

您可能有几个事件的“周期”，不同的配置(即每个周期的周期数和TTL值)。您的第一个循环尽可能地处理新事件，在随机交换下通过几个队列减少尖峰。如果它不能足够快地处理事件，则事件将被移动到另一个具有专用队列和使用者的循环中。

这样，您可以确保新事件有更好的更改需要快速处理，因为它们总是在第一个周期中发布(而不是在另一个用户的一堆旧事件后面)。

Answer 3

如果您需要订单，不幸的是，您依赖于用户的输入。

但是在卡夫卡的世界里，有几件事要提出来；

• 您可以使用exactly-once实现Transactions交付，这允许您构建类似于常规AMQPs的类似系统。
• Kafka支持按键进行分区。它允许您保持相同密钥的处理顺序(在您的例子中是userId)。
• 可以通过调优所有生产者、服务器和消费者端(批处理大小、信息请求等)来提高吞吐量，有关更多参数，请参见Kafka文献。
• Kafka支持消息压缩，这减少了网络流量，增加了吞吐量(只需为LZ4这样的快速压缩算法消耗更多的CPU功率)。

分区在您的场景中是最重要的。您可以增加分区以同时处理更多消息。你的消费者可以和你的分区在同一个消费者中一样多。即使您在达到分区计数后进行缩放，您的新使用者也将无法阅读，并且他们将保持未分配。

与常规的AMQP服务不同，Kafka在阅读后不会删除消息，只会为消费者注册标识标记偏移。这允许你同时做一些事情。就像在单独的进程中计算实时用户计数一样。