confirm原理

  生產者將通道設定成confirm模式，一旦通道進入confirm模式，所有在通道上釋出的資訊就會有一個唯一的ID ，將資訊傳送到佇列之後，broker就會發送一個確認給生產者，這個確認是包含這個唯一ID ，這就可以保證每個資訊都能存到佇列的，如果資訊佇列是持久化的，那確認機制就會在進入磁碟後再發確認機制，broker回傳給生產者的確認資訊中deliver-tag欲包含可確認資訊的序列號，此外broker也可以設定basic.ack的multiple域u，表示到這個系列號之前的所有資訊都已經得到了處理。

優點

  非同步，在得到確認機制前也可以傳送其他資訊，出現異常會發送Nack。

開啟模式

  channel.confirmSelect();

非同步模式

  Channe.物件提供的Confirmlistener(）回撥方法只包含deliveryTag（當前chanel發出的訊息序號），我們需要自己為每一個channel維護一個UNconfirm的訊息系列集合，沒publish一條資料，集合中元素+1，每回調一次handleAck方法，UNconfirm集合刪掉相應的一條（multiple=false）或者多條（multiple=true）記錄。從程式執行效率上看，這個UNconfirm集合最好採用有序集合sortdeset存錯結構。