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消息中間件極速入門與實戰》。

原文出處：https://www.cnblogs.com/sgh1023/p/11217017.html