rabbitmq消费者集群天然支持负载均衡与任务抢占，关键在于同一队列下多消费者通过服务端轮询分发、手动ack配合prefetchcount=1实现公平分配与故障时消息重入队，无需额外协调组件。
Java 中 RabbitMQ 的消费者集群天然支持负载均衡与任务抢占，关键在于合理配置队列、消费者和 ACK 模式，而非依赖额外的协调组件。
使用同一队列 + 多个消费者实现自动负载均衡
RabbitMQ 默认采用“轮询（Round-Robin）”方式将消息分发给绑定在同一队列上的多个消费者。只要所有消费者监听同一个 durable 队列，RabbitMQ 服务端会自动完成负载分发。
- 确保所有消费者使用相同的 queue name（如 "order.processing.queue"），且声明时参数一致（durable=true, exclusive=false, autoDelete=false）
- 每个消费者调用 channel.basicConsume() 订阅该队列，无需指定 routing key 或 exchange 绑定逻辑
- 默认 prefetchCount=1（推荐）：防止某个消费者积压大量未确认消息，导致其他空闲消费者“饿死”
通过手动 ACK + prefetch 控制抢占行为
任务抢占的核心机制是“消息未确认即释放”。当消费者异常断连或未及时 ACK，RabbitMQ 会将未确认消息重新入队（或投递到其他消费者），实现故障转移与动态抢占。
- 关闭自动 ACK：channel.basicConsume(queue, false, ...)，并在业务处理完成后显式调用 channel.basicAck(deliveryTag, false)
- 设置合理的 prefetchCount = 1（推荐）：避免单个消费者预取过多消息，阻塞抢占机会；若业务耗时差异大，可设为 0（无上限），但需配合超时重发逻辑
- 消费者进程崩溃或连接中断时，RabbitMQ 会在 consumer timeout（默认 30 分钟） 后自动 requeue 未 ACK 消息；也可主动发送 Connection.close() 或心跳失败触发快速释放
利用消息属性支持优先级与延迟抢占
单纯轮询无法应对紧急任务插队。可通过消息属性增强抢占能力：
- 启用队列 max-priority（如 x-max-priority=10），发送时设置 AMQP.BasicProperties.Builder.priority()，高优先级消息会被插到队列头部，更快被消费
- 对超时任务，用 DLX（Dead Letter Exchange）+ TTL 实现“重试后抢占”：设置消息 expiration，过期后路由到重试队列，再由相同消费者组重新竞争
- 避免在消费者端做复杂调度逻辑——RabbitMQ 的抢占应由服务端基于连接状态和 ACK 状态驱动，而非客户端协调
避免常见陷阱：集群 ≠ 消费者组协调
RabbitMQ 本身不提供跨节点消费者状态同步。所谓“集群中的消费者”，本质是多个独立应用实例连接到同一个 RabbitMQ 集群（或单节点），共享队列资源。
- 不要试图用 ZooKeeper / Redis 做消费者选主——违背 AMQP 设计哲学，增加复杂度且易出错
- 确保所有消费者使用相同的 connection factory 配置（尤其是 network timeouts、automatic recovery 开关）
- 若需严格顺序或独占处理，改用单消费者 + 并行线程池，而非多消费者抢占；抢占只适用于“完全独立、幂等”的任务
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
