在消息队列（如 RabbitMQ）中，**ACK（Acknowledgement）是消息确认机制**，用于确保消息被消费者成功处理。其核心作用是解决以下问题：

mermaid复制代码导出svg

---

📌 ACK 的两种模式

1. 自动确认模式 (Auto-ACK)

• 消费者收到消息时，RabbitMQ 立即删除队列中的消息
• 风险：若消费者处理消息时崩溃，消息永久丢失

python复制代码

channel.basic_consume(queue="my_queue",auto_ack=True,  # ⚠️ 危险模式on_message_callback=callback
)

2. 手动确认模式 (Manual ACK) ✅ 推荐

• 消费者处理完业务逻辑后，显式发送 ACK
• RabbitMQ 收到 ACK 后才删除消息
• 处理失败时可拒绝消息（NACK）

python复制代码

def callback(channel, method, properties, body):try:process_message(body)  # 业务处理channel.basic_ack(delivery_tag=method.delivery_tag)  # ✅ 手动确认except Exception:# 处理失败：拒绝消息并重新入队channel.basic_nack(delivery_tag=method.delivery_tag, requeue=True)

---

🔧 ACK 的三大核心作用

场景	无 ACK 机制	开启手动 ACK
消费者崩溃	消息丢失 ❌	消息重新投递给其他消费者 ✅
处理逻辑出错	消息被误删除 ❌	触发重试机制 ✅
高并发场景	可能因消息积压导致内存溢出 ⚠️	控制消息流速（QoS）✅

---

🛠 最佳实践：手动 ACK + QoS

python复制代码

# 1. 设置每次只接收一条消息（避免消息积压）
channel.basic_qos(prefetch_count=1)  # 🚦 流量控制# 2. 消费消息（关闭自动ACK）
channel.basic_consume(queue="orders",auto_ack=False,  # ✋ 手动确认模式on_message_callback=process_order
)# 3. 在回调函数中显式ACK
def process_order(channel, method, properties, body):try:save_to_database(body)   # 业务操作charge_credit_card(body) # 关键业务channel.basic_ack(delivery_tag=method.delivery_tag)  # ✅ 确认except PaymentFailed:# 支付失败：消息重新入队等待重试channel.basic_nack(delivery_tag=method.delivery_tag, requeue=True)except InvalidOrder:# 无效订单：拒绝并不再重试channel.basic_reject(delivery_tag=method.delivery_tag, requeue=False)

---

⚠️ 关键注意事项

1. 忘记 ACK 的后果

   • 消息会一直保留在队列中（显示 Unacked 状态）
   • 导致消息堆积，最终阻塞整个队列

2. NACK 与 Reject 的区别

   • basic_nack()：支持批量拒绝多条消息
   • basic_reject()：只能拒绝单条消息

3. 死信队列配合
   当消息被拒绝且 requeue=False 时，可将其路由到死信队列进行分析：

   python复制代码

   # 声明队列时绑定死信交换机
   args = {"x-dead-letter-exchange": "dead_letter_exchange"}
   channel.queue_declare(queue="orders", arguments=args)
   

---

🌟 总结：ACK 的本质

ACK 是消息可靠性的最后一道防线
它通过 生产者 → RabbitMQ → 消费者 的闭环确认机制，实现：

• 至少一次投递（At Least Once Delivery）
• 防消息丢失（即使消费者崩溃）
• 业务可重试性（通过 NACK 机制）