rabbitmq优先级队列仅控制消息出队顺序，不干预worker并发数；并发由消费者端prefetchcount、进程数量及ack机制决定，需配合多队列拆分、dlx和ttl等策略才能真正保障优先级语义。
为什么 RabbitMQ 优先级队列本身不控制 Worker 并发数
很多人误以为只要给队列设了 x-max-priority，RabbitMQ 就会自动按优先级“调度更多消费者处理高优消息”。事实并非如此：RabbitMQ 的优先级队列只影响**消息在队列内的出队顺序**（高优先级消息插队），但不会干预消费者端的并发行为。Worker 数量、预取值（prefetchCount）、手动确认节奏，全由 NestJS 客户端配置和代码逻辑决定。
用多个独立队列 + 多个 BullMQ / RMQ Worker 实例实现分级并发
NestJS 原生微服务模块（@nestjs/microservices）不支持单个 queue 内按消息优先级动态调整 Worker 并发。真正可控且生产可用的做法是：为不同优先级业务拆成多个物理队列，每个队列绑定专属 Worker，并单独配置其并发能力。
以 BullMQ 为例（推荐用于任务型场景）：
- 定义三个队列：
ai-report-queue:high、notification-queue:medium、log-sync-queue:low - 在
BullModule.registerQueue()中分别注册，每个传入不同concurrency值 - 发送时根据业务逻辑选择对应队列名，例如：
await this.highPriorityQueue.add('generate-report', payload, { priority: 10 })
若坚持用原生 RabbitMQ 微服务传输器，则需启动多个 createMicroservice() 实例（或多个 ClientsModule 注入点），每个绑定不同 queue 和不同 prefetchCount —— 但注意：prefetchCount 控制的是信道级预取条数，不是 Worker 进程数；真正的并发数取决于你启动了多少个监听该队列的微服务进程。
关键参数：prefetchCount 不等于 concurrency，但必须配对设置
在 RabbitMQ 场景下，prefetchCount 是唯一能间接影响“实际并发粒度”的配置项。它表示 AMQP 信道一次最多向当前消费者推送几条未确认消息。如果设为 1，则每处理完一条才取下一条，天然串行；设为 10，则最多有 10 条消息同时处于“已投递、未确认”状态 —— 这就要求你的处理器能并行处理它们（比如用 Promise.all 或子进程）。
-
noAck: false必须启用，否则无法手动ack/nack，失去重试与失败隔离能力 -
prefetchCount应 ≤ 单个 Worker 实例的 CPU 核心数 × 2（Node.js 场景下过高的值反而引发事件循环阻塞） - 高优队列建议
prefetchCount: 5，低优队列可设为1或2，避免低优任务抢占资源 - 务必配合
queueOptions.durable: true，否则 RabbitMQ 重启后队列消失，prefetch配置也白设
别忽略 ACK 超时和死信队列（DLX）的协同设计
单纯调高并发或优先级，不处理失败边界，会导致高优消息卡死、低优消息永久积压。真实系统里必须配套：
- 为每个优先级队列声明独立的 DLX（Dead Letter Exchange），指向专用的
dlq-high/dlq-low队列 - 设置
messageTtl或maxPriority配合deadLetterRoutingKey，让超时/失败消息自动路由到 DLX - 高优队列的
messageTtl可设更短（如 30s），低优队列放宽（如 5min），防止长耗时任务拖垮整体吞吐 - DLX 队列本身也要配
durable: true和独立 Worker，用于人工干预或自动降级重投
并发数只是表象，ACK 行为、TTL 策略、DLX 路由才是保障优先级语义落地的关键链条。漏掉任意一环，所谓“高优”就只剩心理安慰。
