RabbitMQ實戰訊息通訊模式和最佳實踐

本系列是「rabbitmq實戰：高效部署分布式訊息佇列」書籍的總結筆記。

通過介紹，你會了解到：

主要從非同步狀態思維、處理能力擴充套件性、整合複雜度方面，說明面向訊息通訊的好處。

非同步狀態思維

當將訊息通訊整合到應用程式時，開發模式將從同步模型變為非同步模型，rabbitmq提供了不同的方法，允許我們在一處傳送請求，在另一處進行處理，這樣同步程式可以繼續執行其他邏輯。

舉個簡單的例子來說明，通過支付寶還信用卡：

如果是同步請求，使用者需要等待幾個小時檢視結果，等待過程中不能進行其他操作，這是很不合理的。

非同步的思維是將請求和處理分離，在應用中緊密耦合的兩部分中間使用rabbitmq，請求解析後，傳送一條業務能夠理解的訊息到rabbitmq，就返回給使用者，真正的處理由另外的服務非同步處理。

擴充套件性隨著業務的擴充套件，對服務處理能力的要求越來越高，rabbitmq可以很簡單的增加處理能力。

因為rabbitmq可以將請求在處理伺服器間平均地分發，不需要負載均衡器了。

零成本api

系統間相互呼叫，需要約定一套api，通常來講，需要花費一點點時間，編寫一大段**將傳入的http請求轉化為應用程式中的函式呼叫。

如果使用amqp來連線應用程式的各個部分，無需額外定義api，使用訊息通訊即可。另外， amqp是語言無關的，擁有數十種語言的本地語言繫結。

當考慮訊息通訊能夠解決的問題型別時，訊息通訊適用的主要領域是的「發後即忘」處理模式。關心的是任務將會完成，但無須實時完成，建立乙個任務，傳送到交換器上後，就可以返回繼續工作，甚至都不需要通知使用者任務已經完成。

匹配該模式的兩種型別任務：

有多種方式來實現遠端過程呼叫rpc，比如rest api、soap、thrift等，這些傳統的rpc實現方法有共同之處：客戶端和伺服器緊密相連、而且要等待返回結果。另外考慮這些問題：

通過mq伺服器來實現時，只是簡單地發布訊息而已，將訊息路由到合適的地方放，通過多台rpc伺服器對訊息進行負載均衡，當處理訊息的伺服器崩潰時，將rpc訊息重發到另一台。

現在的問題在於，如果將應答返回給客戶端？

rabbitmq使用訊息來發回應答，在amqp訊息頭里有乙個字段叫做reply_to，訊息的生成者可以通過該字段來確定佇列名稱，並監聽佇列等待應答，訊息接收者能夠檢查reply_to欄位，並建立包含應答內容的新的訊息，並以佇列名稱作為路由鍵。

關於reply_to的佇列名稱，如果生成者宣告了沒有名字的佇列，rabbitmq為自動生成乙個唯一的佇列名，同時在宣告的時候指定exclusive引數，確保只有建立佇列的生產者可以讀取佇列上的訊息。

這樣，所有rpc客戶端要做的，就是宣告臨時的、排他的、匿名佇列，並將該佇列名稱包含到rpc訊息的reply_to頭中，這樣伺服器端就知道應答訊息該發往哪兒了。

很多場景使用「發後即忘」模型，不需要處理者響應，如果需要響應，可以使用rabbitmq的rpc模型。

RabbitMQ實戰 訊息通訊模式和最佳實踐