RabbitMQ 高級指南

1 RabbitMQ 簡介
1.1 介紹
　　RabbitMQ 是一個由 erlang 開發的基於 AMQP（Advanced Message Queue）協議的開源實現。用於在分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面都很是的優秀，是當前最主流的消息中間件之一。RabbitMQ 官網：http://www.rabbitmq.com

1.2 AMQP
　　AMQP 是應用層協議的一個開放標準，爲面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，一樣，消息使用者也不用知道發送者的存在。AMQP 的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。

1.3 系統架構

消息隊列的使用過程大概以下：

客戶端鏈接到消息隊列服務器，打開一個 channel；
客戶端聲明一個 exchange，並設置相關屬性；
客戶端聲明一個 queue，並設置相關屬性；
客戶端使用 routing key，在 exchange 和 queue 之間創建好綁定關係；
客戶端投遞消息到 exchange，exchange 接收到消息後，就根據消息的 key 和已經設置的 binding，進行消息路由，將消息投遞到一個或多個隊列裏。
如上圖所示：AMQP 裏主要說兩個組件，Exchange 和 Queue。綠色的X就是 Exchange ，紅色的是 Queue ，這二者都在 Server 端，又稱做 Broker，這部分是 RabbitMQ 實現的，而藍色的則是客戶端，一般有 Producer 和 Consumer 兩種類型。

1.4 幾個概念
P： 爲 Producer，數據的發送方；
C：爲 Consumer，數據的接收方；
Exchange：消息交換機，它指定消息按什麼規則，路由到哪一個隊列；
Queue：消息隊列載體，每一個消息都會被投入到一個或多個隊列；
Binding：綁定，它的做用就是把 exchange 和 queue 按照路由規則綁定起來；
Routing Key：路由關鍵字，exchange 根據這個關鍵字進行消息投遞；
vhost：虛擬主機，一個 broker 裏能夠開設多個 vhost，用做不一樣用戶的權限分離；
channel：消息通道，在客戶端的每一個鏈接裏，可創建多個 channel，每一個 channel 表明一個會話任務。

4 四種 Exchange 模式
　　AMQP 協議中的核心思想就是：生產者和消費者隔離，生產者從不直接將消息發送給隊列。生產者一般不知道是否一個消息會被髮送到隊列中，只是將消息發送到一個交換機。先由 Exchange 來接收，而後 Exchange 按照特定的策略轉發到 Queue 進行存儲。同理，消費者也是如此。Exchange 就相似於一個交換機，轉發各個消息分發到相應的隊列中。

　　RabbitMQ 提供了四種 Exchange 模式：fanout、direct、topic、header. 因爲 header 模式在實際使用中較少，所以本節只對前三種模式進行比較。

4.1 Fanout Exchange

全部發送到 Fanout Exchange 的消息都會被轉發到與該 Exchange 綁定（Binding）的全部 Queue 上。

Fanout Exchange 不須要處理 RouteKey，只須要簡單的將隊列綁定到 exchange 上，這樣發送到 exchange 的消息都會被轉發到與該交換機綁定的全部隊列上。相似子網廣播，每臺子網內的主機都得到了一份複製的消息。

因此，Fanout Exchange 轉發消息是最快的。

4.2 Direct Exchange

全部發送到 Direct Exchange 的消息被轉發到 RouteKey 中指定的 Queue.

Direct 模式可使用 RabbitMQ 自帶的 Exchange：default Exchange ，所以不須要將 Exchange 進行任何綁定（binding）操做 。消息傳遞時，RouteKey 必須徹底匹配，纔會被隊列接收，不然該消息會被拋棄。

4.3 Topic Exchange

全部發送到 Topic Exchange 的消息被轉發到全部關心 RouteKey 中指定 Topic 的 Queue 上，Exchange 將 RouteKey 和某 Topic 進行模糊匹配。此時隊列須要綁定一個 Topic，可使用通配符進行模糊匹配，符號#匹配一個或多個詞，符號匹配很少很多一個詞。所以log.#可以匹配到log.info.oa，可是log. 只會匹配到log.error.

因此，Topic Exchange 使用很是靈活。

5 RPC 遠程過程調用
　　在這一節中，主要講述 RabbitMQ RPC. 其實，RabbitMQ RPC 就是經過消息隊列（Message Queue）來實現 RPC 的功能，就是客戶端向服務端發送定義好的 Queue 消息，其中攜帶的消息就應該是服務端將要調用的方法的參數 ，並使用 Propertis 告訴服務端將結果返回到指定的 Queue.

5.1 RabbitMQ RPC 的特色
Message Queue 把全部的請求消息存儲起來，而後處理，和客戶端解耦；
Message Queue 引入新的結點，系統的可靠性會受 Message Queue 結點的影響；
Message Queue 是異步單向的消息。發送消息設計成是不須要等待消息處理的完成。
因此對於有同步返回需求的，Message Queue 是個不錯的方向。

5.2 普通 PRC 的特色
同步調用，對於要等待返回結果/處理結果的場景，RPC 是能夠很是天然直覺的使用方式，固然 RPC 也能夠是異步調用；
因爲等待結果，客戶端會有線程消耗。
若是以異步 RPC 的方式使用，客戶端線程消耗能夠去掉，但不能作到像消息同樣暫存消息請求，壓力會直接傳導到服務端。

5.3 適用場合說明
但願同步獲得結果的場合，RPC 合適。
但願使用簡單，則 RPC；RPC 操做基於接口，使用簡單，使用方式模擬本地調用。異步的方式編程比較複雜。
不但願客戶端受限於服務端的速度等，可使用 Message Queue.
5.4 RabbitMQ RPC工做流程

基本概念：

　　Callback queue 回調隊列，客戶端向服務器發送請求，服務器端處理請求後，將其處理結果保存在一個存儲體中。而客戶端爲了得到處理結果，那麼客戶在向服務器發送請求時，同時發送一個回調隊列地址reply_to.

　　Correlation id 關聯標識，客戶端可能會發送多個請求給服務器，當服務器處理完後，客戶端沒法辨別在回調隊列中的響應具體和那個請求時對應的。爲了處理這種狀況，客戶端在發送每一個請求時，同時會附帶一個獨有correlation_id屬性，這樣客戶端在回調隊列中根據correlation_id字段的值就能夠分辨此響應屬於哪一個請求。

流程說明：

• 當客戶端啓動的時候，它建立一個匿名獨享的回調隊列；
• 在 RPC 請求中，客戶端發送帶有兩個屬性的消息：一個是設置回調隊列的 reply_to 屬性，另外一個是設置惟一值的correlation_id屬性；
• 將請求發送到一個 rpc_queue 隊列中；
• 服務器等待請求發送到這個隊列中來，當請求出現的時候，它執行他的工做而且將帶有執行結果的消息發送給 reply_to 字段指定的隊列；
• 客戶端等待回調隊列裏的數據。當有消息出現的時候，它會檢查correlation_id屬性，若是此屬性的值與請求匹配，將它返回給應用。