使用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 自身的消息队列，已经非常可靠了，可以适应很多业务场景，除了非常要求性能的高并发场景之外，一般的高并发场景，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 打造高可用队列的理论实现。

同学们只有对本节内容所提及的理论实现思路有所了解之后，才会在最后的下一小节中的代码实操部分，理解相应地代码的含义，如果本小节的理论实现思路你没有理解，那还请多学习几遍，否则，在下一小节中你就会一脸懵。