在RabbitMQ之失敗確認中，我們提到失敗確認只會讓RabbitMQ向你通知失敗，而不會通知成功。如果消息正確路由到隊列，則發佈者不會受到任何通知。帶來的問題是無法確保發佈消息一定是成功的，因爲通知失敗的消息可能會丟失。
那麼我們如何能夠進一步的來保證其消息的可靠性呢？這裏我們就在想，要是RabbitMQ不僅僅在路由失敗的時候給我們發送消息，並且能夠在消息路由成功的時候也給我們發送消息就好了，這裏RabbitMQ就爲我們提供了該方案，即發送方確認模式。
原理： 生產者將信道設置成confirm模式，一旦信道進入confirm模式，所有在該信道上面發佈的消息都將會被指派一個唯一的ID(從1開始)，由這個id在生產者和RabbitMQ之間進行消息的確認。
發送方確認模式需要分兩種情況下列來看，首先我們先來看一看消息不可路由的情況，如下：
首先我們都知道，消息不可路由時，就不存在路由到隊列了，所以這裏只管到交換器的路徑，當消息成功送到交換器後，就會進行確認操作。
另外在這過程中，生產者接受到了確認消息後，那麼因爲消息無法路由，所以該消息也是無效的，所以一般情況下這裏會結合我們在RabbitMQ之失敗確認中介紹過失敗確認模式，這裏一般會進行設置mandatory模式，失敗則會調用addReturnListener監聽器來進行處理。
發送方確認模式的另一種情況肯定就是消息可以進行路由，如下：
可路由的消息，要等到消息被投遞到所有匹配的隊列之後，broker會發送一個確認給生產者(包含消息的唯一ID)，這就使得生產者知道消息已經正確到達目的隊列了。
如果消息和隊列是可持久化的，那麼確認消息會在將消息寫入磁盤之後發出，broker回傳給生產者的確認消息中delivery-tag域包含了確認消息的序列號。
RabbitMQ的發送方確認模式共有三種方式：
- 普通發送方確認模式
channel.waitForConfirms()普通發送方確認模式；每條消息都需要進行逐條確認，當消息到達交換器，就會返回true
![在這裏插入圖片描述]()
這裏我們就在RabbitMQ之失敗確認上的代碼基礎上進行修改了下，如上添加了發送者確認，測試結果如下：
- 批量確認模式
使用同步方式等所有的消息發送之後纔會執行後面代碼，只要有一個消息未到達交換器就會拋出IOException異常。
![在這裏插入圖片描述]()
這裏我們就可以在catch中進行一些業務處理，來處理消息發送失敗後的動作。
- 異步監聽發送方確認模式
channel.addConfirmListener()異步監聽發送方確認模式
![在這裏插入圖片描述]()
上述添加的ConfirmListener中，我們實現兩個方法，一個是發送成功的ack方法，另一個是發送失敗的nack方法，其中都有兩個參數deliveryTag、multiple，其中第一個表示消息的ID，由這個id在生產者和RabbitMQ之間進行消息的確認；第二個表示是否是批量確認。
在異步監聽發送方確認模式下，將有RabbitMQ幫我們來決定是否批量發送，這裏我們就是通過multiple來判斷的，測試結果如下：
從上述結果來看，我們共發送了3條消息，第一條消息(ID=1)，multiple爲false，是一條消息單獨發送確認的。
而第二、三條消息時批量確認的，deliveryTag返回的是最後一條消息的ID，multiple表示是多條消息批量確認。
這個結果我們多運行幾次，發現是又會不同的表現的，這裏就有RabbitMQ爲我們進行判斷。