1. RabbitMQ 的相關概念

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

2. 為什么要用 MQ

流量消峰

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

應用解耦

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

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

• 異步處理

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

3. 四大核心概念

• 生產者：

  產生數據發送消息的程序是生產者

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

• 隊列
  隊列是 RabbitMQ 內部使用的一種數據結構，盡管消息流經 RabbitMQ 和應用程序，但它們只能存儲在隊列中。隊列僅受主機的內存和磁盤限制的約束，本質上是一個大的消息緩沖區。許多生產者可以將消息發送到一個隊列，許多消費者可以嘗試從一個隊列接收數據。這就是我們使用隊列的方式

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

4. RabbitMQ 核心部分

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

5. RabbitMQ工作原理

Broker：接收和分發消息的應用，RabbitMQ Server 就是 Message Broker

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。