一、缘起

在一个阳光明媚的中午，虽然还没到饭点，但我已沉浸在午饭的抉择中无法自拔，正当我准备奔向食堂大快朵颐时，秃然，奇怪的现象发生了……

本文是线上问题专栏的第三篇，内容为【消息队列积压危机解析：排查和解决方法】，其余两篇内容如下：

【面试拿来即用系列】你遇到过什么线上问题，如何解决的？（一）- 分库分表流量倾斜问题的排查与解决

【面试拿来即用系列】你遇到过什么线上问题，如何解决的？（二）- 容器线程数过多的排查与解决

文章之间无关联，点赞关注后食用最佳，若文章有描述不清楚的地方，可在评论区指出，我会进行补充完善

注：本文是中大型互联网公司遇到的真实案例（没错，就是我亲自遇到的……），其知识点的深度和广度拿来面试都足够，建议认真阅读并且熟悉涉及到的相关知识点。若有任何问题可在评论区指出~

二、奇怪的现象

如上图所示，消息落后量（积压量）在上午8点后慢慢增加，最终在饭点达到了报警阈值......

三、猜想

让我们花费0.01秒想一想，为什么消息会积压？

当然是消费消息的速度赶不上消息生产的速度了啊，这里面又包含了三层信息，生产者太快、消费者太慢、生产者即太快消费者又太慢。于是乎开启“胡思乱想”模式得到了以下三个猜想

猜想一：频繁的数据改动导致生产者短时间内生产消息过多，消费者来不及消费

猜想二：生产者正常，但消费者消费消息出了点问题，导致消费过慢。如消费线程夯住，或者消费逻辑抛异常了，导致消费线程卡住，或逻辑不断的重试。新的消息需要继续消费，老的消息还要不断重试，消费者表示它比较累，它鸭梨山大，它觉得就像我们这届年轻人一样，承担了过多……

猜想三：约等于猜想一加猜想二同时存在

猜想验证前

问题发生后，需要先了解下这个生产者和消费者的相关信息

生产者是商品价格、状态等信息发生变更时即发MQ

消费者是统计商品的最大价格和最小价格等数据，因此需要顺序消费消息

简单聊聊顺序消息啊，顺序消息，即先发的消息先消费，后发的消息后消费，因此这里可以拆成三个维度的顺序性：

1. 消息发送的顺序性
2. 消息存储的顺序性
3. 消息消费的顺序性

RocketMq的顺序消息采用的方案是分区有序，即保证单个队列的消费是顺序的，举个例子：

张三的订单-3经历了创建订单，支付订单、订单发货三个流程，李四的订单-4也是如此，现在要对它们顺序消费（不然先收到订单发货的消息，过一段时间才收到订单创建的消息你懵不懵啊）

从消息发送的角度来看

RcoketMq要保证订单-3的消息是顺序的，订单4的消息是顺序的，而订单3和订单4之间并不要求有序，如下图，RocketMq采用的方案是将订单3的消息都放在了队列1，订单4的消息都放在了队列2

从消息存储的角度来看

RocketMq采用了队列文件来存储消息，即先进先出，这里不做过多说明

从消息消费的角度来看

对于顺序消息，RocketMq采用单线程来消费一个队列的消息，在上图中只有两个队列的情况下，顺序消息消费的最大并发度就只有2了，如下图：

总结一下，对于顺序消息，rocketMq的做法是：

1. 消息发送的时候，对于需要保持顺序的消息需要发送到一个队列中

2. 消息消费的时候，用单线程来消费一个队列中的消息

OK，下面就到了精彩的猜想验证环节~

四、猜想验证

4.1 猜想一验证

生产者是否发送了过多的消息，从MQ的监控就可得知，如下图：

可以发现，发送的消息量确实增加了，而且是这种锯齿状，明显是某种JOB任务

（此时已经开始意淫揪到某个小伙伴，把锅盖到他的头上，问他为什么发这么多消息）

但仔细一看，最高QPS也才105左右，而且从服务监控可以看到，消费逻辑耗时30ms左右，这样的话单线程每秒大概可以消费30个消息（因为顺序消息就是单线程消费），16个队列的话每秒大概可以同时消费480个消息（共4台消费者机器），完全没压力啊（此时感觉锅又到了我的头上，沉重无比）

因此猜想一PASS

4.2 猜想二验证

猜想二指的是生产者消息发送正常，消费慢是由消费者引起的。根据猜想一可知，生产者发送的消息和平时相比已经增加了不少，因此猜想二PASS

4.3 猜想三验证

生产者发送消息变多依然是事实，现在的关注点是：为什么消费者消费这么慢？

消费者消费慢有可能是因为消费逻辑出异常，消费不断重试导致的，这个很好验证，去看下消费者的错误日志即可，一片风平浪静。。

还有可能是消费线程夯住？这个可以通过消费者消费进度来验证，如果进度Consumer offset一直不变化的话，可以证明消费线程有卡住的可能性，然鹅，这里的消费进度也一直在变化，所以也不是此原因导致的。（下图是我随便找的一个例子的数据，和案例无关，案例发生较久远，下图的数据当时没保存。。）

Consumer offset指的是消费进度，消费越多，此值越大，Diff可以理解为消息积压数

所以现在的问题很明确了，就是消费慢，咋滴吧？

正在一筹莫展时，关注到一个震惊的数据！

队列0的数据比其他队列高了几个数量级，如下图

这就有意思了，敢情所有的消息基本都路由到队列0去了，而顺序消息是单线程消费，QPS也就30左右，所以就不断的积压呗

上面说顺序消息的时候，聊了下发送的顺序性，rocketmq会将要保证顺序的消息路由到一个队列，这个路由的算法是我们自定义的，如下：

int queueIndex = infoId%queueSize;

其中infoId是商品ID，采用雪花算法生成

queueSize为队列数量，这里为16

雪花算法在分库分表流量倾斜问题的排查与解决 已经详细介绍过，这里不再赘述，只列举雪花算法的二进制位组成，如下：

64位ID = (42(毫秒)+8(业务编码)+5(机器ID)+9(重复累加))

需要注意的是后9位为毫秒内重复累加位，举个例子，在1毫秒内如果创建两个商品，那后9位分别是0和1。而创建商品是个相对低频的操作，毫秒内创建多个商品更是少之又少，因此大部分商品ID后9位基本是0

而路由算法是infoId%queueSize，在queueSize为2的幂次方的情况下，其算法等同于infoId&(queueSize-1)，也就是infoId&15，其二进制位运算如下图：

这里可以参考HashMap的桶定位算法，因为与运算的性能高于取余运算，因此Hashmap将容量定义为2的n次幂，这样取余运算就可以转换为与运算，即：hash%length==hash&(length-1)

可见二进制15的末四位为1，其余均为0，在只有后四位参与运算的情况下，商品ID末9位基本均为0，这也就导致了大部分数据路由到了0队列上

至此，真相大白

四、解决方案

将infoId再Hash一次，打破雪花算法的后9位规律，然后再做取余运算

int hash = hash(infoId);
int queueIndex = hash % queueSize;

扩展：这么调整有没有问题？

极端情况下是有的，因为改变了队列的路由算法，会导致同一个ID不在同一个队列中，从而破坏了其顺序性，因篇幅过长，解决方案后续的文章中推出，关注秃我，加更不迷路~

五、改造效果

下图可见消费QPS完全跟得上发送QPS

下图显示消费积压量也正常了

六、知识扩展

6.1 RocketMQ基础

本部分不会大而全的讲述RocketMq的所有知识，而是有侧重的只关注和该问题相关的部分内容 在没有知识背景或问题背景关联的情况下，大而全的知识看完只会让你，额 ，很虚

后续的文章内容也会按照这种思路进行输出->引入一个问题->介绍相关知识体系

6.2 Rocketmq的架构

RocketMQ 是一个分布式消息中间件，其整体架构可以分为以下几个部分：

1. Producer：消息生产者，将消息发送到 RocketMQ 中。
2. NameServer：命名服务，提供轻量级的服务发现和路由，维护 Broker 的状态信息。
3. Broker：消息中转角色，存储、接收和转发消息，每个 Broker 可以存储多个 Topic 的消息。
4. Consumer：消息消费者，从 Broker 消费消息。

举一个例子将上述的架构串一下：

比如有一个电商网站，需要使用 RocketMQ 来处理订单消息。订单消息由订单服务产生并发送到 RocketMQ 中，短信服务通过订阅 RocketMQ 中的订单主题，实现对订单消息的处理。如下图

具体的流程如下：

1. 订单服务向NameServer获取订单主题所在的Broker的信息
2. 订单服务向该Broker发送订单消息。
3. Broker（消息代理）将消息存储在自己的磁盘上，并返回确认消息给订单服务。
4. 短信服务向NameServer获取订单主题所在的Broker信息，并在初始化时订阅了订单主题
5. 当有新的订单消息产生时，Broker 会将消息推送给短信服务
6. 短信服务收到消息并进行处理。
7. 处理完成后，向 Broker 发送确认消息。

Rocketmq的顺序消息

顺序消息需要保证消息的全链路有序，在RocketMq中，即消息顺序发送，顺序存储，以及顺序消费

在顺序消息中，有两种常见的排序方式：全局有序和分区有序。

全局有序是指在整个消息系统中，所有的消息都按照特定的顺序进行排序。也就是说，对于所有的消息，无论它们来自哪个生产者，都按照同一种排序规则进行排序。

分区有序是指在消息系统中，将消息划分为多个分区，每个分区内的消息都按照特定的顺序进行排序，但不同分区之间的消息不保证有序。

举个例子来说，假设有一个电商系统，需要处理用户下单的消息。每个用户都有一个唯一的ID，为了保证处理订单的有序性，我们可以将消息系统中的订单消息按照用户ID进行分区，每个分区内的订单消息都按照订单创建时间进行排序，这样就能保证同一个用户的订单消息按照创建时间的先后顺序进行处理，而不同用户的订单消息则可能会以不同的顺序进行处理。这就是分区有序的例子。

另外，如果我们将整个消息系统中的所有订单消息都按照订单创建时间进行排序，这就是全局有序的例子。

七、总结时刻

• 本文阐述了消息积压问题的排查方法论
• 首先明确消息积压的问题就是消息消费的速度赶不上消息生产的速度，但这里面依然有多种原因导致的，比如消费者线程消费线程夯住，producer消息路由不均衡，producer短时间内生产消息过多等等，对于不同的情况，有不同的判断方式。
• RocketMq的顺序消息是分区有序，发送消息的时候采用路由算法将某个ID的消息路由到一个队列中，然后消费的时候采用单线程消费来保证单个队列消费的有序性
• 问题千变万化，不可能全部学会，也没这个必要，但遇到问题的时候，解决问题后要进行反思，将具体的问题解决方案进行抽象丶沉淀，下次再遇到类似问题的时候，定位，排查，解决的思路就会很清晰，这也就是传说中的方法论
• 如果是解决了本次的问题是鱼，那方法论就是渔
• 调研下，本文讲述思路是否清晰？小伙伴是否能看懂？可以在评论区指出，不足地方我会进行优化
• 最后，不如关注一下？