理論修煉之RabbitMQ，消息隊列服務的穩健者

這是我參與8月更文挑戰的第12天，活動詳情查看：8月更文挑戰

• 📢歡迎點贊 ：👍 收藏 ⭐留言 📝 若有錯誤敬請指正，賜人玫瑰，手留餘香！
• 📢本文做者：由webmote 原創，首發於 【掘金】
• 📢做者格言： 生活在於折騰，當你不折騰生活時，生活就開始折騰你，讓咱們一塊兒加油！💪💪💪

🎏 序言

在ETCD節有講過，對於架構師來講，對中間件的理論研究和熟悉不是過度的要求，之前大意了，主要偏向應用層了，今天就來學習RabbitMQ，這個消息隊列服務的穩健者。

固然因爲RabbitMQ內容比較豐富，所以這裏先闡述下消息組件的幾種模式，而後注重於鏈接管理。其餘章節後續也許會進一步學習，有所得必和你們分享。

🎏 01. RabbitMQ支持的幾種隊列模式

仍是這個圖精簡，一會兒就看完了6種模式。

🎏 01.1 簡單隊列模式

1個生產者，1個消費者。這種模式下消費者是按照消息的生產順序嚴格進行消費的，能夠看做是嚴格順序消息隊列。

🎏 01.2 工做隊列

1個生產者，多個消費者，消費者按照次序逐次把消息排放到各個消費者。所以默認狀況下，消費的調度並非按照工做量來的，而是按照順序公平調度來的。

幸運的是RabbitMQ提供了參數，能夠修改使用帶有prefetch_count=1設置的Channel#basic_qos方法 。這使用basic.qos協議方法告訴 RabbitMQ 一次不要給一個工人多個消息。或者，換句話說，在處理並確認前一條消息以前，不要向工做人員發送新消息。相反，它會將它分派給下一個不忙的工人。

channel.basic_qos(prefetch_count= 1 )
複製代碼

🎏 01.3 發佈、訂閱模式

也是1個生產者，多個消費者，不過與上面方案不一樣的是每個消費者都有本身的一個隊列。

生產者將消息直髮送到交換機，每一個隊列都要綁定到交換機。有幾種可用的交換類型：direct、topic、headers 和fanout。咱們將關注最後一個——它就是廣播(fanout)

所以不管交換機綁定多少隊列，交換機總會保證消息被廣播給每個隊列。

🎏 01.4 路由模式

仍然是多個消費者，生產者嘛，就不必定了。 這裏生產者把消息發送到 direct類型的交換機上。該交換機按照綁定的Key路由消息到固定的隊列。

🎏 01.5 主題模式

主題模式相比路由模式，其更靈活，按照訂閱的主題創建相關隊列，交換機按照主題路由消息到各個隊列。

這裏一條消息若是負責多個隊列的規則，則消息被路由分發到多個隊列。固然若是多個規則都匹配一條消息，在一個隊列內這條消息也僅被路由1次。

主題能夠支持通配符*和#。

🎏 01.6 RPC模式

你們都知道RPC是遠程過程調用，其能夠返回調用後執行的結果值，所以經過RPC模式，能夠利用RabbitMQ構建一個基於RPC通信的分佈式微服務系統。

🎏 02 客戶端鏈接

這裏的鏈接介紹基於.net client sdk，固然java的客戶端也是相似。但其餘客戶端sdk可能會不太同樣，所以謹慎參考。

RabbitMQ 支持的全部協議都是基於 TCP 的，並維持長鏈接（每一個協議操做不打開新鏈接）以提升效率。

當再也不須要鏈接時，應用程序必須關閉它們以節省資源。不然可能出現鏈接泄露問題，有最終耗盡其目標資源節點的風險。

若是咱們使用rabbitmq的監控面板，請注意:RabbitMQ 記錄全部發送至少 1 字節數據的入站客戶端鏈接。不會記錄在沒有任何活動的狀況下打開的鏈接。

利用監控面板，能夠輕鬆監控鏈接的泄露狀況。

固然若是頻繁打開關閉鏈接，對系統的性能也會形成影響，咱們也能夠監控是否頻繁打開關閉鏈接。

發佈消息的鏈接可能速度很快，但讀和處理消息可能很慢，致使速度不匹配。這時，會自動觸發背壓式流，這時候讀消息不受影響，但寫受到流控控制，致使速度放慢。

.net client 和 java client的sdk均支持鏈接故障自動恢復，所以編程者幾乎不用作太多工做。

雖然標準的sdk提供了鏈接池管理，但並不是最優。而 spring 框架提供了豐富的鏈接池二次封裝，其能夠管理單連接多通道或多鏈接多通道模式的鏈接池，也提供了發佈確認等相關封裝。

做爲.net 開發者，咱們只有羨慕的份了，固然仿照其寫個.net版的也應該能夠，不過這個能力要求有點高，我試試寫一個看看。

🎏 03 強一致性方案

爲了保證消息中間件的強一致性，RabbitMQ提供了集羣鏡像功能，交換機和隊列持久化，以及發佈和訂閱消息的確認（ack）機制，所以咱們若是須要強一致性，那麼避免不了和這些技術打打交道。

經過發送消息、推送消息的確認ack方案，虛線表示，的確提高了消息投遞、消費的準確性。

而且確認ack均支持異步批量方案，所以數據的讀寫吞吐量不用擔憂受到影響。

生產者在採用批量ack時，能夠適當開啓緩存，緩存待確認的消息，能夠完美解決ack確認問題。

🎏 04. 小結

RabbitMQ的內容很是多，這裏僅僅介紹了一些很小的要點，後續有時間仍須要繼續學習！

例行小結，理性看待！

結的是啥啊，結的是我想你點贊而不可得的寂寞。😳😳😳

👓都看到這了，還在意點個贊嗎？

👓都點讚了，還在意一個收藏嗎？

👓都收藏了，還在意一個評論嗎？