前言：
`MQ` 是什么？隊列是什么蛮瞄，`MQ` 我們可以理解為消息隊列所坯，隊列我們可以理解為管道。以管道的方式做消息傳遞挂捅。
場景：
1.其實我們在雙11的時候芹助，當(dāng)我們凌晨大量的秒殺和搶購商品，然后去結(jié)算的時候闲先，就會發(fā)現(xiàn)状土，界面會提醒我們，讓我們稍等伺糠，以及一些友好的圖片文字提醒蒙谓。而不是像前幾年的時代，動不動就頁面卡死训桶，報錯等來呈現(xiàn)給用戶累驮。
在這業(yè)務(wù)場景中，我們就可以采用隊列的機(jī)制來處理渊迁，因為同時結(jié)算就只能達(dá)到這么多慰照。
2.在我們平時的超市中購物也是一樣，當(dāng)我們在結(jié)算的時候琉朽，并不會一窩蜂一樣涌入收銀臺毒租，而是排隊結(jié)算。這也是隊列機(jī)制箱叁。
對墅垮，就是排隊。一個接著一個的處理耕漱，不能插隊算色。
RabbitMQ簡介
AMQP，即Advanced Message Queuing Protocol螟够，高級消息隊列協(xié)議灾梦，是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn)峡钓，為面向消息的中間件設(shè)計。消息中間件主要用于組件之間的解耦若河，消息的發(fā)送者無需知道消息使用者的存在能岩，反之亦然。 AMQP的主要特征是面向消息萧福、隊列拉鹃、路由（包括點對點和發(fā)布/訂閱）、可靠性鲫忍、安全膏燕。 RabbitMQ是一個開源的AMQP實現(xiàn)，服務(wù)器端用Erlang語言編寫悟民，支持多種客戶端坝辫，如：Python、Ruby逾雄、.NET阀溶、Java、JMS鸦泳、C、PHP永品、ActionScript做鹰、XMPP、STOMP等鼎姐，支持AJAX钾麸。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，在易用性炕桨、擴(kuò)展性饭尝、高可用性等方面表現(xiàn)不俗。 下面將重點介紹RabbitMQ中的一些基礎(chǔ)概念献宫，了解了這些概念钥平，是使用好RabbitMQ的基礎(chǔ)。
ConnectionFactory姊途、Connection涉瘾、Channel
ConnectionFactory、Connection捷兰、Channel都是RabbitMQ對外提供的API中最基本的對象立叛。Connection是RabbitMQ的socket鏈接，它封裝了socket協(xié)議相關(guān)部分邏輯贡茅。ConnectionFactory為Connection的制造工廠秘蛇。 Channel是我們與RabbitMQ打交道的最重要的一個接口其做，我們大部分的業(yè)務(wù)操作是在Channel這個接口中完成的，包括定義Queue赁还、定義Exchange妖泄、綁定Queue與Exchange、發(fā)布消息等秽浇。
Queue
Queue（隊列）是RabbitMQ的內(nèi)部對象浮庐，用于存儲消息，用下圖表示柬焕。
RabbitMQ中的消息都只能存儲在Queue中审残，生產(chǎn)者（下圖中的P）生產(chǎn)消息并最終投遞到Queue中，消費者（下圖中的C）可以從Queue中獲取消息并消費斑举。
多個消費者可以訂閱同一個Queue搅轿，這時Queue中的消息會被平均分?jǐn)偨o多個消費者進(jìn)行處理，而不是每個消費者都收到所有的消息并處理富玷。
Message acknowledgment
在實際應(yīng)用中璧坟，可能會發(fā)生消費者收到Queue中的消息，但沒有處理完成就宕機(jī)（或出現(xiàn)其他意外）的情況赎懦，這種情況下就可能會導(dǎo)致消息丟失雀鹃。為了避免這種情況發(fā)生，我們可以要求消費者在消費完消息后發(fā)送一個回執(zhí)給RabbitMQ励两，RabbitMQ收到消息回執(zhí)（Message acknowledgment）后才將該消息從Queue中移除黎茎；如果RabbitMQ沒有收到回執(zhí)并檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發(fā)送給其他消費者（如果存在多個消費者）進(jìn)行處理当悔。這里不存在timeout概念傅瞻，一個消費者處理消息時間再長也不會導(dǎo)致該消息被發(fā)送給其他消費者，除非它的RabbitMQ連接斷開盲憎。 這里會產(chǎn)生另外一個問題嗅骄，如果我們的開發(fā)人員在處理完業(yè)務(wù)邏輯后，忘記發(fā)送回執(zhí)給RabbitMQ饼疙，這將會導(dǎo)致嚴(yán)重的bug——Queue中堆積的消息會越來越多溺森；消費者重啟后會重復(fù)消費這些消息并重復(fù)執(zhí)行業(yè)務(wù)邏輯…
另外pub message是沒有ack的。
Message durability
如果我們希望即使在RabbitMQ服務(wù)重啟的情況下宏多，也不會丟失消息儿惫，我們可以將Queue與Message都設(shè)置為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失伸但。但依然解決不了小概率丟失事件的發(fā)生（比如RabbitMQ服務(wù)器已經(jīng)接收到生產(chǎn)者的消息肾请，但還沒來得及持久化該消息時RabbitMQ服務(wù)器就斷電了），如果我們需要對這種小概率事件也要管理起來更胖，那么我們要用到事務(wù)铛铁。由于這里僅為RabbitMQ的簡單介紹隔显，所以這里將不講解RabbitMQ相關(guān)的事務(wù)。
Prefetch count
前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息饵逐，Queue中的消息會被平攤給多個消費者括眠。這時如果每個消息的處理時間不同，就有可能會導(dǎo)致某些消費者一直在忙倍权，而另外一些消費者很快就處理完手頭工作并一直空閑的情況掷豺。我們可以通過設(shè)置prefetchCount來限制Queue每次發(fā)送給每個消費者的消息數(shù)，比如我們設(shè)置prefetchCount=1薄声，則Queue每次給每個消費者發(fā)送一條消息当船；消費者處理完這條消息后Queue會再給該消費者發(fā)送一條消息。
Exchange
在上一節(jié)我們看到生產(chǎn)者將消息投遞到Queue中默辨，實際上這在RabbitMQ中這種事情永遠(yuǎn)都不會發(fā)生德频。實際的情況是，生產(chǎn)者將消息發(fā)送到Exchange（交換器缩幸，下圖中的X）壹置，由Exchange將消息路由到一個或多個Queue中（或者丟棄）。
Exchange是按照什么邏輯將消息路由到Queue的表谊？這個將在Binding一節(jié)介紹钞护。 RabbitMQ中的Exchange有四種類型，不同的類型有著不同的路由策略爆办，這將在Exchange Types一節(jié)介紹患亿。
routing key
生產(chǎn)者在將消息發(fā)送給Exchange的時候，一般會指定一個routing key押逼，來指定這個消息的路由規(guī)則，而這個routing key需要與Exchange Type及binding key聯(lián)合使用才能最終生效惦界。 在Exchange Type與binding key固定的情況下（在正常使用時一般這些內(nèi)容都是固定配置好的）挑格，我們的生產(chǎn)者就可以在發(fā)送消息給Exchange時，通過指定routing key來決定消息流向哪里沾歪。 RabbitMQ為routing key設(shè)定的長度限制為255 bytes。
Binding
RabbitMQ中通過Binding將Exchange與Queue關(guān)聯(lián)起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了赢底。
Binding key
在綁定（Binding）Exchange與Queue的同時殴蓬，一般會指定一個binding key；消費者將消息發(fā)送給Exchange時狂窑，一般會指定一個routing key媳板；當(dāng)binding key與routing key相匹配時，消息將會被路由到對應(yīng)的Queue中泉哈。這個將在Exchange Types章節(jié)會列舉實際的例子加以說明蛉幸。 在綁定多個Queue到同一個Exchange的時候破讨，這些Binding允許使用相同的binding key。 binding key 并不是在所有情況下都生效奕纫，它依賴于Exchange Type提陶，比如fanout類型的Exchange就會無視binding key，而是將消息路由到所有綁定到該Exchange的Queue匹层。
Exchange Types
RabbitMQ常用的Exchange Type有fanout隙笆、direct、topic升筏、headers這四種（AMQP規(guī)范里還提到兩種Exchange Type撑柔，分別為system與自定義，這里不予以描述）仰冠，下面分別進(jìn)行介紹乏冀。
fanout
fanout類型的Exchange路由規(guī)則非常簡單，它會把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中洋只。
上圖中辆沦，生產(chǎn)者（P）發(fā)送到Exchange（X）的所有消息都會路由到圖中的兩個Queue，并最終被兩個消費者（C1與C2）消費识虚。
direct
direct類型的Exchange路由規(guī)則也很簡單肢扯，它會把消息路由到那些binding key與routing key完全匹配的Queue中。
以上圖的配置為例担锤，我們以routingKey=”error”發(fā)送消息到Exchange蔚晨，則消息會路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱）和Queue2（amqp.gen-Agl…）肛循；如果我們以routingKey=”info”或routingKey=”warning”來發(fā)送消息铭腕，則消息只會路由到Queue2。如果我們以其他routingKey發(fā)送消息多糠，則消息不會路由到這兩個Queue中累舷。
topic
前面講到direct類型的Exchange路由規(guī)則是完全匹配binding key與routing key，但這種嚴(yán)格的匹配方式在很多情況下不能滿足實際業(yè)務(wù)需求夹孔。topic類型的Exchange在匹配規(guī)則上進(jìn)行了擴(kuò)展被盈，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中搭伤，但這里的匹配規(guī)則有些不同只怎，它約定：
- routing key為一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱為一個單詞），如“stock.usd.nyse”怜俐、“nyse.vmw”身堡、“quick.orange.rabbit”
- binding key與routing key一樣也是句點號“. ”分隔的字符串
- binding key中可以存在兩種特殊字符“”與“#”，用于做模糊匹配佑菩，其中“”用于匹配一個單詞盾沫，“#”用于匹配多個單詞（可以是零個）
以上圖中的配置為例裁赠，routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會路由到Q1與Q2赴精，routingKey=”lazy.brown.fox”的消息會路由到Q2佩捞，routingKey=”lazy.pink.rabbit”的消息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）蕾哟；routingKey=”quick.brown.fox”一忱、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄谭确，因為它們沒有匹配任何bindingKey帘营。
headers
headers類型的Exchange不依賴于routing key與binding key的匹配規(guī)則來路由消息，而是根據(jù)發(fā)送的消息內(nèi)容中的headers屬性進(jìn)行匹配逐哈。 在綁定Queue與Exchange時指定一組鍵值對芬迄；當(dāng)消息發(fā)送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式）昂秃，對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對禀梳；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue肠骆。 該類型的Exchange沒有用到過（不過也應(yīng)該很有用武之地）算途，所以不做介紹。
RPC
MQ本身是基于異步的消息處理蚀腿，前面的示例中所有的生產(chǎn)者（P）將消息發(fā)送到RabbitMQ后不會知道消費者（C）處理成功或者失斪烊俊（甚至連有沒有消費者來處理這條消息都不知道）。 但實際的應(yīng)用場景中莉钙，我們很可能需要一些同步處理廓脆，需要同步等待服務(wù)端將我的消息處理完成后再進(jìn)行下一步處理。這相當(dāng)于RPC（Remote Procedure Call磁玉，遠(yuǎn)程過程調(diào)用）狞贱。在RabbitMQ中也支持RPC。
RabbitMQ 中實現(xiàn)RPC 的機(jī)制是：
- 客戶端發(fā)送請求（消息）時蜀涨，在消息的屬性（
MessageProperties，在AMQP協(xié)議中定義了14中properties蝎毡，這些屬性會隨著消息一起發(fā)送）中設(shè)置兩個值replyTo（一個Queue名稱厚柳，用于告訴服務(wù)器處理完成后將通知我的消息發(fā)送到這個Queue中）和correlationId（此次請求的標(biāo)識號，服務(wù)器處理完成后需要將此屬性返還沐兵，客戶端將根據(jù)這個id了解哪條請求被成功執(zhí)行了或執(zhí)行失敱鹂濉） - 服務(wù)器端收到消息并處理
- 服務(wù)器端處理完消息后，將生成一條應(yīng)答消息到
replyTo指定的Queue扎谎，同時帶上correlationId屬性 - 客戶端之前已訂閱
replyTo指定的Queue碳想，從中收到服務(wù)器的應(yīng)答消息后烧董，根據(jù)其中的correlationId屬性分析哪條請求被執(zhí)行了，根據(jù)執(zhí)行結(jié)果進(jìn)行后續(xù)業(yè)務(wù)處理
總結(jié)
本文介紹了RabbitMQ 中個人認(rèn)為最重要的概念胧奔，充分利用RabbitMQ 提供的這些功能就可以處理我們絕大部分的異步業(yè)務(wù)了逊移。
RabbitMQ 選型和對比
1.從社區(qū)活躍度
按照目前網(wǎng)絡(luò)上的資料，RabbitMQ 龙填、activeM 胳泉、ZeroMQ 三者中，綜合來看岩遗，RabbitMQ 是首選扇商。
2.持久化消息比較
ZeroMq 不支持，ActiveMq 和RabbitMq 都支持宿礁。持久化消息主要是指我們機(jī)器在不可抗力因素等情況下掛掉了案铺，消息不會丟失的機(jī)制。
3.綜合技術(shù)實現(xiàn)
可靠性梆靖、靈活的路由控汉、集群、事務(wù)涤姊、高可用的隊列暇番、消息排序、問題追蹤思喊、可視化管理工具壁酬、插件系統(tǒng)等等。
RabbitMq / Kafka 最好恨课，ActiveMq 次之舆乔，ZeroMq 最差。當(dāng)然ZeroMq 也可以做到剂公，不過自己必須手動寫代碼實現(xiàn)希俩，代碼量不小。尤其是可靠性中的：持久性纲辽、投遞確認(rèn)颜武、發(fā)布者證實和高可用性。
4.高并發(fā)
毋庸置疑拖吼，RabbitMQ 最高鳞上，原因是它的實現(xiàn)語言是天生具備高并發(fā)高可用的erlang 語言。
5.比較關(guān)注的比較吊档， RabbitMQ 和 Kafka
RabbitMq 比Kafka 成熟篙议，在可用性上，穩(wěn)定性上，可靠性上鬼贱， RabbitMq 勝于 Kafka （理論上）移怯。
另外，Kafka 的定位主要在日志等方面这难， 因為Kafka 設(shè)計的初衷就是處理日志的舟误，可以看做是一個日志（消息）系統(tǒng)一個重要組件，針對性很強(qiáng)雁佳，所以 如果業(yè)務(wù)方面還是建議選擇 RabbitMq 脐帝。
還有就是，Kafka 的性能（吞吐量糖权、TPS ）比RabbitMq 要高出來很多堵腹。
選型最后總結(jié)：
如果我們系統(tǒng)中已經(jīng)有選擇 Kafka ，或者 RabbitMq 星澳，并且完全可以滿足現(xiàn)在的業(yè)務(wù)疚顷，建議就不用重復(fù)去增加和造輪子。
可以在 Kafka 和 RabbitMq 中選擇一個適合自己團(tuán)隊和業(yè)務(wù)的禁偎，這個才是最重要的腿堤。但是毋庸置疑現(xiàn)階段，綜合考慮沒有第三選擇如暖。
版權(quán)所屬：SO JSON在線解析
原文地址：https://www.sojson.com/blog/48.html
轉(zhuǎn)載時必須以鏈接形式注明原始出處及本聲明笆檀。
