哪个消息队列可以处理订阅者断开连接后仍然存在的私有队列？
我对需要消息队列的系统有一些要求：
- 订阅者应获得单独的队列。
- 当订阅者断开连接时，不应删除各个队列
- 如果失去连接，订阅者应能够重新连接到自己的队列
- 只有订阅者才能使用分配给它的队列
- 很好：队列在服务器重新启动后仍然存在
可以RabbitMQ 可以用来实现这个，那么如何实现呢？
I have some requirements for a system in need of a message queue:
- The subscribers shall get individual queues.
- The individual queues shall NOT be deleted when the subscriber disconnects
- The subscriber shall be able to reconnect to its own queue if it looses connection
- Only the subscriber shall be able to use the queue assigned to it
- Nice to have: the queues survive a server restart
Can RabbitMQ be used to implement this, and in that case how?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我最近才开始使用 Rabbit，但我相信您的要求可以很容易地得到满足。
1）我通过让订阅者使用其机器名称作为队列名称的一部分来声明队列（和相关的路由键），为各个订阅者实现了特定的队列。交换器通过绑定/路由密钥来适当地路由消息。就我而言，所有订阅者都会获得发布者发布的同一消息的副本，并且任意数量的订阅者可以声明自己的队列并开始接收消息。
2）这几乎是标准的。如果您声明一个队列，那么它将保留在交换中，并且如果将其设置为持久队列，那么它将在代理重新启动后继续存在。无论如何，您的订阅者应该在启动时调用queue.Declare()以确保队列存在，但就订阅者断开连接而言，队列将保留。
3) 如果队列在那里并且订阅者正在按名称侦听该队列，那么它没有理由不能重新连接。
4）我还没有真正深入研究Rabbit的安全方面。可能有一种方法可以保护单个队列，但我会让其他人对此发表评论，因为我不是权威。
5) 参见(2)。如果将消息设置为与写入磁盘时一样持久，则消息在重新启动后也将继续存在。由于存在磁盘 I/O，这会导致性能下降，但这正是您所期望的。
所以基本上，是的。兔子可以按照你的要求去做。就“如何”而言，有不同程度的“如何”。如果您在实现上述任何问题时遇到困难，我们将很乐意为您提供代码级答案。同时，如果您还没有这样做，我建议您阅读文档：
http://www.rabbitmq.com/documentation.html
HTH。史蒂夫
I have only recently started using Rabbit but I believe your requirements can be addressed fairly easily.
1) I have implemented specific queues for individual subscribers by having the subscriber declare the queue (and related routing key) using its machine name as part of the queue name. The exchange takes care of routing messages appropriately by way of the binding/routing keys. In my case, all subscribers get a copy of the same message posted by the publisher and an arbitrary number of subscribers can declare their own queues and start receiving messages.
2) That's pretty much standard. If you declare a queue then it will remain in the exchange, and if it is set as durable then it will survive broker restarts. In any case, your subscriber should call queue.Declare() at startup to ensure that the queue exists but in terms of the subscriber disconnecting, the queue will remain.
3) If the queue is there and a subscriber is listening to that queue by name then there's no reason why it shouldn't be able to reconnect.
4) I haven't really delved in to the security aspects of Rabbit yet. There may be a means of securing individual queues though I'll let someone else comment on this as I'm no authority.
5) See (2). Messages will also survive a restart if set as durable as they are then written to disk. This incurs a performance penalty as there's disk I/O but that's kind of what you'd expect.
So basically, yes. Rabbit can do as you ask. In terms of 'how', there are varying degrees of 'how'. Will happily try to provide you with code-level answers should you have trouble implementing any of the above. In the meantime, and if you haven't already done so, I suggest reading through the docs:
http://www.rabbitmq.com/documentation.html
HTH. Steve