RabbitMQ（一）：RabbitMQ快速入門

RabbitMQ是目前非常熱門的一款消息中間件，不管是互聯網大廠還是中小企業都在大量使用。作爲一名合格的開發者，有必要對RabbitMQ有所瞭解，本文是RabbitMQ快速入門文章，主要內容包括RabbitMQ是什麼、RabbitMQ核心概念、常用交換器類型、用Docker安裝RabbitMQ等。

RabbitMQ簡介

以熟悉的電商場景爲例，如果商品服務和訂單服務是兩個不同的微服務，在下單的過程中訂單服務需要調用商品服務進行扣庫存操作。按照傳統的方式，下單過程要等到調用完畢之後才能返回下單成功，如果網絡產生波動等原因使得商品服務扣庫存延遲或者失敗，會帶來較差的用戶體驗，如果在高併發的場景下，這樣的處理顯然是不合適的，那怎麼進行優化呢？這就需要消息隊列登場了。

消息隊列提供一個異步通信機制，消息的發送者不必一直等待到消息被成功處理才返回，而是立即返回。消息中間件負責處理網絡通信，如果網絡連接不可用，消息被暫存於隊列當中，當網絡暢通的時候在將消息轉發給相應的應用程序或者服務，當然前提是這些服務訂閱了該隊列。如果在商品服務和訂單服務之間使用消息中間件，既可以提高併發量，又降低服務之間的耦合度。

RabbitMQ就是這樣一款我們苦苦追尋的消息隊列。RabbitMQ是一個開源的消息代理的隊列服務器，用來通過普通協議在完全不同的應用之間共享數據。

RabbitMQ是使用Erlang語言來編寫的，並且RabbitMQ是基於AMQP協議的。Erlang語言在數據交互方面性能優秀，有着和原生Socket一樣的延遲，這也是RabbitMQ高性能的原因所在。可謂“人如其名”，RabbitMQ像兔子一樣迅速。

RabbitMQ除了像兔子一樣跑的很快以外，還有這些特點：

• 開源、性能優秀，穩定性保障
• 提供可靠性消息投遞模式、返回模式
• 與Spring AMQP完美整合，API豐富
• 集羣模式豐富，表達式配置，HA模式，鏡像隊列模型
• 保證數據不丟失的前提做到高可靠性、可用性

MQ典型應用場景：

• 異步處理。把消息放入消息中間件中，等到需要的時候再去處理。
• 流量削峯。例如秒殺活動，在短時間內訪問量急劇增加，使用消息隊列，當消息隊列滿了就拒絕響應，跳轉到錯誤頁面，這樣就可以使得系統不會因爲超負載而崩潰。
• 日誌處理
• 應用解耦。假設某個服務A需要給許多個服務（B、C、D）發送消息，當某個服務（例如B）不需要發送消息了，服務A需要改代碼再次部署；當新加入一個服務（服務E）需要服務A的消息的時候，也需要改代碼重新部署；另外服務A也要考慮其他服務掛掉，沒有收到消息怎麼辦？要不要重新發送呢？是不是很麻煩，使用MQ發佈訂閱模式，服務A只生產消息發送到MQ，B、C、D從MQ中讀取消息，需要A的消息就訂閱，不需要了就取消訂閱，服務A不再操心其他的事情，使用這種方式可以降低服務或者系統之間的耦合。

AMQP協議和RabbitMQ

提到RabbitMQ，就不得不提AMQP協議。AMQP協議是具有現代特徵的二進制協議。是一個提供統一消息服務的應用層標準高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。

先了解一下AMQP協議中間的幾個重要概念：

• Server：接收客戶端的連接，實現AMQP實體服務。
• Connection：連接，應用程序與Server的網絡連接，TCP連接。
• Channel：信道，消息讀寫等操作在信道中進行。客戶端可以建立多個信道，每個信道代表一個會話任務。
• Message：消息，應用程序和服務器之間傳送的數據，消息可以非常簡單，也可以很複雜。有Properties和Body組成。Properties爲外包裝，可以對消息進行修飾，比如消息的優先級、延遲等高級特性；Body就是消息體內容。
• Virtual Host：虛擬主機，用於邏輯隔離。一個虛擬主機裏面可以有若干個Exchange和Queue，同一個虛擬主機裏面不能有相同名稱的Exchange或Queue。
• Exchange：交換器，接收消息，按照路由規則將消息路由到一個或者多個隊列。如果路由不到，或者返回給生產者，或者直接丟棄。RabbitMQ常用的交換器常用類型有direct、topic、fanout、headers四種，後面詳細介紹。
• Binding：綁定，交換器和消息隊列之間的虛擬連接，綁定中可以包含一個或者多個RoutingKey。
• RoutingKey：路由鍵，生產者將消息發送給交換器的時候，會發送一個RoutingKey，用來指定路由規則，這樣交換器就知道把消息發送到哪個隊列。路由鍵通常爲一個“.”分割的字符串，例如“com.rabbitmq”。
• Queue：消息隊列，用來保存消息，供消費者消費。

我們完全可以直接使用 Connection 就能完成信道的工作，爲什麼還要引入信道呢?

試想這樣一個場景， 一個應用程序中有很多個線程需要從 RabbitMQ 中消費消息，或者生產消息，那麼必然需要建立很多個 Connection，也就是許多個 TCP 連接。然而對於操作系統而言，建立和銷燬 TCP 連接是非常昂貴的開銷，如果遇到使用高峯，性能瓶頸也隨之顯現。 RabbitMQ 採用 TCP 連接複用的方式，不僅可以減少性能開銷，同時也便於管理 。

下圖是AMQP的協議模型：

正如圖中所看到的，AMQP協議模型有三部分組成：生產者、消費者和服務端。

生產者是投遞消息的一方，首先連接到Server，建立一個連接，開啓一個信道；然後生產者聲明交換器和隊列，設置相關屬性，並通過路由鍵將交換器和隊列進行綁定。同理，消費者也需要進行建立連接，開啓信道等操作，便於接收消息。

接着生產者就可以發送消息，發送到服務端中的虛擬主機，虛擬主機中的交換器根據路由鍵選擇路由規則，然後發送到不同的消息隊列中，這樣訂閱了消息隊列的消費者就可以獲取到消息，進行消費。

最後還要關閉信道和連接。

RabbitMQ是基於AMQP協議實現的，其結構如下圖所示，和AMQP協議簡直就是一模一樣。

常用交換器

RabbitMQ常用的交換器類型有direct、topic、fanout、headers四種。

Direct Exchange

該類型的交換器將所有發送到該交換器的消息被轉發到RoutingKey指定的隊列中，也就是說路由到BindingKey和RoutingKey完全匹配的隊列中。

Topic Exchange

該類型的交換器將所有發送到Topic Exchange的消息被轉發到所有RoutingKey中指定的Topic的隊列上面。

Exchange將RoutingKey和某Topic進行模糊匹配，其中“”用來匹配一個詞，“#”用於匹配一個或者多個詞。例如“com.#”能匹配到“com.rabbitmq.oa”和“com.rabbitmq”；而"login."只能匹配到“com.rabbitmq”。

Fanout Exchange

該類型不處理路由鍵，會把所有發送到交換器的消息路由到所有綁定的隊列中。優點是轉發消息最快，性能最好。

Headers Exchange

該類型的交換器不依賴路由規則來路由消息，而是根據消息內容中的headers屬性進行匹配。headers類型交換器性能差，在實際中並不常用。

安裝和使用入門

在雲計算和容器技術大熱的今天，不會Docker顯得未免太out了吧。Docker提供一種安全、可重複的環境中自動部署軟件的方式，本文使用Docker進行安裝RabbitMQ。

• 進入官方下載地址，選擇使用Docker安裝，跳轉到dockerhub查看鏡像。

• 我選擇3.8.0-beta.4-management進行安裝，帶有management是含有管理界面的。

• 拉取鏡像和啓動：docker run -d --hostname my-rabbit -p 5672:5672 -p 15672:15672 rabbitmq:3.8.0-beta.4-management

• 查看鏡像：

[root@localhost ~]# docker images
REPOSITORY              TAG                       IMAGE ID            CREATED             SIZE
docker.io/rabbitmq      3.8.0-beta.4-management   d0f93d2b83f7        3 days ago          180 MB

• 打開瀏覽器訪問localhost:15672，如果你和我一樣裝在虛擬機上面的話，需要打開虛擬機ip:15672

• 進行填寫賬號密碼：默認賬號密碼都是guest.

到此，RabbitMQ已經安裝並運行起來了。

總結

本文介紹了RabbitMQ是什麼、RabbitMQ核心概念、常用交換器類型、用Docker安裝RabbitMQ等內容，看完本文，想必對於RabbitMQ已經有了一些初步的瞭解了，後面的世界更精彩。

本文參考慕課網免費課程：《RabbitMQ消息中間件極速入門與實戰》。