RabbitMQ集群故障排查与恢复概述

1. 前言

Hello，大家好。通过上述几个小节的学习，我们已经了解了要搭建 RabbitMQ 集群所需的全部组件，以及一些基本的配置属性和配置项。

我们已经可以使用这些内容来搭建属于我们自己的 RabbitMQ 集群了，但是，考虑到本套课程作为 RabbitMQ 的入门课程，所以，不会介绍搭建 RabbitMQ 集群的详细步骤，感兴趣的同学可以自行查阅资料。

本小节作为本套课程中 RabbitMQ 集群介绍章节的收尾部分，会给各位同学介绍一下，在 RabbitMQ 集群运行时，当我们的集群发生了故障，或者集群有突发情况发生时，我们应该如何应对，即如何解决这一问题，使我们的集群环境恢复到正常运行状态。

本节主要内容：

• RabbitMQ 集群常见问题介绍；

• RabbitMQ 集群出现故障的原因分析；

• RabbitMQ 集群故障恢复方案介绍；

2.RabbitMQ 集群常见问题介绍

在我们搭建好 RabbitMQ 集群之后，无论我们采用哪种搭建方式，我们本身都需要知道一些集群中容易出现的问题，这样我们在遇到集群出现问题的时候，我们才不会那么慌张。

问题一：集群宕机

集群宕机这一问题，是无论搭建什么样的集群，都是比较容易出现的一种问题，这种问题出现的频率高，同时，也是最容易修复的一种问题。

那么什么是集群宕机呢？

集群宕机其实指的就是我们的 RabbitMQ 集群，所在的服务器节点，由于种种原因导致我们的 RabbitMQ Server 服务非自然停止，或意外退出的一种现象。

如果我们的 RabbitMQ Server 宕机了，就表明，我们的 RabbitMQ 集群中有一个或多个 RabbitMQ Server 服务节点不能够再继续提供服务了，那么所有有关 RabbitMQ Server 服务的请求都要在正常运行的服务节点上进行处理，可想而知，这种情况下，RabbitMQ 服务器所承受的压力有多大。

上述是集群宕机之后所造成的一个直接结果，还有一种间接结果也是非常致命的，那就是由于集群节点服务的宕机，用户请求只能在可用的集群节点上进行处理，如果这个节点的服务器配置较低，那么很可能由于处理请求数量的激增，导致这个节点的服务器直接崩掉，也就是直接关机，或者服务器不再返回任何响应，这种情况也是比较严重的。

问题二：集群间通信延迟

集群间通信延迟也是比较容易出现的一种问题，这种问题我们从字面意思上来看，基本上可以知道个大概。

集群间通信延迟问题，指的就是，RabbitMQ 集群中的一个节点向另一个节点传递数据，或者从另一个节点中获取数据时，目标节点不能及时将所需数据进行返回，导致的请求节点出现长时间等待的一种现象。

那么集群间通信延迟问题造成的直接影响就是，用户的数据不能同步更新，导致用户看到的数据是不准确的，这极大影响了用户的使用体验。

集群间通信延迟问题造成的间接影响就是，如果我们的目标节点迟迟不能返回响应数据，就会导致请求节点一直等待，那么位于请求节点上后续的用户请求就不能得到处理，这就是请求阻塞现象。

问题三：集群数据文件丢失

集群数据文件丢失问题相对而言，出现的频率较低，但是我们应该也要进行简单的了解。

集群数据文件丢失问题，指的就是，位于服务器上的 RabbitMQ Server 节点突然出现的一种服务器磁盘数据丢失现象， 这种问题不出现还好，一旦出现，一般都是致命性的问题，往往恢复的时间也是最长的。

集群数据文件丢失问题的出现，会直接影响用户无法打开我们的项目或应用，给用户造成非常严重的体验问题，同时，也会间接导致用户关键数据的丢失，造成我们的项目或者应用用户的一个流失。

以上三种问题类型，是 RabbitMQ 集群中比较常见的三种问题类型，无论出现哪种问题，我们都应该知道一个大概的解决措施，或者恢复方案，下面让我们先来分析一下产生这三种问题的常见原因。

3 RabbitMQ 集群出现故障的原因分析

问题一：集群宕机

出现集群宕机问题的原因，我们可以从服务器所处的运行环境进行考虑，考虑几种因素：

1. 服务器本身硬件配置较低，不足以支撑我们的集群服务环境，导致集群运行环境崩溃。

2. 一台服务器上同时部署了超过 3 个或以上数量的项目，导致服务器内存被占满，使我们的集群运行环境不能正常运行。

3. 由于开发人员自身技术问题，在部署集群时，导致集群节点没有加入到我们的 RabbitMQ 集群队列中去，导致我们在启动集群时，这一集群节点不能被启动。

问题二：集群间通信延迟

出现集群间通信延迟问题的原因，我们可以从程序本身，以及集群所处的位置来考虑，考虑几种因素：

1. 我们在配置 RabbitMQ 集群时，不同节点间所设置的集群配置属性的数值不合理，导致配置小的集群节点需要等待配置大的集群节点。

2. 我们在部署 RabbitMQ 集群时，我们所部署的地理位置区域之间的间隔过大，例如，我们在北京区域部署了一个服务节点，然后我们又在香港区域部署了一个服务节点，这样无形之中就会加重我们集群节点间服务的响应时间。

3. 在处理用户请求时，用户请求没有按照我们之前设定好的 RabbitMQ 集群分发策略来进行，导致用户请求被分发到了非目标集群节点上，导致服务响应缓慢。

问题三：集群数据文件丢失

就请你数据文件丢失问题的原因，我们可以从运维和服务提供商来考虑，考虑集中因素：

1. 服务运维人员主动将 RabbitMQ 集群数据文件删除，以报复公司或报复社会。

2. 我们的服务器服务提供方没有提供集群数据备份机制，或服务提供方的机房不稳定，由于外界因素导致机房断电，RabbitMQ 集群数据文件来不及备份而丢失。

3. 我们在配置 RabbitMQ 集群时，没有配置集群数据文件备份策略，导致发生突发情况时，集群数据文件直接丢失。

4. RabbitMQ 集群故障恢复方案介绍

我们在了解了常见问题，以及常见问题的产生原因之后，我们还需要知道一些常见故障的恢复方案，这里为大家简单介绍一下。

由于集群宕机所引发的集群故障，我们在恢复起来时，可以从集群节点发生宕机的先后顺序考虑，如果我们的从节点先发生了宕机，接着主节点也发生了宕机，那么这种情况我们该如何恢复呢？

这种情况下，我们只需要先启动我们的主节点，接着再启动我们的从节点就行了，我们的集群也就恢复到正常运行状态了。

如果我们主从节点同时发生了宕机，那又该如何恢复呢？

这种情况下，我们服务器所在的机房发生短暂停电的可能性最大，我们只需要在 30 秒内依次启动主节点、从节点即可将集群恢复到正常的运行状态。

如果我们的从节点发生了宕机，接着主节点也发生了宕机，但是，我们的从节点启动不起来了，这种情况我们又该如何恢复呢？

这种情况我们需要先将主节点启动起来，然后在主节点中通过运行一下命令来将不能够启动的从节点先从集群中剔除掉：

rabbitmqctl forget_cluster_node name(节点名称)

然后我们可以启动一个新的从节点，再将这个新的从节点加入到我们的 RabbitMQ 集群中来就可以了。

Tips:
1. 同学们在对不同集群节点的配置参数进行配置时，一定要综合考虑集群所在服务器的环境，以及预估一下本节点所能扛得住的最高请求数量，这可以对我们设置集群配置参数提供一定的参考；
2. 如果集群发生了宕机或者其他突发问题，同学们一定不要慌张，一定要结合本小节所介绍的内容去冷静的分析问题的原因，然后第一时间恢复集群的运行状态。

5. 小结

本小节为同学们详细介绍了 RabbitMQ 集群中较常见的几种问题，介绍了常见问题对我们的 RabbitMQ 集群所造成直接影响与间接影响。接着，介绍了这几种问题所产生的原因，详细为同学们分析了常见的问题产生因素。最后，结合常见的业务场景，为同学们介绍了，场景集群故障的恢复方案。

通过以上几部分内容的介绍，希望同学们对 RabbitMQ 中的集群问题有一个简单的系统性地了解，这样，同学们在实际工作中如果遇到了这些集群问题，可以第一时间进行修复。