RocketMq遇到过的线上问题-消息积压

在顺序消费消息的场景中，消息落后量（积压量）在上午8点后慢慢增加，最终在饭点达到了报警阈值…

为什么消息会积压？

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

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

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

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

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

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

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

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

消息发送的顺序性
消息存储的顺序性
消息消费的顺序性

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

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

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

2、从消息存储的角度来看
RocketMq采用了队列文件来存储消息，即先进先出，这里不做过多说明

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

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

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

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

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

1、猜想一验证
生产者是否发送了过多的消息，从MQ的监控就可得知，如下图：

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

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

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

因此猜想一PASS

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

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

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

知识扩展
本部分内容属于扩展内容，可看可不看

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

2. Rocketmq的架构
   

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

Producer：消息生产者，将消息发送到 RocketMQ 中。

NameServer：命名服务，提供轻量级的服务发现和路由，维护 Broker 的状态信息。

Broker：消息中转角色，存储、接收和转发消息，每个 Broker 可以存储多个 Topic 的消息。

Consumer：消息消费者，从 Broker 消费消息。

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

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

具体的流程如下：

订单服务向NameServer获取订单主题所在的Broker的信息

订单服务向该Broker发送订单消息。

Broker（消息代理）将消息存储在自己的磁盘上，并返回确认消息给订单服务。

短信服务向NameServer获取订单主题所在的Broker信息，并在初始化时订阅了订单主题

当有新的订单消息产生时，Broker 会将消息推送给短信服务

短信服务收到消息并进行处理。

处理完成后，向 Broker 发送确认消息。

3. Rocketmq的顺序消息
   顺序消息需要保证消息的全链路有序，在RocketMq中，即消息顺序发送，顺序存储，以及顺序消费
   
   在顺序消息中，有两种常见的排序方式：全局有序和分区有序。

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

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

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

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

总结时刻

首先明确消息积压的问题就是消息消费的速度赶不上消息生产的速度，但这里面依然有多种原因导致的，比如消费者线程消费线程夯住，producer消息路由不均衡，producer短时间内生产消息过多等等，对于不同的情况，有不同的判断方式。

RocketMq的顺序消息是分区有序，发送消息的时候采用路由算法将某个ID的消息路由到一个队列中，然后消费的时候采用单线程消费来保证单个队列消费的有序性