欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

1. 背景

RabbitMQ 是一個由 erlang 開發的AMQP 開源實現，erlang語言天生具備高并發的特性，而且他的管理界面用起來十分方便。 

基礎概念

講解基礎概念的前面，我們先來整體構造一個結構圖，這樣會方便們更好地去理解RabbitMQ的基本原理。

 

通過上面這張應用相結合的結構圖既能夠清晰的看清楚整體的send Message到Receive Message的一個大致的流程。當然上面有很多名詞都相比還沒有介紹到，不要著急接下來我們就開始對其進行詳細的講解。

 2. Queue

　　Queue（隊列）RabbitMQ的作用是存儲消息，隊列的特性是先進先出。上圖可以清晰地看到Client A和Client B是生產者，生產者生產消息最終被送到RabbitMQ的內部對象Queue中去，而消費者則是從Queue隊列中取出數據。可以簡化成表示為：

?

　　生產者Send Message “A”被傳送到Queue中，消費者發現消息隊列Queue中有訂閱的消息，就會將這條消息A讀取出來進行一系列的業務操作。這里只是一個消費正對應一個隊列Queue，也可以多個消費者訂閱同一個隊列Queue，當然這里就會將Queue里面的消息平分給其他的消費者，但是會存在一個問題就是如果每個消息的處理時間不同，就會導致某些消費者一直在忙碌中，而有的消費者處理完了消息后一直處于空閑狀態，因為前面已經提及到了Queue會平分這些消息給相應的消費者。這里我們就可以使用prefetchCount來限制每次發送給消費者消息的個數。詳情見下圖所示：　　

　　這里的prefetchCount=1是指每次從Queue中發送一條消息來。等消費者處理完這條消息后Queue會再發送一條消息給消費者。

 3. Exchange

　　我們在開篇的時候就留了一個坑，就是那個應用結構圖里面，消費者Client A和消費者Client B是如何知道我發送的消息是給Queue1還是給Queue2，有沒有想過這個問題，那么我們就來解開這個面紗，看看到底是個什么構造。首先明確一點就是生產者產生的消息并不是直接發送給消息隊列Queue的，而是要經過Exchange（交換器），由Exchange再將消息路由到一個或多個Queue，當然這里還會對不符合路由規則的消息進行丟棄掉，這里指的是后續要談到的Exchange Type。那么Exchange是怎樣將消息準確的推送到對應的Queue的呢？那么這里的功勞最大的當屬Binding，RabbitMQ是通過Binding將Exchange和Queue鏈接在一起，這樣Exchange就知道如何將消息準確的推送到Queue中去。簡單示意圖如下所示：

　　在綁定（Binding）Exchange和Queue的同時，一般會指定一個Binding Key，生產者將消息發送給Exchange的時候，一般會產生一個Routing Key，當Routing Key和Binding Key對應上的時候，消息就會發送到對應的Queue中去。那么Exchange有四種類型，不同的類型有著不同的策略。也就是表明不同的類型將決定綁定的Queue不同，換言之就是說生產者發送了一個消息，Routing Key的規則是A，那么生產者會將Routing Key=A的消息推送到Exchange中，這時候Exchange中會有自己的規則，對應的規則去篩選生產者發來的消息，如果能夠對應上Exchange的內部規則就將消息推送到對應的Queue中去。那么接下來就來詳細講解下Exchange里面類型。

 4. Exchange Type

　　Exchange分為以下四種： 

4.1 fanout

　　fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。

　　上圖所示，生產者（P）生產消息1將消息1推送到Exchange，由于Exchange Type=fanout這時候會遵循fanout的規則將消息推送到所有與它綁定Queue，也就是圖上的兩個Queue最后兩個消費者消費。 

4.2 direct

　　direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。

　　當生產者（P）發送消息時Rotuing key=booking時，這時候將消息傳送給Exchange，Exchange獲取到生產者發送過來消息后，會根據自身的規則進行與匹配相應的Queue，這時發現Queue1和Queue2都符合，就會將消息傳送給這兩個隊列，如果我們以Rotuing key=create和Rotuing key=confirm發送消息時，這時消息只會被推送到Queue2隊列中，其他Routing Key的消息將會被丟棄。 

4.3 topic

　　前面提到的direct規則是嚴格意義上的匹配，換言之Routing Key必須與Binding Key相匹配的時候才將消息傳送給Queue，那么topic這個規則就是模糊匹配，可以通過通配符滿足一部分規則就可以傳送。它的約定是：

1. routing key為一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱為一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
2. binding key與routing key一樣也是句點號“. ”分隔的字符串
3. binding key中可以存在兩種特殊字符“*”與“#”，用于做模糊匹配，其中“*”用于匹配一個單詞，“#”用于匹配多個單詞（可以是零個）

    當生產者發送消息Routing Key=F.C.E的時候，這時候只滿足Queue1，所以會被路由到Queue中，如果Routing Key=A.C.E這時候會被同是路由到Queue1和Queue2中，如果Routing Key=A.F.B時，這里只會發送一條消息到Queue2中。

4.4 RPC

我們的RPC如此工作：
    ? 當客戶端啟動的時候，它創建一個匿名獨享的回調隊列。
    ? 在RPC請求中，客戶端發送帶有兩個屬性的消息：一個是設置回調隊列的 reply_to 屬性，另一個是設置唯一值的 correlation_id 屬性。
    ? 將請求發送到一個 rpc_queue 隊列中。
    ? RPC工作者（又名：服務器）等待請求發送到這個隊列中來。當請求出現的時候，它執行他的工作并且將帶有執行結果的消息發送給reply_to字段指定的隊列。

客戶端等待回調隊列里的數據。當有消息出現的時候，它會檢查correlation_id屬性。如果此屬性的值與請求匹配，將它返回給應用。

 5. 補充說明

ConnectionFactory、Connection、Channel：

ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory為Connection的制造工廠。
Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。
Connection就是建立一個TCP連接，生產者和消費者的都是通過TCP的連接到RabbitMQ Server中的，這個后續會再程序中體現出來。

Channel虛擬連接，建立在上面TCP連接的基礎上，數據流動都是通過Channel來進行的。為什么不是直接建立在TCP的基礎上進行數據流動呢？

如果建立在TCP的基礎上進行數據流動，建立和關閉TCP連接有代價。頻繁的建立關閉TCP連接對于系統的性能有很大的影響，而且TCP的連接數也有限制，這也限制了系統處理高并發的能力。但是，在TCP連接中建立Channel是沒有上述代價的。