messaging - 是否有任何基于拉取的标准消息传递协议？

有几种基于推送的消息传递标准（例如，MQTT、STORM）。是否有任何基于拉取的消息传递协议？

用例：

A 公司目前提供支持多个主题的 MQTT 端点。当事件发布到主题时，MQTT 服务器将事件推送给所有订阅者。

但是，A公司希望解决一些缺点：

当一个新订阅者注册接收发布到某个主题的事件时，她希望接收曾经发布到该主题的所有消息。
每当有一个“热门”主题时，即在短时间内向该主题发布大量事件时，将这些事件分派给已注册的订阅者可能会使订阅者不堪重负。因此，订阅者希望按照自己的节奏从主题中提取事件。

当前解决方案：

公司 A 公开了一个 HTTP 端点，该端点具有get-event检索事件的操作（例如，编号1034567为发布到以下 curl 调用中1034578命名的主题）：some-hot-topic

curl http://pull.company-a.com/get-events?topic=some-hot-topic&start-at=1034567&stop-at=1034578

问题：

而是构建这种一次性解决方案，其中公司 A 定义 URL 的格式和响应负载的格式，公司 A 可以使用任何已经定义这些的标准来解决问题（标准不必是基于 HTTP 的）。

我想到了一些事情（例如，Kafka Consumer REST API，RSS），它们在不同的上下文中解决了类似的问题，但似乎没有定义任何东西来服务于基于拉的事件通知协议的标准目的。

标签： messagingkafka-consumer-apiarchitectural-patterns

我有一些想法如何用 Kafka 来实现。我对 MQTT 没有任何经验，所以也许在那里可以实现相同的目标。

Kafka 消费者有一个偏移量——它控制消费者从队列中接收新消息的当前位置。当组中的消费者从协调器分配的分区中读取消息时，它必须提交与它已读取的消息相对应的偏移量。因此，据我了解，您的新消费者可以从一开始就开始阅读，从而接收所有消息。您需要阅读有关 Kafka 分区、消费者组和偏移量的更多信息以更好地理解它。
如果假设您在短时间内消耗了 100 个，我想您可以停止消耗新事件。因此，您将有一些时间来处理它。然后你可以恢复你的消费者。