1. RabbitMQ 的相關(guān)概念

2007 年發(fā)布，是一個在 AMQP(高級消息隊列協(xié)議)基礎(chǔ)上完成的，可復(fù)用的企業(yè)消息系統(tǒng)，是當(dāng)前最主流的消息中間件之一。
.
RabbitMQ是一個由erlang開發(fā)的AMQP（Advanced Message Queue 高級消息隊列協(xié)議 ）的開源實現(xiàn)，由于erlang 語言的高并發(fā)特性，性能較好，本質(zhì)是個隊列，FIFO 先入先出，里面存放的內(nèi)容是message
.
RabbitMQ 是一個消息中間件：它接收消息并且轉(zhuǎn)發(fā)，就類似于一個快遞站，賣家把快遞通過快遞站，送到我們的手上，MQ也是這樣，接收并存儲消息，再轉(zhuǎn)發(fā)。

2. 為什么要用 MQ

流量消峰

舉個例子，如果訂單系統(tǒng)最多能處理一萬次訂單，這個處理能力應(yīng)付正常時段的下單時綽綽有余，正常時段我們下單一秒后就能返回結(jié)果。但是在高峰期，如果有兩萬次下單操作系統(tǒng)是處理不了的，只能限制訂單超過一萬后不允許用戶下單。使用消息隊列做緩沖，我們可以取消這個限制，把一秒內(nèi)下的訂單分散成一段時間來處理，這時有些用戶可能在下單十幾秒后才能收到下單成功的操作，但是比不能下單的體驗要好。
簡單來說： 就是在訪問量劇增的情況下，但是應(yīng)用仍然不能停，比如“雙十一”下單的人多，但是淘寶這個應(yīng)用仍然要運行，所以就可以使用消息中間件采用隊列的形式減少突然訪問的壓力

應(yīng)用解耦

以電商應(yīng)用為例，應(yīng)用中有訂單系統(tǒng)、庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)。用戶創(chuàng)建訂單后，如果耦合調(diào)用庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)，任何一個子系統(tǒng)出了故障，都會造成下單操作異常。當(dāng)轉(zhuǎn)變成基于消息隊列的方式后，系統(tǒng)間調(diào)用的問題會減少很多，比如物流系統(tǒng)因為發(fā)生故障，需要幾分鐘來修復(fù)。在這幾分鐘的時間里，物流系統(tǒng)要處理的內(nèi)存被緩存在消息隊列中，用戶的下單操作可以正常完成。當(dāng)物流系統(tǒng)恢復(fù)后，繼續(xù)處理訂單信息即可，中間用戶感受不到物流系統(tǒng)的故障，提升系統(tǒng)的可用性。

如圖：
把支付，庫存，物流都交給MQ

• 異步處理

有些服務(wù)間調(diào)用是異步的，例如 A 調(diào)用 B，B 需要花費很長時間執(zhí)行，但是 A 需要知道 B 什么時候可以執(zhí)行完，以前一般有兩種方式，A 過一段時間去調(diào)用 B 的查詢 api 查詢。或者 A 提供一個 callback api， B 執(zhí)行完之后調(diào)用 api 通知 A 服務(wù)。
這兩種方式都不是很優(yōu)雅，使用消息總線，可以很方便解決這個問題，A 調(diào)用 B 服務(wù)后，只需要監(jiān)聽 B 處理完成的消息，當(dāng) B 處理完成后，會發(fā)送一條消息給 MQ，MQ 會將此消息轉(zhuǎn)發(fā)給 A 服務(wù)。這樣 A 服務(wù)既不用循環(huán)調(diào)用 B 的查詢 api，也不用提供 callback api。同樣 B 服務(wù)也不用做這些操作。A 服務(wù)還能及時的得到異步處理成功的消息。

3. 四大核心概念

• 生產(chǎn)者：

  產(chǎn)生數(shù)據(jù)發(fā)送消息的程序是生產(chǎn)者

• 交換機
  交換機是 RabbitMQ 非常重要的一個部件，一方面它接收來自生產(chǎn)者的消息，另一方面它將消息推送到隊列中。交換機必須確切知道如何處理它接收到的消息，是將這些消息推送到特定隊列還是推送到多個隊列，亦或者是把消息丟棄，這個得有交換機類型決定

• 隊列
  隊列是 RabbitMQ 內(nèi)部使用的一種數(shù)據(jù)結(jié)構(gòu)，盡管消息流經(jīng) RabbitMQ 和應(yīng)用程序，但它們只能存儲在隊列中。隊列僅受主機的內(nèi)存和磁盤限制的約束，本質(zhì)上是一個大的消息緩沖區(qū)。許多生產(chǎn)者可以將消息發(fā)送到一個隊列，許多消費者可以嘗試從一個隊列接收數(shù)據(jù)。這就是我們使用隊列的方式

• 消費者
  消費與接收具有相似的含義。消費者大多時候是一個等待接收消息的程序。請注意生產(chǎn)者，消費者和消息中間件很多時候并不在同一機器上。同一個應(yīng)用程序既可以是生產(chǎn)者又是可以是消費者。

4. RabbitMQ 核心部分

• Hello Wold 簡單模式
• Work queues工作 隊列模式
• Publish/Subscribe發(fā)布訂閱模式
• Routing 路由模式
• Topics 主題模式
• Publisher Confirms 發(fā)布確認(rèn)模式

5. RabbitMQ工作原理

Broker：接收和分發(fā)消息的應(yīng)用，RabbitMQ Server 就是 Message Broker

Virtual host：出于多租戶和安全因素設(shè)計的，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似于網(wǎng)絡(luò)中的 namespace 概念。當(dāng)多個不同的用戶使用同一個RabbitMQ server 提供的服務(wù)時，可以劃分出多個 vhost，每個用戶在自己的 vhost 創(chuàng)建 exchange／queue 等

Connection：publisher／consumer 和 broker 之間的 TCP 連接

Channel：如果每一次訪問 RabbitMQ 都建立一個 Connection，在消息量大的時候建立 TCP Connection 的開銷將是巨大的，效率也較低。Channel 是在 connection 內(nèi)部建立的邏輯連接，如果應(yīng)用程序支持多線程，通常每個 thread 創(chuàng)建單獨的 channel 進行通訊，AMQP method 包含了 channel id 幫助客戶端和 message broker 識channel，所以 channel 之間是完全隔離的。Channel 作為輕量級的Connection 極大減少了操作系統(tǒng)建立 TCP connection 的開銷

Exchange：message 到達 broker 的第一站，根據(jù)分發(fā)規(guī)則，匹配查詢表中的 routing key，分發(fā)消息到 queue 中去。常用的類型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)

Queue：消息最終被送到這里等待 consumer 取走

Binding：exchange 和 queue 之間的虛擬連接，binding 中可以包含 routing key，Binding 信息被保存到 exchange 中的查詢表中，用于 message 的分發(fā)依據(jù)

總結(jié)

以上是生活随笔為你收集整理的RabbitMQ介绍（详细）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。