一次 MQ 堆积的解决 (并发地从数据库中查询出大量数据导致数据库繁忙最终宕机)

生产记录

发布日期: 2023-11-07

更新日期: 2024-10-10

文章字数: 1.6k

阅读时长: 6 分

阅读次数:

这次事故实际的借鉴意义不大, 只是整个解决过程比较有趣, 所以记录一下。

1 背景

为了应对旺季的到来, 加上一些重要的接口的性能未知, 所以决定对这些接口进行压测并优化。

但是生产和测试环境的机器性能等差距很大, 为了准确性, 所以决定在生产环境进行压测。
先通过特定的账号进行压测, 然后删除这批账号产生的数据, 通过这种方式得到最准确的结果。

2 结论

压测的接口中有一个的功能, 高度概括如下:

一次 Http 请求, 会产生 n 条数据库记录, 发送出 n 条 MQ 消息

每条 MQ 消息会从数据库中查询出所有的记录, 然后处理这些记录

对这个接口进行压测时, 随着请求量的增加

数据库记录越来越多

MQ 消费时, 查询数据库时越来越慢, 消费能力随之下降, 最终导致 MQ 堆积

发现堆积时, 在不了解具体逻辑时, 本着先解决问题再定位原因的原则, 我们选择了不断提高 MQ 消费能力, 最终导致

数据库的查询压力越来越大, 先是触发了主从切换, 然后没多久整个库还是挂了

应用这边有的卡在等待数据库响应全部数据, 有的是查询到了大量数据, 进入了 GC

3 过程

3.1 反馈

20:00, 测试开始压测。
20:30, 测试说明压测结束。
20:35, 测试反馈生产出现 MQ 堆积。

Alt 'MQ 堆积告警图'

3.2 解决

3.2.1 启动新的实例, 先解决堆积

这种 MQ 堆积的情况, 个人习惯都会先确定一下对应的消费线程的状态, 确定是消费慢, 还是消费阻塞等原因。

进入到某个生产实例, 执行

## 获取到当前 Java 程序的进程号
jps -l 

## 查看 MQ 消费线程堆栈的情况, ConsumeMessageThread 是我们定义的 MQ 消费线程的名称前缀
jstack 74 | grep "ConsumeMessageThread" -C 50

情况如下:

"ConsumeMessageThread_20" #36030 prio=5 os_prio=@ tid=0x00007f1648035000 nid=®x4b59b waiting on condition (0x00007f1c0e9f0000]
    java. lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park (Native Method)
    - parking to wait for
    <0x00000000c3a23938> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$Condition0bject)
    at java.til. concurrent. locks. LockSupport.park(LockSupport.java:175)
    at java.til. concurrent. locks.AbstractQueuedSynchronizer$Condition0bject.await (AbstractQueuedSynchronizer. java: 2039)
    at java.til. concurrent.LinkedBlockingQueue.take (LinkedBlockingQueue. java:442)
    at java.til. concurrent. ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
    at java.til. concurrent. ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java. lang.Thread.run (Thread.java: 748)

所有的消费线程都是进入 WAITING 状态, 失去了消费能力, 连续抽查了几台生产实例, 都是相同的情况。

这种全局的等待, 初步怀疑是全局锁导致的, 比如数据库等 (实际上, 这时应该是在 FullGC, 全部线程都阻塞了)。
本着先解决问题, 再定位原因。所以先预发起了另一个版本实例, 然后切换流量过去。

同样通过 jstack 查看, 消费线程都是 Runnable 状态, 默认是解决了, 等消息消费完就行了, 回到旧版本, 定位原因。

3.2.2 加大生产实例, 提高消费能力

20:50, 运维群各种反馈 MQ 堆积。
通过监控平台查看, 发现 MQ 堆积加重 (应该是正常业务的消息 + 重试的消息)

通过 jstack 查看线程有的在 Runable, 有的 WAITING, 而不是一开始的 WAITING。
所以先将应用是实例增加, 从 10 个增加到了 16 个, 提高一些消费能力, 看看能否降下来。

3.2.3 增加堆内存, 防止应用 GC overhead limit exceeded

通过观察监控平台, 堆积的情况没有好转。
这时告警平台不断的提示应用有异常, 进入到实例的日志, 发现

[xxxx-xx-xx 21:05:53.978][ConsumeMessageThread_19][ERROR][com.xxx.qqq.mq.service.TodoSubscriber:49][ConsumeMessageThread_19raceId] TodoSubscriber:onMessage:org.springframework.data.redis.serializer.SerializationException: Cannot serialize; nested exception is org.springframework.core.serializer.support.SerializationFailedException: Failed to serialize object using DefaultSerializer; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
	at org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:93)
	at org.springframework.data.redis.core.AbstractOperations.rawValue(AbstractOperations.java:117)
	at org.springframework.data.redis.core.DefaultValueOperations.set(DefaultValueOperations.java:168)
	at com.xxx.qqq.mq.service.impl.ProtoCacheServiceImpl.addTodoIds(ProtoCacheServiceImpl.kt:154)
	...
Caused by: org.springframework.core.serializer.support.SerializationFailedException: Failed to serialize object using DefaultSerializer; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded
	at org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:68)
	at org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:35)
	at org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:91)
	... 23 more
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded