RabbitMQ 消息确认机制在 Linux 上的工作机制
一 核心概念与适用场景
- 在 Linux 上，RabbitMQ 的消息确认由两部分构成：生产者确认（Publisher Confirm） 与 消费者确认（Consumer ACK）。前者保证消息被 Broker 接收（并可感知是否路由到队列），后者保证消息被消费者成功处理后才会从队列移除。两种确认共同用于避免消息丢失与虚假消费。RabbitMQ 还提供 事务（txSelect/txCommit/txRollback） 与 Confirm 模式 两种生产者可靠性手段，其中 Confirm 性能更优，事务吞吐较低。
二 消费者确认的工作方式
- 确认模式
- 自动确认 autoAck=true：Broker 一旦把消息投递给消费者就立即标记为删除，若消费者处理中崩溃，消息会丢失，适合可靠性要求不高的场景。
- 手动确认 autoAck=false：消费者处理完成后显式发送 Basic.Ack；若未收到确认且消费者连接断开，Broker 会将消息重新入队投递给其他消费者。该模式无超时概念，处理耗时较长也不会被提前重投，除非连接断开。
- 确认与拒绝 API
- Basic.Ack(deliveryTag, multiple)：肯定确认；multiple=true 可一次性确认小于等于该 deliveryTag 的批量消息。
- Basic.Nack(deliveryTag, multiple, requeue)：否定确认并支持批量；requeue=true 表示重新入队，false 表示丢弃或进入死信（需配合死信队列）。
- Basic.Reject(deliveryTag, requeue)：单条否定确认，语义同 Nack 的单条版。
- 队列状态与监控
- Web 管理界面或命令行可查看队列的 Ready（待投递）与 Unacked（已投递未确认）计数，用于判断是否有消息堆积或确认滞后。
- Linux 下可用命令查看：
- rabbitmqctl list_queues name messages_ready messages_unacknowledged
- 重要特性
- 确认是“至少一次”语义：未确认的消息在消费者断开时会重投，业务需具备幂等性处理。
三 生产者确认的工作方式
- Confirm 模式（推荐）
- 开启：在 Channel 上调用 confirmSelect()；Broker 对每条消息或按批量返回 Basic.Ack/Nack，其中 multiple 字段可指示是否对序列号之前的消息一并确认。
- 异步回调：通过 ConfirmCallback 感知消息是否被 Broker 接收；配合 ReturnCallback 可捕获消息到达 Exchange 但无法路由到队列的情况（需设置 mandatory=true）。
- 事务模式（低吞吐）
- 通过 txSelect/txCommit/txRollback 保证消息投递的原子性，但会显著降低性能，通常仅在一致性要求极高且并发不高时考虑。
- 典型流程
- 生产者开启 Confirm → 发送消息并携带唯一 CorrelationData → 监听 ConfirmCallback/ReturnCallback 处理结果 → 失败按策略重试或落库告警。
四 Linux 下的实践要点
- 开启手动确认与合理重试
- Spring Boot 示例（消费者）：
- listener: simple: acknowledge-mode: manual
- 在监听器内按业务成功调用 channel.basicAck，异常时根据业务选择 nack+requeue 或 nack+不回队列（进入死信）。
- 观察确认滞后与堆积
- 使用命令持续观察队列 Ready/Unacked：
- watch -n 1 ‘rabbitmqctl list_queues name messages_ready messages_unacknowledged’
- 若出现 Unacked 持续增长，常见原因为：消费者处理慢、未正确 ack、异常导致未 ack、消费者进程数不足等。
- 避免消息堆积与内存压力
- 未确认消息会占用内存且无法释放；应控制并发、优化处理时长、确保异常分支也能 ack/nack，必要时增加消费者实例或优化下游处理链路。