首页 文章

哪个解决方案更好地处理发布者/订阅者方案?

提问于
浏览
1

该场景是发布者/订阅者,我正在寻找一种解决方案,该解决方案可以实现在MULTIPLE消费者实时发送由ONE 生产环境 者生成的一条消息的可行性 . 这个场景可以通过一个解决方案来处理轻量级,效果更好!

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

但我真的不喜欢rabbitmq的方法,如果rabbitmq可以处理这个发布/子场景,只有一个队列,一条消息,许多消费者在一个队列上监听,这将是理想的!

我想问的是哪个AMQP服务器或其他类型的解决方案(任何类似的包括XMPP服务器或Apache Kafka或...)处理发布/订阅模式/场景比RabbitMQ更好,更高效,消耗(当然)更少服务器资源?

感兴趣的偏好:

  • 在启用AMQP的情况下,服务器处理只有一个或少数个队列的发布/订阅方案(如上所述)

与pub / sub模式中的其他解决方案相比,

  • 以轻量级方式处理数千个消费者,消耗更少的服务器资源

  • 聚类,容忍节点失败

  • 许多语言绑定(至少Python和Java)

  • 易于使用和管理

我知道我的问题可能很普遍,但我喜欢听到pub / sub案例的想法和建议 .

谢谢 .

1 回答

  • 1

    通常,对于 RabbitMQ ,如果将 user 放在 routing key 中,您应该能够使用单个 exchange 然后使用少量的 queue (如果需要,甚至可以使用单个),但您可以将它们按服务器或类似的,如果你的设置有意义) .

    如果您不需要 guaranteed order (例如,保证FK约束不会导致您无法从单个队列中获取一堆 consumers ) .

    如果您想要一种广播消息类型的场景,那么这可能会有所不同 . 可以用于非广播类型消息的 routing key 中的单个用户,而不是用户可以拥有的特殊用户类型,例如 broadcast ,并且让用户广播存储在有效负载中 . 消息以及消息本身 .

    然后,您的消息处理代码可以负责将该消息存储在所有这些用户的数据库(或任何最终目的地)中 .

    Edit in response to comment from OP:

    所以 routing key 可能看起来像这样 message.[user] ,其中[user]可能是实际用户(如果它是点对点消息)和特殊 broadcast 用户(或实际用户不允许注册的类似用户名)这表示广播风格的消息 .

    然后,您可以在邮件的 payload 中放置要传递邮件的用户,然后可以将该邮件内容(也可以在 payload 中)传递给每个用户 . 这样做的机制取决于您的最终目的地 . 即消息最终是存储在 Postgres ,还是 Mongo DB 或类似的?

相关问题