RabbitMQ實戰(zhàn)：消息通信模式和最佳實踐

本系列是「RabbitMQ實戰(zhàn)：高效部署分布式消息隊列」書籍的總結(jié)筆記。

通過前2篇的介紹，了解了消息通信的主要元素和交互過程，以及如何運行和管理RabbitMQ，這篇將站在開發(fā)模式的角度理解「面向消息通信」帶來的好處，以及在各種場景下的最佳實踐。

通過介紹，你會了解到：

• 面向消息通信的好處
• 發(fā)后即忘模型
• 用RabbitMQ實現(xiàn)RPC

面向消息通信的好處

主要從異步狀態(tài)思維、處理能力擴展性、集成復(fù)雜度方面，說明面向消息通信的好處。

異步狀態(tài)思維

當將消息通信集成到應(yīng)用程序時，開發(fā)模式將從同步模型變?yōu)楫惒侥Ｐ停琑abbitMQ提供了不同的方法，允許我們在一處發(fā)送請求，在另一處進行處理，這樣同步程序可以繼續(xù)執(zhí)行其他邏輯。

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

• 用戶填寫信用卡號、發(fā)卡銀行、持卡人姓名、還款金額，提交還款申請；
• 支付寶會立即提示用戶，申請已提交，多少小時內(nèi)完成還款；
• 還款完成后，會推送給用戶一條消息，提醒還款是否成功；

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

異步的思維是將請求和處理分離，在應(yīng)用中緊密耦合的兩部分中間使用RabbitMQ，請求解析后，發(fā)送一條業(yè)務(wù)能夠理解的消息到RabbitMQ，就返回給用戶，真正的處理由另外的服務(wù)異步處理。

擴展性

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

因為RabbitMQ可以將請求在處理服務(wù)器間平均地分發(fā)，不需要負載均衡器了。

零成本API

系統(tǒng)間相互調(diào)用，需要約定一套API，通常來講，需要花費一點點時間，編寫一大段代碼將傳入的HTTP請求轉(zhuǎn)化為應(yīng)用程序中的函數(shù)調(diào)用。

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

發(fā)后即忘模型

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

匹配該模式的兩種類型任務(wù)：

• 批處理：針對大型數(shù)據(jù)集合的工作或者轉(zhuǎn)換，多個任務(wù)對數(shù)據(jù)集合的獨立部分進行操作；
• 通知：對發(fā)送事件的描述，可以是消息的日志，或者通知另一個程序或者管理員；

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

用RabbitMQ實現(xiàn)RPC

有多種方式來實現(xiàn)遠程過程調(diào)用RPC，比如REST API、SOAP、Thrift等，這些傳統(tǒng)的RPC實現(xiàn)方法有共同之處：客戶端和服務(wù)器緊密相連、而且要等待返回結(jié)果。另外考慮這些問題：

• 當有多個服務(wù)節(jié)點時，客戶端如何發(fā)現(xiàn)對應(yīng)服務(wù)器；
• 如果客戶端連接的RPC服務(wù)器崩潰了，客戶端需要額外邏輯進行重連；

通過MQ服務(wù)器來實現(xiàn)時，只是簡單地發(fā)布消息而已，將消息路由到合適的地方放，通過多臺RPC服務(wù)器對消息進行負載均衡，當處理消息的服務(wù)器崩潰時，將RPC消息重發(fā)到另一臺。

現(xiàn)在的問題在于，如果將應(yīng)答返回給客戶端？

RabbitMQ使用消息來發(fā)回應(yīng)答，在AMQP消息頭里有一個字段叫做reply_to，消息的生成者可以通過該字段來確定隊列名稱，并監(jiān)聽隊列等待應(yīng)答，消息接收者能夠檢查reply_to字段，并創(chuàng)建包含應(yīng)答內(nèi)容的新的消息，并以隊列名稱作為路由鍵。

關(guān)于reply_to的隊列名稱，如果生成者聲明了沒有名字的隊列，RabbitMQ為自動生成一個唯一的隊列名，同時在聲明的時候指定exclusive參數(shù)，確保只有創(chuàng)建隊列的生產(chǎn)者可以讀取隊列上的消息。

這樣，所有RPC客戶端要做的，就是聲明臨時的、排他的、匿名隊列，并將該隊列名稱包含到RPC消息的reply_to頭中，這樣服務(wù)器端就知道應(yīng)答消息該發(fā)往哪兒了。

很多場景使用「發(fā)后即忘」模型，不需要處理者響應(yīng)，如果需要響應(yīng)，可以使用RabbitMQ的RPC模型。

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

歡迎掃描下方二維碼，關(guān)注我的個人微信公眾號 ~