RabbitMQ消息隊(duì)列有什么用

這篇文章主要介紹了RabbitMQ消息隊(duì)列有什么用，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

目前創(chuàng)新互聯(lián)已為上1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、雅安服務(wù)器托管、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、蕭縣網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

1. 歷史

    RabbitMQ是一個(gè)由erlang開發(fā)的AMQP（Advanced Message Queue ）的開源實(shí)現(xiàn)。AMQP 的出現(xiàn)其實(shí)也是應(yīng)了廣大人民群眾的需求，雖然在同步消息通訊的世界里有很多公開標(biāo)準(zhǔn)（如 COBAR的 IIOP ，或者是 SOAP 等），但是在異步消息處理中卻不是這樣，只有大企業(yè)有一些商業(yè)實(shí)現(xiàn)（如微軟的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等聯(lián)合制定了 AMQP 的公開標(biāo)準(zhǔn)。

    RabbitMQ是由RabbitMQ  Technologies Ltd開發(fā)并且提供商業(yè)支持的。該公司在2010年4月被SpringSource（VMWare的一個(gè)部門）收購(gòu)。在2013年5月被并入Pivotal。其實(shí)VMWare，Pivotal和EMC本質(zhì)上是一家的。不同的是VMWare是獨(dú)立上市子公司，而Pivotal是整合了EMC的某些資源，現(xiàn)在并沒(méi)有上市。

2. 應(yīng)用場(chǎng)景  

     言歸正傳。RabbitMQ，或者說(shuō)AMQP解決了什么問(wèn)題，或者說(shuō)它的應(yīng)用場(chǎng)景是什么？

     對(duì)于一個(gè)大型的軟件系統(tǒng)來(lái)說(shuō)，它會(huì)有很多的組件或者說(shuō)模塊或者說(shuō)子系統(tǒng)或者（subsystem or Component or submodule）。那么這些模塊的如何通信？這和傳統(tǒng)的IPC有很大的區(qū)別。傳統(tǒng)的IPC很多都是在單一系統(tǒng)上的，模塊耦合性很大，不適合擴(kuò)展（Scalability）；如果使用socket那么不同的模塊的確可以部署到不同的機(jī)器上，但是還是有很多問(wèn)題需要解決。比如：

 1）信息的發(fā)送者和接收者如何維持這個(gè)連接，如果一方的連接中斷，這期間的數(shù)據(jù)如何方式丟失？

 2）如何降低發(fā)送者和接收者的耦合度？

 3）如何讓Priority高的接收者先接到數(shù)據(jù)？

 4）如何做到load balance？有效均衡接收者的負(fù)載？

 5）如何有效的將數(shù)據(jù)發(fā)送到相關(guān)的接收者？也就是說(shuō)將接收者subscribe 不同的數(shù)據(jù)，如何做有效的filter。

 6）如何做到可擴(kuò)展，甚至將這個(gè)通信模塊發(fā)到cluster上？

 7）如何保證接收者接收到了完整，正確的數(shù)據(jù)？

  AMDQ協(xié)議解決了以上的問(wèn)題，而RabbitMQ實(shí)現(xiàn)了AMQP。

3. 系統(tǒng)架構(gòu)

      成為系統(tǒng)架構(gòu)可能不太合適，可能叫應(yīng)用場(chǎng)景的系統(tǒng)架構(gòu)更合適。

 

    這個(gè)系統(tǒng)架構(gòu)圖版權(quán)屬于sunjun041640。

    RabbitMQ Server： 也叫broker server，它不是運(yùn)送食物的卡車，而是一種傳輸服務(wù)。原話是RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是維護(hù)一條從Producer到Consumer的路線，保證數(shù)據(jù)能夠按照指定的方式進(jìn)行傳輸。但是這個(gè)保證也不是100%的保證，但是對(duì)于普通的應(yīng)用來(lái)說(shuō)這已經(jīng)足夠了。當(dāng)然對(duì)于商業(yè)系統(tǒng)來(lái)說(shuō)，可以再做一層數(shù)據(jù)一致性的guard，就可以徹底保證系統(tǒng)的一致性了。

    Client A & B： 也叫Producer，數(shù)據(jù)的發(fā)送方。createmessages and publish (send) them to a broker server (RabbitMQ).一個(gè)Message有兩個(gè)部分：payload（有效載荷）和label（標(biāo)簽）。payload顧名思義就是傳輸?shù)臄?shù)據(jù)。label是exchange的名字或者說(shuō)是一個(gè)tag，它描述了payload，而且RabbitMQ也是通過(guò)這個(gè)label來(lái)決定把這個(gè)Message發(fā)給哪個(gè)Consumer。AMQP僅僅描述了label，而RabbitMQ決定了如何使用這個(gè)label的規(guī)則。

    Client 1，2，3：也叫Consumer，數(shù)據(jù)的接收方。Consumersattach to a broker server (RabbitMQ) and subscribe to a queue。把queue比作是一個(gè)有名字的郵箱。當(dāng)有Message到達(dá)某個(gè)郵箱后，RabbitMQ把它發(fā)送給它的某個(gè)訂閱者即Consumer。當(dāng)然可能會(huì)把同一個(gè)Message發(fā)送給很多的Consumer。在這個(gè)Message中，只有payload，label已經(jīng)被刪掉了。對(duì)于Consumer來(lái)說(shuō)，它是不知道誰(shuí)發(fā)送的這個(gè)信息的。就是協(xié)議本身不支持。但是當(dāng)然了如果Producer發(fā)送的payload包含了Producer的信息就另當(dāng)別論了。

     對(duì)于一個(gè)數(shù)據(jù)從Producer到Consumer的正確傳遞，還有三個(gè)概念需要明確：exchanges, queues and bindings。

        Exchangesare where producers publish their messages.

        Queuesare where the messages end up and are received by consumers

        Bindingsare how the messages get routed from the exchange to particular queues.

   還有幾個(gè)概念是上述圖中沒(méi)有標(biāo)明的，那就是Connection（連接），Channel（通道，頻道）。

   Connection： 就是一個(gè)TCP的連接。Producer和Consumer都是通過(guò)TCP連接到RabbitMQ Server的。以后我們可以看到，程序的起始處就是建立這個(gè)TCP連接。

   Channels：虛擬連接。它建立在上述的TCP連接中。數(shù)據(jù)流動(dòng)都是在Channel中進(jìn)行的。也就是說(shuō)，一般情況是程序起始建立TCP連接，第二步就是建立這個(gè)Channel。

    那么，為什么使用Channel，而不是直接使用TCP連接？

    對(duì)于OS來(lái)說(shuō)，建立和關(guān)閉TCP連接是有代價(jià)的，頻繁的建立關(guān)閉TCP連接對(duì)于系統(tǒng)的性能有很大的影響，而且TCP的連接數(shù)也有限制，這也限制了系統(tǒng)處理高并發(fā)的能力。但是，在TCP連接中建立Channel是沒(méi)有上述代價(jià)的。對(duì)于Producer或者Consumer來(lái)說(shuō)，可以并發(fā)的使用多個(gè)Channel進(jìn)行Publish或者Receive。有實(shí)驗(yàn)表明，1s的數(shù)據(jù)可以Publish20K的數(shù)據(jù)包。當(dāng)然對(duì)于不同的硬件環(huán)境，不同的數(shù)據(jù)包大小這個(gè)數(shù)據(jù)肯定不一樣，但是我只想說(shuō)明，對(duì)于普通的Consumer或者Producer來(lái)說(shuō)，這已經(jīng)足夠了。如果不夠用，你考慮的應(yīng)該是如何細(xì)化split你的設(shè)計(jì)。

4. 進(jìn)一步的細(xì)節(jié)闡明

4.1 使用ack確認(rèn)Message的正確傳遞

   默認(rèn)情況下，如果Message 已經(jīng)被某個(gè)Consumer正確的接收到了，那么該Message就會(huì)被從queue中移除。當(dāng)然也可以讓同一個(gè)Message發(fā)送到很多的Consumer。

    如果一個(gè)queue沒(méi)被任何的Consumer Subscribe（訂閱），那么，如果這個(gè)queue有數(shù)據(jù)到達(dá)，那么這個(gè)數(shù)據(jù)會(huì)被cache，不會(huì)被丟棄。當(dāng)有Consumer時(shí)，這個(gè)數(shù)據(jù)會(huì)被立即發(fā)送到這個(gè)Consumer，這個(gè)數(shù)據(jù)被Consumer正確收到時(shí)，這個(gè)數(shù)據(jù)就被從queue中刪除。

     那么什么是正確收到呢？通過(guò)ack。每個(gè)Message都要被acknowledged（確認(rèn)，ack）。我們可以顯示的在程序中去ack，也可以自動(dòng)的ack。如果有數(shù)據(jù)沒(méi)有被ack，那么：

     RabbitMQ Server會(huì)把這個(gè)信息發(fā)送到下一個(gè)Consumer。

    如果這個(gè)app有bug，忘記了ack，那么RabbitMQ Server不會(huì)再發(fā)送數(shù)據(jù)給它，因?yàn)镾erver認(rèn)為這個(gè)Consumer處理能力有限。

   而且ack的機(jī)制可以起到限流的作用（Benefitto throttling）：在Consumer處理完成數(shù)據(jù)后發(fā)送ack，甚至在額外的延時(shí)后發(fā)送ack，將有效的balance Consumer的load。

   當(dāng)然對(duì)于實(shí)際的例子，比如我們可能會(huì)對(duì)某些數(shù)據(jù)進(jìn)行merge，比如merge 4s內(nèi)的數(shù)據(jù)，然后sleep 4s后再獲取數(shù)據(jù)。特別是在監(jiān)聽系統(tǒng)的state，我們不希望所有的state實(shí)時(shí)的傳遞上去，而是希望有一定的延時(shí)。這樣可以減少某些IO，而且終端用戶也不會(huì)感覺(jué)到。

4.2 Reject a message

   有兩種方式，第一種的Reject可以讓RabbitMQ Server將該Message 發(fā)送到下一個(gè)Consumer。第二種是從queue中立即刪除該Message。

4.3  Creating a queue

     Consumer和Procuder都可以通過(guò) queue.declare創(chuàng)建queue。對(duì)于某個(gè)Channel來(lái)說(shuō)，Consumer不能declare一個(gè)queue，卻訂閱其他的queue。當(dāng)然也可以創(chuàng)建私有的queue。這樣只有app本身才可以使用這個(gè)queue。queue也可以自動(dòng)刪除，被標(biāo)為auto-delete的queue在最后一個(gè)Consumer unsubscribe后就會(huì)被自動(dòng)刪除。那么如果是創(chuàng)建一個(gè)已經(jīng)存在的queue呢？那么不會(huì)有任何的影響。需要注意的是沒(méi)有任何的影響，也就是說(shuō)第二次創(chuàng)建如果參數(shù)和第一次不一樣，那么該操作雖然成功，但是queue的屬性并不會(huì)被修改。

    那么誰(shuí)應(yīng)該負(fù)責(zé)創(chuàng)建這個(gè)queue呢？是Consumer，還是Producer？

如果queue不存在，當(dāng)然Consumer不會(huì)得到任何的Message。但是如果queue不存在，那么Producer Publish的Message會(huì)被丟棄。所以，還是為了數(shù)據(jù)不丟失，Consumer和Producer都try to create the queue！反正不管怎么樣，這個(gè)接口都不會(huì)出問(wèn)題。

   queue對(duì)load balance的處理是完美的。對(duì)于多個(gè)Consumer來(lái)說(shuō)，RabbitMQ 使用循環(huán)的方式（round-robin）的方式均衡的發(fā)送給不同的Consumer。

4.4 Exchanges  

    從架構(gòu)圖可以看出，Procuder Publish的Message進(jìn)入了Exchange。接著通過(guò)“routing keys”， RabbitMQ會(huì)找到應(yīng)該把這個(gè)Message放到哪個(gè)queue里。queue也是通過(guò)這個(gè)routing keys來(lái)做的綁定。

     有三種類型的Exchanges：direct, fanout,topic。 每個(gè)實(shí)現(xiàn)了不同的路由算法（routing algorithm）。

·        Direct exchange: 如果 routing key 匹配, 那么Message就會(huì)被傳遞到相應(yīng)的queue中。其實(shí)在queue創(chuàng)建時(shí)，它會(huì)自動(dòng)的以queue的名字作為routing key來(lái)綁定那個(gè)exchange。

·        Fanout exchange: 會(huì)向響應(yīng)的queue廣播。

·        Topic exchange: 對(duì)key進(jìn)行模式匹配，比如ab*可以傳遞到所有ab*的queue。

4.5 Virtual hosts

   每個(gè)virtual host本質(zhì)上都是一個(gè)RabbitMQ Server，擁有它自己的queue，exchagne，和bings rule等等。這保證了你可以在多個(gè)不同的application中使用RabbitMQ。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“RabbitMQ消息隊(duì)列有什么用”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!

分享題目：RabbitMQ消息隊(duì)列有什么用
路徑分享：http://muchs.cn/article44/ipgdhe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、App開發(fā)、網(wǎng)頁(yè)設(shè)計(jì)公司、靜態(tài)網(wǎng)站、軟件開發(fā)、網(wǎng)站營(yíng)銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)