EMQX 6.x 的消息队列功能，对队列订阅方式有一些疑问

EMQX
,
1

文档上说：队列消费必须使用独立的 $queue/<name> 订阅
本质上这个属于接收离线消息， 为什么特殊的格式topic接收离线消息，而不是原先的topic呢？在设计上有什么考虑点吗

2

$queue/ 是共享订阅的无组写法，不是 EMQX 6 新消息队列的消费前缀。EMQX 6 消息队列消费用的是 $q/{Topic Filter}。
设计上要用独立前缀，是为了把“订阅实时 MQTT 流”和“消费服务端队列”分开。

如果直接让消费者订阅原始 demo/topic 来消费离线队列，会有几个冲突：

  • 普通订阅者会被误认为队列消费者，破坏现有 MQTT 语义。
  • 实时投递和队列投递会混在一起，容易重复消费 / 顺序不清。
  • 队列需要自己的 ACK、消费进度、TTL、容量限制、派发策略、最后值设定，这些都不是普通 topic 订阅能表达的。
  • 一个原始 topic 可能同时服务普通订阅、共享订阅、保留消息、规则引擎和消息队列，必须有显式入口区分。
    所以 $q/ 本质上是“从队列消费”的控制前缀，不是业务 topic。业务 topic 还是原来的 topic。

选型可以按这个分：

  • 多个在线消费者均摊实时消息：用 $share/{group}/topic，或旧的 $queue/topic。
  • 没有消费者在线时也要保留消息、之后再消费：用 EMQX 6 消息队列，也就是 $q/topic。
3

我还有一个疑问：

如果每台设备、每种 Topic 都需要一个独立队列，例如：

设备 A：$q/n1/<iotId>/thing/action/execute
设备 B：$q/n2/<iotId>/thing/action/execute

那么百万级设备可能会产生百万甚至更多队列。
每台设备 × 每种 Topic = 队列数量

请问 EMQX 是否能够保障百万级队列场景下的性能？对于这种“每台设备独立接收离线消息”的需求，是否有更合适的配置方式？

4

你可以结合自己的场景压测一测，然后再看看源码（所有的代码都是公开的）