RabbitMQ實戰：消息通信模式和最佳實踐

本系列是「RabbitMQ實戰：高效部署分散式消息隊列」書籍的總結筆記。

通過前2篇的介紹，了解了消息通信的主要元素和交互過程，以及如何運行和管理RabbitMQ。

通過介紹，你會了解到：

面向消息通信的好處

發後即忘模型

用RabbitMQ實現RPC

面向消息通信的好處

主要從非同步狀態思維、處理能力擴展性、集成複雜度方面，說明面向消息通信的好處。

非同步狀態思維

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

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

用戶填寫信用卡號、發卡銀行、持卡人姓名、還款金額，提交還款申請；

支付寶會立即提示用戶，申請已提交，多少小時內完成還款；

還款完成後，會推送給用戶一條消息，提醒還款是否成功；

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

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

擴展性

隨著業務的擴展，對服務處理能力的要求越來越高，RabbitMQ可以很簡單的增加處理能力。

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

零成本API

系統間相互調用，需要約定一套API，通常來講，需要花費一點點時間，編寫一大段代碼將傳入的HTTP請求轉化為應用程序中的函數調用。

如果使用AMQP來連接應用程序的各個部分，無需額外定義API，使用消息通信即可。另外， AMQP是語言無關的，擁有數十種語言的本地語言綁定。

發後即忘模型

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

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

批處理：針對大型數據集合的工作或者轉換，多個任務對數據集合的獨立部分進行操作；

通知：對發送事件的描述，可以是消息的日誌，或者通知另一個程序或者管理員；

書上介紹的實例比較簡單，就不在此列出了，主要是根據不同的場景，確定交換器的類型和routingkey，可以參考上一篇介紹的「收集日誌」的例子進行理解。

用RabbitMQ實現RPC

有多種方式來實現遠程過程調用RPC，比如REST API、SOAP、Thrift等，這些傳統的RPC實現方法有共同之處：客戶端和伺服器緊密相連、而且要等待返回結果。另外考慮這些問題：

當有多個服務節點時，客戶端如何發現對應伺服器；

如果客戶端連接的RPC伺服器崩潰了，客戶端需要額外邏輯進行重連；

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

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

RabbitMQ使用消息來發回應答，在AMQP消息頭裡有一個欄位叫做reply_to，消息的生成者可以通過該欄位來確定隊列名稱，並監聽隊列等待應答，消息接收者能夠檢查reply_to欄位，並創建包含應答內容的新的消息，並以隊列名稱作為路由鍵。

關於reply_to的隊列名稱，如果生成者聲明了沒有名字的隊列，RabbitMQ為自動生成一個唯一的隊列名，同時在聲明的時候指定exclusive參數，確保只有創建隊列的生產者可以讀取隊列上的消息。

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

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

下一篇將介紹RabbitMQ集群和高可用性以及它們的設置。

老爸和小妹今天回去了，期待下一次的團聚

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！