RabbitMQ 基礎(chǔ)知識
當(dāng)前位置:點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
1. 背景RabbitMQ 是一個由 erlang 開發(fā)的AMQP 開源實現(xiàn),erlang語言天生具備高并發(fā)的特性,而且他的管理界面用起來十分方便。 基礎(chǔ)概念 講解基礎(chǔ)概念的前面,我們先來整體構(gòu)造一個結(jié)構(gòu)圖,這樣會方便們更好地去理解RabbitMQ的基本原理。 ![]() 通過上面這張應(yīng)用相結(jié)合的結(jié)構(gòu)圖既能夠清晰的看清楚整體的send Message到Receive Message的一個大致的流程。當(dāng)然上面有很多名詞都相比還沒有介紹到,不要著急接下來我們就開始對其進行詳細(xì)的講解。 2. Queue Queue(隊列)RabbitMQ的作用是存儲消息,隊列的特性是先進先出。上圖可以清晰地看到Client A和Client B是生產(chǎn)者,生產(chǎn)者生產(chǎn)消息最終被送到RabbitMQ的內(nèi)部對象Queue中去,而消費者則是從Queue隊列中取出數(shù)據(jù)。可以簡化成表示為:
生產(chǎn)者Send Message “A”被傳送到Queue中,消費者發(fā)現(xiàn)消息隊列Queue中有訂閱的消息,就會將這條消息A讀取出來進行一系列的業(yè)務(wù)操作。這里只是一個消費正對應(yīng)一個隊列Queue,也可以多個消費者訂閱同一個隊列Queue,當(dāng)然這里就會將Queue里面的消息平分給其他的消費者,但是會存在一個問題就是如果每個消息的處理時間不同,就會導(dǎo)致某些消費者一直在忙碌中,而有的消費者處理完了消息后一直處于空閑狀態(tài),因為前面已經(jīng)提及到了Queue會平分這些消息給相應(yīng)的消費者。這里我們就可以使用prefetchCount來限制每次發(fā)送給消費者消息的個數(shù)。詳情見下圖所示:
這里的prefetchCount=1是指每次從Queue中發(fā)送一條消息來。等消費者處理完這條消息后Queue會再發(fā)送一條消息給消費者。 3. Exchange 我們在開篇的時候就留了一個坑,就是那個應(yīng)用結(jié)構(gòu)圖里面,消費者Client A和消費者Client B是如何知道我發(fā)送的消息是給Queue1還是給Queue2,有沒有想過這個問題,那么我們就來解開這個面紗,看看到底是個什么構(gòu)造。首先明確一點就是生產(chǎn)者產(chǎn)生的消息并不是直接發(fā)送給消息隊列Queue的,而是要經(jīng)過Exchange(交換器),由Exchange再將消息路由到一個或多個Queue,當(dāng)然這里還會對不符合路由規(guī)則的消息進行丟棄掉,這里指的是后續(xù)要談到的Exchange Type。那么Exchange是怎樣將消息準(zhǔn)確的推送到對應(yīng)的Queue的呢?那么這里的功勞最大的當(dāng)屬Binding,RabbitMQ是通過Binding將Exchange和Queue鏈接在一起,這樣Exchange就知道如何將消息準(zhǔn)確的推送到Queue中去。簡單示意圖如下所示: 在綁定(Binding)Exchange和Queue的同時,一般會指定一個Binding Key,生產(chǎn)者將消息發(fā)送給Exchange的時候,一般會產(chǎn)生一個Routing Key,當(dāng)Routing Key和Binding Key對應(yīng)上的時候,消息就會發(fā)送到對應(yīng)的Queue中去。那么Exchange有四種類型,不同的類型有著不同的策略。也就是表明不同的類型將決定綁定的Queue不同,換言之就是說生產(chǎn)者發(fā)送了一個消息,Routing Key的規(guī)則是A,那么生產(chǎn)者會將Routing Key=A的消息推送到Exchange中,這時候Exchange中會有自己的規(guī)則,對應(yīng)的規(guī)則去篩選生產(chǎn)者發(fā)來的消息,如果能夠?qū)?yīng)上Exchange的內(nèi)部規(guī)則就將消息推送到對應(yīng)的Queue中去。那么接下來就來詳細(xì)講解下Exchange里面類型。
4. Exchange Type Exchange分為以下四種: 4.1 fanoutfanout類型的Exchange路由規(guī)則非常簡單,它會把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中。 上圖所示,生產(chǎn)者(P)生產(chǎn)消息1將消息1推送到Exchange,由于Exchange Type=fanout這時候會遵循fanout的規(guī)則將消息推送到所有與它綁定Queue,也就是圖上的兩個Queue最后兩個消費者消費。 4.2 directdirect類型的Exchange路由規(guī)則也很簡單,它會把消息路由到那些binding key與routing key完全匹配的Queue中。 當(dāng)生產(chǎn)者(P)發(fā)送消息時Rotuing key=booking時,這時候?qū)⑾魉徒oExchange,Exchange獲取到生產(chǎn)者發(fā)送過來消息后,會根據(jù)自身的規(guī)則進行與匹配相應(yīng)的Queue,這時發(fā)現(xiàn)Queue1和Queue2都符合,就會將消息傳送給這兩個隊列,如果我們以Rotuing key=create和Rotuing key=confirm發(fā)送消息時,這時消息只會被推送到Queue2隊列中,其他Routing Key的消息將會被丟棄。 4.3 topic前面提到的direct規(guī)則是嚴(yán)格意義上的匹配,換言之Routing Key必須與Binding Key相匹配的時候才將消息傳送給Queue,那么topic這個規(guī)則就是模糊匹配,可以通過通配符滿足一部分規(guī)則就可以傳送。它的約定是:
當(dāng)生產(chǎn)者發(fā)送消息Routing Key=F.C.E的時候,這時候只滿足Queue1,所以會被路由到Queue中,如果Routing Key=A.C.E這時候會被同是路由到Queue1和Queue2中,如果Routing Key=A.F.B時,這里只會發(fā)送一條消息到Queue2中。 4.4 RPC我們的RPC如此工作: 客戶端等待回調(diào)隊列里的數(shù)據(jù)。當(dāng)有消息出現(xiàn)的時候,它會檢查correlation_id屬性。如果此屬性的值與請求匹配,將它返回給應(yīng)用。 5. 補充說明 ConnectionFactory、Connection、Channel:
Channel虛擬連接,建立在上面TCP連接的基礎(chǔ)上,數(shù)據(jù)流動都是通過Channel來進行的。為什么不是直接建立在TCP的基礎(chǔ)上進行數(shù)據(jù)流動呢? 如果建立在TCP的基礎(chǔ)上進行數(shù)據(jù)流動,建立和關(guān)閉TCP連接有代價。頻繁的建立關(guān)閉TCP連接對于系統(tǒng)的性能有很大的影響,而且TCP的連接數(shù)也有限制,這也限制了系統(tǒng)處理高并發(fā)的能力。但是,在TCP連接中建立Channel是沒有上述代價的。 該文章在 2025/3/6 16:59:13 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |