哪种解决方案更好地处理发布者/订阅者场景？答案

【问题标题】：Which Solution Handles Publisher/Subscriber Scenario Better?哪种解决方案更好地处理发布者/订阅者场景？
【发布时间】：2014-07-06 08:24:47
【问题描述】：

场景是发布者/订阅者，我正在寻找一种解决方案，该解决方案可以让一个生产者生成的一条消息实时发送给多个消费者。一种解决方案可以处理这种情况的重量越轻越好！

在 AMQP 服务器的情况下，我只检查了 Rabbitmq 并使用rabbitmq 服务器进行发布/订阅模式，每个消费者都应该声明一个匿名的私有队列并将其绑定到扇出交换，因此如果有数千名用户消费一条消息rabbitmq 会实时处理数千个左右的匿名队列。

但是我真的不喜欢rabbitmq的做法，如果rabbitmq能够处理这个pub/sub场景，一个队列，一个消息，多个消费者在一个队列上监听，那将是理想的！

我想问的是哪种 AMQP 服务器或其他类型的解决方案（任何类似的解决方案，包括 XMPP 服务器或 Apache Kafka 或...）在处理 pub/sub 模式/场景时比 RabbitMQ 更好、更高效地使用（当然）更少的服务器资源？

按兴趣排序的偏好：

我知道我的问题可能非常笼统，但我喜欢听听有关 pub/sub 案例的想法和建议。

谢谢。

【问题讨论】：

【解决方案1】：

一般来说，对于RabbitMQ，如果将用户放在routing key中，应该可以使用单个exchange，然后再使用少量queues （如果您愿意，甚至可以单独使用一个，但如果您的设置有意义的话，您可以将它们按服务器或类似设备划分）。

如果您不需要 guaranteed order（例如，保证 FK 约束不会因对各种 SQL 数据库表的一系列更改而受到影响），那么您没有理由不能拥有一堆consumers 从一个队列中抽取。

如果您想要广播消息类型的场景，那么处理方式可能会有所不同。除了routing key 中的单个用户（您可以将其用于非广播类型的消息），而是具有特殊的用户类型，例如，__broadcast__，没有用户实际上可以拥有，并且拥有用户广播到与消息本身一起存储在消息的有效负载中。

然后，您的消息处理代码可以负责将该消息存放在所有这些用户的数据库（或任何最终目的地）中。

根据 OP 的评论进行编辑：

所以routing key 可能看起来像这样 message.[user] 其中 [user] 可能是实际用户，如果它是一个点对点消息，并且是一个特殊的 __broadcast__ 用户（或不允许实际用户注册的类似用户名），表示广播式消息。

然后，您可以将要接收消息的用户放置在消息的payload 中，然后可以将消息内容（也将在 payload 中）传递给每个用户。这样做的机制取决于您的最终目的地是什么。即消息是否最终存储在 Postgres 或 Mongo DB 或类似中？

【讨论】：

你能说得更准确点吗？ put the user in the routing key 是什么意思？我没有得到它与交换和少量队列的关系。如果您能解释更多，将不胜感激。如前所述，该场景是通过单个队列向所有消费者发送一条消息，确保所有消费者都收到该消息的副本，以及之后的消息。如果您可以指出任何类型的文档也可以。顺便谢谢你的回答:)
上面已澄清；还质疑消息的最终目的地是什么。