Rabbitmq 发布/订阅时，每条消息都有若干个关键字，每个队列都有若干个他感兴趣的关键字

我有一个相对标准的发布/订阅系统，具有以下要求：

• 每条消息包含的主题数量（1到几十个，但通常不超过5个）
• 每个消费者订阅的主题数量（通常为3-10个）
• 有数千个主题，数百个消费者和几位制作人
• 系统必须每秒缩放2000条消息
• 有时，消费者可以改变他们感兴趣的话题
• 当然，要求每条消息只到达订阅者一次（即使它包含消费者订阅的几个关键字）

我使用的是RabbitMQ，但我认为这个问题已经足够笼统了

Rabbit拥有的所有exchange类型都不直接支持此模型。若RabbitMQ支持将正则表达式绑定到队列，那个将非常酷，但我认为这并不存在

我在考虑一个方案，如果客户机对key1、key2和key3感兴趣，它将创建到#.key1.#、#.key2.#和#.key3.#的绑定，并且带有key1和key4的消息的路由键为：.key1.key4。

---

我想知道这是否是正确的范例，或者是否存在更规范的方法。路线有多贵？消费者更改订阅时更改绑定的成本有多高？绑定发生更改后，队列中已存在的消息会发生什么情况

简短回答：

路由模型已经足够好了。不要担心rabbitmq性能（尤其是2k/s消息流）。一旦消息进入队列，它将仍然存在，除非它被消耗或死亡（由于ttl或长度限制）

长答案：

我在考虑一个方案，如果客户机对key1、key2和key3感兴趣，它将创建到#.key1.#、#.key2.#和#.key3.#的绑定，并且带有key1和key4的消息的路由键为：.key1.key4。我想知道这是否是正确的范例，或者是否存在更规范的方法

这个主意很好。如果你愿意，你也可以尝试一下，如果你确定你需要他们的力量（如果你不需要的话——坚持主题）

路线有多贵

不必担心主题交换路由性能，它足够快，并且在RabbitMQ代理内部进行了很好的优化

有关详细信息，请阅读，尤其是和

消费者更改订阅时更改绑定的成本有多高

这是一个微不足道的操作，根本不会对性能造成任何影响

绑定发生更改后，队列中已存在的消息会发生什么情况

消息进入队列后，它仍将在那里，除非您使用

basic.get

或

basic.consumer

方法或消息获取：

• 消息被拒绝（basic.reject或basic.nack），requeue=false
• 消息的TTL过期；或
• 超出了队列长度限制

附言：

可能存在一些警告，如同步延迟（当您进入HA或群集时）、网络故障等，这些警告会引入额外的条件，在这些条件下，消息可能会丢失（当消息在未经确认的情况下被消费，并从队列中删除，但由于（例如）消费者应用程序故障而未交付给消费者时）或者翻倍到另一个（在刻字时），但这些都是非常特殊的情况，当你进入它时就会知道