rabbitmq 重復確認導致消息丟失
背景
rabbitmq 在應用場景中，大多采用工作隊列 work-queue的模式。
在一個常見的工作隊列模式中，消費者 worker 將不斷的輪詢從隊列中拉取最新消息，當隊列負載壓力增大時允許添加多個worker 進行處理。
然而執行一個任務可能需要相當的時長，這是由業務特性所決定的；如果 worker執行任務過程中出現異常甚至宕機，此時消息便會丟失，這是簡單消息隊列難以解決的問題。
rabbitmq 采用了消息確認機制來防止此類問題，在該機制中，worker需要向 MQ Server 返回 ACK響應以表示消息已確認處理；
在以下情況下，rabbitmq 會對消息進行重新投遞：
1 client 未響應ACK, 主動關閉 Channel；
2 client 未響應ACk, 網絡異常斷開；
消息的重發機制沒有超時限制，只要client 不響應ACK，那么會一直投遞；
如果啟用了消息持久化機制，那么消息將有進一步的保障。
問題描述及分析
1 客戶端為簡化應答處理，可以設置自動應答選項，如：
boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck, consumer); 2 如果不啟用自動應答，需要應用代碼手動進行應答：
try { doWork(message); } finally { logger.info(" xxx work done"); channel.basicAck(envelope.getDeliveryTag(), false); } 3 當兩種方案同時存在
由於客戶端的編碼失誤，先啟用了自動應答選項，又在應用代碼執行了應答的代碼： // enable autoAck boolean autoAck = true; consumerChannel.basicConsume(queueName, autoAck, this); //... // snipper from Consumer.handleDelivery method // send ack to server try { consumerChannel.basicAck(deliveryTag, true); } catch (Exception e) { } 多了一次確認，應用代碼貌似一切如常。 但在頻繁進行消息收發測試時發現 消息存在隨機性丟失處理的情況！
檢查 rabbitmq server日志發現以下異常：
{amqp_error,precondition_failed,"unknown delivery tag 1",'basic.ack'} ... {amqp_error,precondition_failed,"unknown delivery tag 1",'basic.ack'} ... {amqp_error,precondition_failed,"unknown delivery tag 1",'basic.ack'} ... 提示未知的 delivery tag=1，該字段為MQ server 用於消息確認的標記，服務端因無法識別而打印錯誤。
另外一個現象則是，連續收發消息 5次，其中丟失消息處理1次，而 rabbitmq server錯誤日志出現 4次！
經過分析，發現問題原因所在：
rabbitmq 為每一個channel維護了一個delivery tag的計數器，這里采用正向自增，新消息投遞時自增，當消息響應時自減；
在連續收發的場景中，由於消息發送的間隔較短，部分消息因 consumer的重復確認被rabbitmq 當做已處理而丟棄。
解決方案
取消consumer 的自動應答機制，僅保留手動應答的處理，問題解決。
參考資料
關於 rabbitmq 消息確認機制：
http://www.rabbitmq.com/confirms.html#when