这个场景是publisher/subscriber，我正在寻找一个解决方案，它可以让一个生产者跨多个消费者实时发送一条消息。一个解决方案可以处理的重量越轻越好！
在amqp服务器的情况下，我只 checkout 了rabbitmq，并使用rabbitmq服务器进行pub/sub模式，每个使用者都应该声明一个匿名的私有队列，并将其绑定到fanout交换，因此在数千个用户实时消费一条消息的情况下，rabbitmq将有数千个左右的匿名队列处理。
但是我真的不喜欢rabbitmq的方法，如果rabbitmq能够处理一个队列、一条消息、多个消费者在一个队列上侦听的pub/sub场景，那就太理想了！
我想问的是，哪种amqp服务器或其他类型的解决方案（任何类似的解决方案，包括xmpp服务器或apache kafka或……）比rabbitmq更好地处理发布/子模式/场景，并且更高效地消耗（当然）更少的服务器资源？
按兴趣顺序排列的偏好：
在启用amqp的情况下，服务器处理pub/sub场景时，只有一个或更少的队列（如所述）
以轻量级的方式处理数千个使用者，与pub/sub模式中的其他解决方案相比消耗更少的服务器资源
群集，容忍节点故障
许多语言绑定（至少是python和java）
易于使用和管理
我知道我的问题可能很笼统，但我喜欢听听关于酒吧/酒吧案例的想法和建议。
谢谢。
1条答案
按热度按时间yzckvree1#
一般来说
RabbitMQ，如果将用户放入routing key，您应该能够使用单个exchange然后是一小部分queues（即使是一个单独的，如果你想，但你可以分为服务器或类似的，如果这是有意义的给你的设置）。如果你不需要
guaranteed order（比如说，保证fk约束不会因为对各种sql数据库表的一系列更改而受到影响），那么就没有理由不能有一堆consumers从单个队列绘制。如果您想要一种广播消息类型的场景，那么可能会有点不同的处理方式。而不是
routing key，您可以将其用于非广播类型的消息，它有一个特殊的用户类型，例如，\u broadcast，\uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu。然后，您的消息处理代码可以负责将该消息存放在所有这些用户的数据库（或任何最终目的地）中。
根据op的评论进行编辑：
所以
routing key可能类似于此消息。[user]，其中[user]可能是实际用户（如果它是点对点消息）和特殊的广播用户（或实际用户不允许注册的类似用户名），这将指示广播样式的消息。然后，您可以将消息应传递到的用户放置在
payload然后是消息内容（也将在payload)可以传递给每个用户。这样做的机制取决于你的最终目的地是什么。i、 e.信息最终是否会存储在Postgres，或Mongo DB还是类似的？