• ????歡迎點贊 ：???? 收藏 ?留言 ???? 如有錯誤敬請指正，賜人玫瑰，手留余香！

• ????本文作者：由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的內容非常多，這里僅僅介紹了一些很小的要點，后續有時間仍需要繼續學習！

例行小結，理性看待！

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

????都看到這了，還在乎點個贊嗎？

????都點贊了，還在乎一個收藏嗎？

????都收藏了，還在乎一個評論嗎？

總結

以上是生活随笔為你收集整理的理论修炼之RabbitMQ，消息队列服务的稳健者的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。