使用RabbitMQ打造扛得住的高并發環境(二)

1. 前言

Hello，大家好。我們在上一小節中，介紹了使用 RabbitMQ 打造扛得住的高并發環境系列內容的第一小節部分，也就是我們的準備內容。

本小節會繼續介紹使用 RabbitMQ 打造扛得住的高并發環境系列內容的第二部分，在本小節中，我們會使用我們在第一節中安裝好的 Redis 緩存中間件，結合 RabbitMQ 消息通信中間件，來完成我們此系列小節內容的核心部分。

在將此系列小節內容的核心部分完成之后，我們在此系列最后一小節中就會用到我們搭建的核心部分，下面就讓我們來看看這一核心內容到底是什么吧！

本節主要內容：

• RabbitMQ 整合 Redis 概述；

• RabbitMQ + Redis 打造高可用消息隊列概述。

2.RabbitMQ 整合 Redis 概述

RabbitMQ 消息通信中間件，整合 Redis 緩存中間件，這一整合集成方案，已經是計算機業界主流的解決方案，該方案的誕生目的，或者說是主要目標，就是解決一般高并發場景下的請求激增而引發的服務器壓力過大或服務器宕機的問題。

RabbitMQ 與 Redis 的整合解決方案，經過了計算機業界常年的應用考核，以及計算機互聯網大廠中，實際高并發真實業務場景的考核，這一整合方案的應用，各互聯網大廠以及業界前輩，為我們積累了寶貴的實戰經驗。

RabbitMQ 消息通信中間件，整合 Redis 緩存中間件，這一整合集成方案發展到現在，已經演進出了很多經典的實現方式，為不同的問題提供了不同的解決方案，本小節會介紹這一整合方案中最基礎的實現場景。

RabbitMQ 消息通信中間件整合 Redis 緩存中間件最基礎的實現場景，其實核心就是將這兩個中間件之間的通信進行打通， 使位于 RabbitMQ 消息通信中間的消息可以經過 Redis 緩存中間件，同時，Redis 緩存中間件中的數據，也可以根據實際情況分發到 RabbitMQ 消息通信中間件中。

下面讓我們來看一下具體的整合步驟。

像本套課程開篇那樣，我們使用的是基于 Spring Boot Web 框架而搭建的課程項目，并且，是以 Maven 包管理工具來管理項目中各種 jar 包等依賴項，所以，要想整合 RabbitMQ 與 Redis ，應該首先將這兩個中間件的 Maven 依賴集成到我們項目中去。

關于 RabbitMQ 與 Redis 的兩個 Maven 依賴，老師這里直接給出，不需要同學們去自行查找了。

RabbitMQ-Spring 依賴如下：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>3.6.5</version>
</dependency>

Redis-Spring 依賴如下：

 <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

在將上述 RabbitMQ 和 Redis 的依賴引入到項目中去之后，我們的項目就具備了 RabbitMQ 和 Redis 的能力，下面我們要做的就是對 RabbitMQ 和 Redis 進行相應的配置，以滿足我們的項目需求。

這里簡單來說一下我們都需要配置 RabbitMQ 和 Redis 哪些屬性內容。

對于 RabbitMQ 來說，我們需要在項目中配置 RabbitMQ Server 服務所在節點的主機 host 地址，然后配置 RabbitMQ Server 的用戶名和密碼(如果有的話)，以及 RabbitMQ Server 服務所占用的端口號，默認為 5672 ，最后，配置 RabbitMQ Server 默認使用的交換機名稱，就可以了。

對于 Redis 來說，我們同樣地需要配置 Redis Server 服務所在節點的主機 host 地址，然后配置訪問 Redis Server 所需要的用戶名和密碼(本教程沒有設置)，接著配置 Redis Server 服務所占用的端口，默認是 6379 ，就可以了。

我們只要在項目中完成了上述所介紹的配置內容之后，基本上 RabbitMQ 和 Redis 就可以滿足我們的項目需求了。由于配置文件的介紹不屬于本小節內容范疇，所以 RabbitMQ 和 Redis 的詳細配置文件本小節不再進行介紹，同學們可以自行查閱相關資料獲取。

在將 RabbitMQ 消息通信中間件與 Redis 緩存中間件在項目中配置完成之后，接下來我們就是使用 RabbitMQ 和 Redis 去打造我們的高可用消息隊列了。

Tips: 請同學們在引入 RabbitMQ 與 Redis 的 Maven 依賴時直接復制上述依賴代碼段，所引入的依賴版本務必要和老師的保持一致，尤其是 RabbitMQ 的版本。

3.RabbitMQ + Redis 打造高可用消息隊列概述

其實，RabbitMQ 自身的消息隊列，已經非?？煽苛耍梢赃m應很多業務場景，除了非常要求性能的高并發場景之外，一般的高并發場景，RabbitMQ 自身的消息隊列完全可以應付， 只不過，在一般的高并發場景中，我們只會使用 RabbitMQ 消息通信中間件這么一種工具來應對高并發。

這種場景下，由于我們沒有使用其他的中間件工具，來處理高并發的請求，而是將所有的高并發請求都分發到 RabbitMQ 消息通信中間件上去處理，這就會直接導致我們的 RabbitMQ Server 服務的負載出現激增，或者是 RabbitMQ Server 服務的負責維持在一個很高的數值上。

如果 RabbitMQ Server 服務的高負載現象所維持的時間不長，在維持了半分鐘或者是一分鐘之后，RabbitMQ Server 服務的高負載已經降到了較低數值，這種現象是正常的，沒有任何問題的。

但是，如果在一般地高并發環境中，我們 RabbitMQ Server 服務的負載一直維持在了一個很高的數值上，那么，這種現象就非常危險了，因為，持續過高的 RabbitMQ Server 服務負載，會持續汲取服務器大部分的資源，如果，此時服務器上還有其他項目在運行，那很可能導致該項目不能正常運行。

最可怕的現象就是，RabbitMQ Server 持續地汲取服務器資源，并最終導致我們 RabbitMQ Server 服務所在節點的服務器資源消耗殆盡， 服務器就會直接崩潰或者宕機，此時的 RabbitMQ Server 服務就不會返回給我們任何響應了。

這種問題，我們一般稱它為’服務過載化’現象， 這種現象是我們都不希望發生的，不管在服務器上運行著哪些服務，服務器的資源都應該被合理地分配，而不是只被一個服務所獨吞。

為了緩解，或者解決上述這種問題，我們引入了 Redis 緩存中間件，我們可以在 RabbitMQ 正式發送消息之前，使用 Redis 將數據進行一個緩存， 并結合后續地業務邏輯，決定 Redis 中的緩存數據是否需要被發送到 RabbitMQ 消息通信中間件中。

通過對 Redis 的這種配置，我們實現了數據與 RabbitMQ 之間的一種緩沖屏障，當再有請求過來時，我們首先訪問的是 Redis 緩沖屏障，然后我們再根據具體的業務邏輯，將 Redis 緩存中的數據發送到 RabbitMQ 中，這樣并不會將所有的請求都分發到 RabbitMQ 中了。

這樣一來，我們就緩解了 RabbitMQ Server 服務的壓力，降低了 RabbitMQ Server 服務的負載，優化了服務間的資源占用問題。上述實現原理如下圖所示：

同學們可以結合這個原理圖去理解上述內容。

通過上述打造過程，我們基本上已經實現了一種高可用的消息隊列，這里的高可用并不是指的是集群間的高可用，而是指的是具體的一種服務的高可用，即 RabbitMQ 消息隊列服務的高可用改造過程，這點同學們不要搞混淆了。

Tips: 本節只會介紹打造高可用消息隊列的理論思路，并不會進行代碼層面的實操介紹，為什么要這么做呢？因為同學們只有在將這些理論思路產生一個自己的理解之后，我們的代碼實操同學們才能看的懂，我們會在下一小節中進行代碼實操部分的介紹。

4. 小結

本小節為同學們介紹了使用 RabbitMQ 打造扛得住的高并發環境的第二部分內容，包括 RabbitMQ 如何與 Redis 進行整合的詳細步驟，以及 RabbitMQ 和 Redis 的一些基礎配置內容，最后，我們使用 RabbitMQ 與 Redis 將 RabbitMQ 消息隊列進行了改造，介紹了如何使用 Redis 和 RabbitMQ 打造高可用隊列的理論實現。

同學們只有對本節內容所提及的理論實現思路有所了解之后，才會在最后的下一小節中的代碼實操部分，理解相應地代碼的含義，如果本小節的理論實現思路你沒有理解，那還請多學習幾遍，否則，在下一小節中你就會一臉懵。