在消息隊列（如 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 機制）