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集羣和高可用性以及它們的設置。

歡迎掃描下方二維碼，關注個人我的微信公衆號 ~