一 mandatory 引數 上一篇文章中我們知道，生產者將訊息傳送到RabbitMQ的交換器中通過RoutingKey與BindingKey的匹配將之路由到具體的佇列中以供消費者消費。那麼當我們通過匹配規則找不到佇列的時候，訊息將何去何從呢?Rabbit給我們提供了兩種方式。mandatory與備份交換器。
mandatory引數是channel.BasicPublish方法中的引數。其主要功能是訊息傳遞過程中不可達目的地時將訊息返回給生產者。當mandatory 引數設為true 時，交換器無法根據自身的型別和路由鍵找到一個符合條件的佇列，那麼RabbitMQ 會呼叫BasicReturn 命令將訊息返回給生產者。當mandatory 引數設定為false 時。則訊息直接被丟棄。其運轉流程與實現程式碼如下(以C# RabbitMQ.Client 3.6.9為例):
複製程式碼當訊息不能路由到佇列時，通過mandatory設定引數,我們可以將訊息返回給生產者處理。但這樣會有一個問題，就是生產者需要開一個回撥的函式來處理不能路由到的訊息，這無疑會增加生產者的處理邏輯。備份交換器(Altemate Exchange)則提供了另一種方式來處理不能路由的訊息。備份交換器可以將未被路由的訊息儲存在RabbitMQ中，在需要的時候去處理這些訊息。其主要實現程式碼如下:
複製程式碼備份交換器其實和普通的交換器沒有太大的區別，為了方便使用，建議設定為fanout型別，若設定為direct 或者topic的型別。需要注意的是，訊息被重新傳送到備份交換器時的路由鍵和從生產者發出的路由鍵是一樣的。考慮這樣一種情況，如果備份交換器的型別是direct,並且有一個與其繫結的佇列，假設繫結的路由鍵是key1，當某條攜帶路由鍵為key2 的訊息被轉發到這個備份交換器的時候，備份交換器沒有匹配到合適的佇列，則訊息丟失。如果訊息攜帶的路由鍵為keyl，則可以儲存到佇列中。 對於備份交換器，有以下幾種特殊情況:
1.如果設定的備份交換器不存在，客戶端和RabbitMQ 服務端都不會有異常出現，此時訊息會丟失。
2.如果備份交換器沒有繫結任何佇列，客戶端和RabbitMQ 服務端都不會有異常出現，此時訊息會丟失。
3.如果備份交換器沒有任何匹配的佇列，客戶端和RabbitMQ 服務端都不會有異常出現，此時訊息會丟失。
4.如果備份交換器和mandatory引數一起使用，那麼mandatory引數無效。
三 過期時間(TTL)
3.1 設定訊息的TTL 目前有兩種方法可以設定訊息的TTL。第一種方法是通過佇列屬性設定，佇列中所有訊息都有相同的過期時間。第二種方法是對訊息本身進行單獨設定，每條訊息的TTL可以不同。如果兩種方法一起使用，則訊息的TTL 以兩者之間較小的那個數值為準。訊息在佇列中的生存時間一旦超過設定的TTL值時，就會變成"死信" (Dead Message) ，消費者將無法再收到該訊息。(有關死信佇列請往下看)
通過佇列屬性設定訊息TTL的方法是在channel.QueueDeclare方法中加入x-message-ttl引數實現的，這個引數的單位是毫秒。示例程式碼下:
複製程式碼針對每條訊息設定TTL的方法是在channel.BasicPublish方法中加入Expiration的屬性引數，單位為毫秒。關鍵程式碼如下：
複製程式碼3.2 設定佇列的TTL 注意，這裡和上述通過佇列設定訊息的TTL不同。上面刪除的是訊息，而這裡刪除的是佇列。通過channel.QueueDeclare 方法中的x-expires引數可以控制佇列被自動刪除前處於未使用狀態的時間。這個未使用的意思是佇列上沒有任何的消費者，佇列也沒有被重新宣告，並且在過期時間段內也未呼叫過channel.BasicGet命令。
設定佇列裡的TTL可以應用於類似RPC方式的回覆佇列，在RPC中，許多佇列會被建立出來，但是卻是未被使用的(有關RabbitMQ實現RPC請往下看)。RabbitMQ會確保在過期時間到達後將佇列刪除，但是不保障刪除的動作有多及時。在RabbitMQ 重啟後， 持久化的佇列的過期時間會被重新計算。用於表示過期時間的x-expires引數以毫秒為單位， 井且服從和x-message-ttl一樣的約束條件，不同的是它不能設定為0(會報錯)。
複製程式碼示例程式碼如下：
在此我向大家推薦一個架構學習交流群。交流學習群號：874811168 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
訊息被拒絕(BasicReject/BasicNack) ，井且設定requeue 引數為false;(消費者確認機制將會在下一篇文章中涉及) 訊息過期; 佇列達到最大長度。 DLX也是一個正常的交換器，和一般的交換器沒有區別，它能在任何的佇列上被指定，實際上就是設定某個佇列的屬性。當這個佇列中存在死信時，RabbitMQ 就會自動地將這個訊息重新發布到設定的DLX上去，進而被路由到另一個佇列，即死信佇列。可以監聽這個佇列中的訊息、以進行相應的處理。
通過在channel.QueueDeclare 方法中設定x-dead-letter-exchange引數來為這個佇列新增DLX。其示例程式碼如下:
複製程式碼五 延遲佇列 RabbitMQ本身並未提供延遲佇列的功能。延遲佇列是一個邏輯上的概念，可以通過過期時間+死信佇列來模擬它的實現。延遲佇列的邏輯架構大致如下:
生產者將訊息傳送到過期時間為n的佇列中，這個佇列並未有消費者來消費訊息，當過期時間到達時，訊息會通過死信交換器被轉發到死信佇列中。而消費者從死信佇列中消費訊息。這個時候就達到了生產者釋出了訊息在講過了n時間後消費者消費了訊息，起到了延遲消費的作用。
延遲佇列在我們的專案中可以應用於很多場景，如：下單後兩個訊息取消訂單，七天自動收貨，七天自動好評，密碼凍結後24小時解凍，以及在分散式系統中訊息補償機制(1s後補償,10s後補償，5m後補償......)。
複製程式碼六 優先順序佇列 就像我們生活中的“特殊”人士一樣，我們的業務上也存在一些“特殊”訊息，可能需要優先進行處理，在生活上我們可能會對這部分特殊人士開闢一套VIP通道，而Rabbit同樣也有這樣的VIP通道(前提是在3.5的版本以後)，即優先順序佇列，佇列中的訊息會有優先順序優先順序高的訊息具備優先被消費的特權。針對這些VIP訊息，我們只需做兩件事:
我們只需做兩件事情：
將佇列宣告為優先順序佇列，即在建立佇列的時候新增引數 x-max-priority 以指定最大的優先順序，值為0-255（整數）。 為優先順序訊息新增優先順序。 其示例程式碼如下:
關於優先順序佇列，好像違背了佇列這種資料結構先進先出的原則，其具體是怎麼實現的在這裡就不過多討論。有興趣的可以自己研究研究。後續可能也會有相關的文章來分析其原理。
複製程式碼七 RPC 實現 RPC,是Remote Procedure Call 的簡稱，即遠端過程呼叫。它是一種通過網路從遠端計算機上請求服務，而不需要了解底層網路的技術。RPC 的主要功用是讓構建分散式計算更容易，在提供強大的遠端呼叫能力時不損失本地呼叫的語義簡潔性。
有關RPC不多介紹，這裡我們主要介紹RabbitMQ如何實現RPC。RabbitMQ 可以實現很簡單的RPC。客戶端傳送請求訊息，服務端回覆響應的訊息，為了接收響應的訊息，我們需要在請求訊息中傳送一個回撥佇列(可以使用預設的佇列)。其伺服器端實現程式碼如下:
複製程式碼ReplyTo: 通常用來設定一個回撥佇列。 CorrelationId : 用來關聯請求(request) 和其呼叫RPC 之後的回覆(response) 。 其處理流程如下:
當客戶端啟動時，建立一個匿名的回撥佇列。 客戶端為RPC 請求設定2個屬性: ReplyTo用來告知RPC 服務端回覆請求時的目的佇列，即回撥佇列; Correlationld 用來標記一個請求。 請求被髮送到RpcQueue佇列中。 RPC 服務端監聽RpcQueue佇列中的請求，當請求到來時，服務端會處理並且把帶有結果的訊息傳送給客戶端。接收的佇列就是ReplyTo設定的回撥佇列。 客戶端監昕回撥佇列，當有訊息時，檢查Correlationld 屬性，如果與請求匹配，那就是結果了。
在此我向大家推薦一個架構學習交流群。交流學習群號：874811168 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
結束語 本篇文章簡單介紹了RabbitMQ在我們專案開發中常用的幾種特性。這些特性可以幫助我們更好的將Rabbit用於我們不同的業務場景中。這些特性與示例，可以自己在程式中執行一下，然後通過檢視Rabbit提供的web管理介面來驗證其正確性(關於web管理介面不多介紹，相信大家稍微研究研究就能明白)。當然，關於Rabbit的使用，仍有許多地方在本文中沒有提及，如：RabbitMQ的特色——確認機制、持久化......將在下一篇文章中再詳細介紹。