RabbitMQ就是 AMQP 協(xié)議的 Erlang 的實(shí)現(xiàn)(當(dāng)然 RabbitMQ 還支持 STOMP2、 MQTT3 等協(xié)議 ) AMQP 的模型架構(gòu) 和 RabbitMQ 的模型架構(gòu)是一樣的，生產(chǎn)者將消息發(fā)送給交換器，交換器和隊(duì)列綁定 。RabbitMQ 中的交換器、交換器類(lèi)型、隊(duì)列、綁定、路由鍵等都是遵循的 AMQP 協(xié)議中相應(yīng)的概念。
采用AMQP高級(jí)消息隊(duì)列協(xié)議的一種消息隊(duì)列技術(shù),最大的特點(diǎn)就是消費(fèi)并不需要確保提供方存在,實(shí)現(xiàn)了服務(wù)之間的高度解耦。
1.在分布式系統(tǒng)下具備異步,削峰,負(fù)載均衡等一系列高級(jí)功能；
2.擁有持久化的機(jī)制，進(jìn)程消息，隊(duì)列中的信息也可以保存下來(lái)。
3.實(shí)現(xiàn)消費(fèi)者和生產(chǎn)者之間的解耦。
4.對(duì)于高并發(fā)場(chǎng)景下，利用消息隊(duì)列可以使得同步訪問(wèn)變?yōu)榇性L問(wèn)達(dá)到一定量的限，利于數(shù)據(jù)庫(kù)的操作。
5.可以使用消息隊(duì)列達(dá)到異步下單的效果，排隊(duì)中，后臺(tái)進(jìn)行邏輯下單。
1.服務(wù)間異步通信
2.順序消費(fèi)
3.定時(shí)任務(wù)
4.請(qǐng)求削峰
Broker：簡(jiǎn)單來(lái)說(shuō)就是消息隊(duì)列服務(wù)器實(shí)體
Exchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列
Queue：消息隊(duì)列載體，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列
Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來(lái)
Routing Key： 路由關(guān)鍵字，exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞
VHost：vhost可以理解為虛擬broker ，即mini-RabbitMQ server。其內(nèi)部均含有獨(dú)立的queue、exchange和binding等，但最最重要的是，其擁有獨(dú)立的權(quán)限系統(tǒng)，可以做到vhost范圍的用戶控制。當(dāng)然，從RabbitMQ的全局角度，vhost可以作為不同權(quán)限隔離的手段（一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）。
Producer： 消息生產(chǎn)者，就是投遞消息的程序
Consumer：消息消費(fèi)者，就是接受消息的程序
Channel：消息通道，在客戶端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話任務(wù)由Exchange、Queue、RoutingKey三個(gè)才能決定一個(gè)從Exchange到Queue的唯一的線路。
消息的發(fā)送方有個(gè)確認(rèn)模式，具體的流程如下：
1.將信道設(shè)置成confirm模式（發(fā)送方確認(rèn)模式），則所有在信道上發(fā)布的消息都會(huì)被指派一個(gè)唯一的ID。
2.一旦消息被投遞到目的隊(duì)列后，或者消息被寫(xiě)入磁盤(pán)后（可持久化的消息），信道會(huì)發(fā)送一個(gè)確認(rèn)給生產(chǎn)者（包含消息唯一 ID）。
3.如果 RabbitMQ發(fā)生內(nèi)部錯(cuò)誤從而導(dǎo)致消息丟失，會(huì)發(fā)送一條nack（notacknowledged，未確認(rèn)）消息。發(fā)送方確認(rèn)模式是異步的，生產(chǎn)者應(yīng)用程序在等待確認(rèn)的同時(shí)，可以繼續(xù)發(fā)送消息。當(dāng)確認(rèn)消息到達(dá)生產(chǎn)者應(yīng)用程序，生產(chǎn)者應(yīng)用程序的回調(diào)方法就會(huì)被觸發(fā)來(lái)處理確認(rèn)消息。
消息的接收方消息確認(rèn)機(jī)制，具體的流程如下：
消費(fèi)者接收每一條消息后都必須進(jìn)行確認(rèn)（消息接收和消息確認(rèn)是兩個(gè)不同操作）。只有消費(fèi)者確認(rèn)了消息，RabbitMQ才能安全地把消息從隊(duì)列中刪除。這里并沒(méi)有用到超時(shí)機(jī)制，RabbitMQ僅通過(guò)Consumer的連接中斷來(lái)確認(rèn)是否需要重新發(fā)送消息。也就是說(shuō)，只要連接不中斷，RabbitMQ給了Consumer足夠長(zhǎng)的時(shí)間來(lái)處理消息。保證數(shù)據(jù)的最終一致性；
如果消費(fèi)者接收到消息，在確認(rèn)之前斷開(kāi)了連接或取消訂閱，RabbitMQ會(huì)認(rèn)為消息沒(méi)有被分發(fā)，然后重新分發(fā)給下一個(gè)訂閱的消費(fèi)者。
在消息生產(chǎn)時(shí)，RabbitMQ內(nèi)部針對(duì)每條生產(chǎn)者發(fā)送的消息生成一個(gè)inner-msg-id，作為去重的依據(jù)（消息投遞失敗并重傳），避免重復(fù)的消息進(jìn)入隊(duì)列；
在消息消費(fèi)時(shí)，要求消息體中必須要有一個(gè) bizId（對(duì)于同一業(yè)務(wù)全局唯一，如支付ID、訂單ID、帖子ID 等）作為去重的依據(jù)，避免同一條消息被重復(fù)消費(fèi)。
消息不丟失需要堆消息進(jìn)行持久化。
確保持久性消息能從服務(wù)器重啟中恢復(fù)的方式是，將它們寫(xiě)入磁盤(pán)上的一個(gè)持久化日志文件，當(dāng)發(fā)布一條持久性消息到持久交換器上時(shí)，Rabbit會(huì)在消息提交到日志文件后才發(fā)送響應(yīng)。一旦消費(fèi)者從持久隊(duì)列中消費(fèi)了一條持久化消息，RabbitMQ會(huì)在持久化日志中把這條消息標(biāo)記為等待垃圾收集。如果持久化消息在被消費(fèi)之前RabbitMQ重啟，那么Rabbit會(huì)自動(dòng)重建交換器和隊(duì)列（以及綁定），并重新發(fā)布持久化日志文件中的消息到合適的隊(duì)列。
由于TCP連接的創(chuàng)建和銷(xiāo)毀開(kāi)銷(xiāo)較大，且并發(fā)數(shù)受系統(tǒng)資源限制，會(huì)造成性能瓶頸。RabbitMQ使用信道的方式來(lái)傳輸數(shù)據(jù)。信道是建立在真實(shí)的TCP連接內(nèi)的虛擬連接，且每條TCP連接上的信道數(shù)量沒(méi)有限制。
若該隊(duì)列至少有一個(gè)消費(fèi)者訂閱，消息將以循環(huán)（round-robin）的方式發(fā)送給消費(fèi)者。每條消息只會(huì)分發(fā)給一個(gè)訂閱的消費(fèi)者（前提是消費(fèi)者能夠正常處理消息并進(jìn)行確認(rèn)）。
主要有3種：
1.fanout：如果交換器收到消息，將會(huì)廣播到所有綁定的隊(duì)列上
2.direct：如果路由鍵完全匹配，消息就被投遞到相應(yīng)的隊(duì)列
3.topic：可以使來(lái)自不同源頭的消息能夠到達(dá)同一個(gè)隊(duì)列。 使用topic交換器時(shí)，可以使用通配符
1.簡(jiǎn)單模式，用的默認(rèn)交換機(jī)，1個(gè)生產(chǎn)者，1個(gè)消費(fèi)者，一個(gè)消息只能被一個(gè)消費(fèi)者消息
2.工作模，多個(gè)消費(fèi)者監(jiān)聽(tīng)同一個(gè)隊(duì)列，如果任務(wù)數(shù)據(jù)比較多，可以多幾個(gè)消費(fèi)者，可以加快消費(fèi)的速度
3.訂閱發(fā)布模式，引入了交換機(jī)的類(lèi)型fanout，廣播模式 ，每個(gè)消費(fèi)者單獨(dú)監(jiān)聽(tīng)自己的對(duì)列都可以取消費(fèi)自己隊(duì)列的消息。
4.routing，是direct的的交換機(jī)類(lèi)型，指定路由
5.topic,是topic的交換機(jī)類(lèi)型，比路由多了通配符的更加的靈活
完成RabbitMQ消息路由的核心組件是 Exchange。而消息的路由是由Exchange類(lèi)型 和 Binding 來(lái)決定的。Binding 表示建立 Queue 和 Exchange 之間的綁定關(guān)系，每一個(gè)綁定關(guān)系會(huì)存在一個(gè) BindingKey。通過(guò)這種方式相當(dāng)于在 Exchange 中建立了一個(gè)路由關(guān)系表。生產(chǎn)者發(fā)送消息的時(shí)候，需要聲明一個(gè) RoutingKey（路由鍵），Exchange 拿到RoutingKey 之后，根據(jù) RoutingKey 和路由表里面的 BindingKey 進(jìn)行匹配，而匹配的規(guī)則是通過(guò) Exchange類(lèi)型來(lái)決定的。在 RabbitMQ 中，默認(rèn)有四種類(lèi)型的 Exchange：Direct ，F(xiàn)anout、Topic和Header。
Direct，叫直連，也就是完整匹配方式，需要Routing Key 和 Binding Key 完全一致，相當(dāng)于點(diǎn)對(duì)點(diǎn)的發(fā)送。
Topic： 叫主題，這種方式是通過(guò)設(shè)置通配符來(lái)動(dòng)態(tài)匹配，相當(dāng)于正則。就是用Routing Key 去匹配Binging Key。BingingKey支持兩個(gè)通配符。
Fanout：叫廣播，這種方式不需要設(shè)置Routing Key，而是把消息廣播給綁定到當(dāng)前 Exchange 上的所有隊(duì)列上。
1)拆分多個(gè)queue(消息隊(duì)列)，每個(gè)queue(消息隊(duì)列) 一個(gè)consumer(消費(fèi)者)，就是多一些queue(消息隊(duì)列)而已，這種方式會(huì)比較麻煩；
2)一個(gè)queue (消息隊(duì)列)但是對(duì)應(yīng)一個(gè)consumer(消費(fèi)者)，然后這個(gè)consumer(消費(fèi)者)內(nèi)部用內(nèi)存隊(duì)列做排隊(duì)，然后分發(fā)給底層不同的worker來(lái)處理。
首先，必然導(dǎo)致性能的下降，因?yàn)閷?xiě)磁盤(pán)比寫(xiě)RAM慢的多，message的吞吐量可能有10倍的差距。
其次，message的持久化機(jī)制用在RabbitMQ的內(nèi)置cluster方案時(shí)會(huì)出現(xiàn)“坑爹”問(wèn)題。矛盾點(diǎn)在于，若message設(shè)置了persistent屬性，但queue未設(shè)置durable屬性，那么當(dāng)該queue的owner node出現(xiàn)異常后，在未重建該queue前，發(fā)往該queue 的message將被 blackholed；若 message 設(shè)置了 persistent屬性，同時(shí)queue也設(shè)置了durable屬性，那么當(dāng)queue的owner node異常且無(wú)法重啟的情況下，則該queue無(wú)法在其他node上重建，只能等待其owner node重啟后，才能恢復(fù)該 queue的使用，而在這段時(shí)間內(nèi)發(fā)送給該queue的message將被 blackholed 。
所以，是否要對(duì)message進(jìn)行持久化，需要綜合考慮性能需要，以及可能遇到的問(wèn)題。若想達(dá)到100,000 條/秒以上的消息吞吐量（單RabbitMQ服務(wù)器），則要么使用其他的方式來(lái)確保message的可靠delivery ，要么使用非常快速的存儲(chǔ)系統(tǒng)以支持全持久化（例如使用SSD）。
另外一種處理原則是：僅對(duì)關(guān)鍵消息作持久化處理（根據(jù)業(yè)務(wù)重要程度），且應(yīng)該保證關(guān)鍵消息的量不會(huì)導(dǎo)致性能瓶頸。
RabbitMQ有三種模式：?jiǎn)螜C(jī)模式、普通集群模式、鏡像集群模式。
單機(jī)模式就是Demo級(jí)別的，一般就是你本地啟動(dòng)了玩玩兒的?，沒(méi)人生產(chǎn)用單機(jī)模式
普通集群模式就是在多臺(tái)機(jī)器上啟動(dòng)多個(gè)RabbitMQ實(shí)例，每個(gè)機(jī)器啟動(dòng)一個(gè)。你創(chuàng)建的queue，只會(huì)放在一個(gè)RabbitMQ實(shí)例上，但是每個(gè)實(shí)例都同步queue的元數(shù)據(jù)。你消費(fèi)的時(shí)候，實(shí)際上如果連接到了另外一個(gè)實(shí)例，那么那個(gè)實(shí)例會(huì)從queue所在實(shí)例上拉取數(shù)據(jù)過(guò)來(lái)。這方案主要是提高吞吐量的，就是說(shuō)讓集群中多個(gè)節(jié)點(diǎn)來(lái)服務(wù)某個(gè)queue的讀寫(xiě)操作。
鏡像集群模式才是所謂的RabbitMQ的高可用模式。這種模式下，每個(gè)RabbitMQ節(jié)點(diǎn)都有這個(gè)queue的一個(gè)完整鏡像，包含queue的全部數(shù)據(jù)的意思。然后每次你寫(xiě)消息到queue的時(shí)候，都會(huì)自動(dòng)把消息同步到多個(gè)實(shí)例的queue上。RabbitMQ有很好的管理控制臺(tái)，就是在后臺(tái)新增一個(gè)策略，這個(gè)策略是鏡像集群模式的策略，指定的時(shí)候是可以要求數(shù)據(jù)同步到所有節(jié)點(diǎn)的，也可以要求同步到指定數(shù)量的節(jié)點(diǎn)，再次創(chuàng)建queue的時(shí)候，應(yīng)用這個(gè)策略，就會(huì)自動(dòng)將數(shù)據(jù)同步到其他的節(jié)點(diǎn)上去了。這樣的好處在于，你任何一個(gè)機(jī)器宕機(jī)了，沒(méi)事兒，其它機(jī)器（節(jié)點(diǎn)）還包含了這個(gè)queue的完整數(shù)據(jù)，別的consumer都可以到其它節(jié)點(diǎn)上去消費(fèi)數(shù)據(jù)。壞處在于，第一，這個(gè)性能開(kāi)銷(xiāo)也太大了吧，消息需要同步到所有機(jī)器上，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！RabbitMQ一個(gè)queue的數(shù)據(jù)都是放在一個(gè)節(jié)點(diǎn)里的，鏡像集群下，也是每個(gè)節(jié)點(diǎn)都放這個(gè)queue的完整數(shù)據(jù)。
京公網(wǎng)安備 11030102010736號(hào)