@SpringBootApplication

@EnableDiscoveryClient

@EnableAutoConfiguration

@ComponentScan

@EnableEurekaClient

@FeignClient（value = “youfanrobbinserver”）

因為Eureka中已經集成了Ribbon，所以我們無需引入新的依賴

在生產者傳送訊息之前，透過channel。txSelect開啟一個事務，接著傳送訊息， 如果訊息投遞server失敗，進行事務回滾channel。txRollback，然後重新發送， 如果server收到訊息，就提交事務channel。txCommit

但是，很少有人這麼幹，因為這是同步操作，一條訊息傳送之後會使傳送端阻塞，以等待RabbitMQ Server的迴應，之後才能繼續傳送下一條訊息，生產者生產訊息的吞吐量和效能都會大大降低

非同步confirm模式

非同步模式需要自己多寫一部分複雜的程式碼實現，非同步監聽類，監聽server端的通知訊息，非同步的好處效能會大幅度提升，傳送完畢之後，可以繼續傳送其他訊息。 MQServer通知生產端ConfirmListener監聽類：使用者可以繼承介面實現自己的實現類，處理訊息確認機制

出錯

channel3 傳送的訊息失敗了，生產端需要對投遞訊息重新投遞，需要額外處理程式碼。 那麼生產端需要做什麼事情呢？因為是非同步的，生產端需要儲存訊息然後根據server通知的訊息，確認如何處理，於是我們面臨的問題是：

第一：傳送訊息之前把訊息存起來

第二：監聽ack 和 nack 並做響應處理

那麼怎麼儲存呢？

我們分析下，可以使用SortedMap 儲存，保證有序，但是有個問題高併發情況下， 每秒可能幾千甚至上萬的訊息投遞出去，訊息的ack要等幾百毫秒的話，放記憶體可能有記憶體溢位的風險。所以建議採用KV儲存，KV儲存承載高併發能力高，效能好，但是要保證KV 高可用，單個有個缺點就是又引入了第三方中介軟體，複雜度升高。

丟失

事務機制和publisher confirm機制確保的是訊息能夠正確的傳送至RabbitMQ，這裡的“傳送至RabbitMQ”的含義是指訊息被正確的發往至RabbitMQ的交換器，如果此交換器沒有匹配的佇列的話，那麼訊息也將會丟失，怎麼辦？

這裡有兩個解決方案，

1。 使用mandatory 設定true

* 當mandatory標誌位設定為true時，如果exchange根據自身型別和訊息routeKey無法找到一個符合條件的queue， 那麼會呼叫basic。return方法將訊息返回給生產者

* 當mandatory設定為false時，出現上述情形broker會直接將訊息扔掉。

* 當immediate標誌位設定為true時，如果exchange在將訊息路由到queue（s）時發現對於的queue上沒有消費者， 那麼這條訊息不會放入佇列中。

當immediate標誌位設定為false時，exchange路由的佇列沒有消費者時，該訊息會透過basic。return方法返還給生產者。

* RabbitMQ 3。0版本開始去掉了對於immediate引數的支援，對此RabbitMQ官方解釋是：這個關鍵字違背了生產者和消費者之間解耦的特性，因為生產者不關心訊息是否被消費者消費掉

2。 利用備份交換機（alternate-exchange）：實現沒有路由到佇列的訊息

此時有人問了，不想複雜化生產者的程式設計邏輯，又不想訊息丟失，那麼怎麼辦？ 還好RabbitMQ提供了一個叫做alternate-exchange東西，翻譯下就是備份交換器，這個幹什麼用呢？很簡單，它可以將未被路由的訊息儲存在另一個exchange佇列中，再在需要的時候去處理這些訊息。

那如何實現呢？

簡單一點可以透過webui管理後臺設定，當你新建一個exchange業務的時候，可以給它設定Arguments，這個引數就是 alternate-exchange，其實alternate-exchange就是一個普通的exchange，型別最好是fanout 方便管理

當你傳送訊息到你自己的exchange時候，對應key沒有路由到queue，就會自動轉移到alternate-exchange對應的queue，起碼訊息不會丟失。

那麼有人有個疑問，上面介紹了，兩種方式處理，傳送的訊息無法路由到佇列的方案， 如果備份交換器和mandatory引數一起使用，會有什麼效果？

答案是：mandatory引數無效