性能文章>公司内部一次关于kafka消息队列消费积压故障复盘分享>

公司内部一次关于kafka消息队列消费积压故障复盘分享转载

2月前
271316

背景现象

1.20晚上8点业务线开始切换LBS相关流量,在之后的1个小时时间内,积压量呈上升趋势,一路到达50W左右,第二天的图没贴出具体是50W数字,以下是第一天晚上的贴图部分。

现象一:

 

现象二:

当时现场图后来就找不回来了,凭印象说明了一下数字。

 

 

简要说明一下上述两个图

 

图一:其实很明显,明显看出,消费者消费速度明显跟不上生产者的发送速度,导致出现积压情况。

图二:图二就有点意思了,因为上游通过Kafka消息队列发送消息给我,topic对应的分区数是20个。由于我的应用消费组内消费者实例是17个,所以从宏观上分析,势必会有3个消费者会承担多消费一个分区的情况。这个倒也容易理解。但为什么会积压这么多。个人分析了一下,主要还是跟消费者本身消费的消费业务逻辑有关。因为我的消费业务逻辑是要调用下游一个LBS地图服务的,通过设备上报的WIFE内容经过公司LBS平台接口换取设备当前地理位置坐标信息,但这个地理位置服务,R通过命令:thread-n3-i 500 : 列出500毫秒内最忙的3个线程栈,其中就有两个属于调用地理位置服务的线程。

 

 

通过命令:thread-n3-i 500(阿里开源诊断工具Arthas:thread命令) : 列出500毫秒内最忙的3个线程栈,其中就有两个属于调用地理位置服务的线程。

 

 

原因分析

分析了具体原因具体是两个层面

  1. HMS-Client(公司自己封装的调用消息队列的SDK)层面

根据图一,其实想说明一点的是,在本应用调用下游服务延迟高的场景下,从图一的现象看出,消费者的利用率其实不高,topic有20个分片,消费组17个容器实例,14个实例基本对应一个分区,有三个实例对应2个分区,导致资源利用率其实很低,而我们其实是希望在下游服务相应慢的情况下,最好有更多线程参与去消费任务,增加吞吐率,提高处理效率(IO密集型应用,尽量提高处理线程数)。而我们的处理线程数是5个,即最高5个线程会去处理任务,其他都会等待进入

 

 

这两个参数,当下应用设置了5个,但我的机器配置是8核16G,参数设置是不合理的。这个参数主要是从其他项目中拷贝过来,没过多关注他,在高并发应用场景下,想不多却成为瓶颈,特别是消费线程内如果涉及到RT很高,QPS上不去的下游服务,就有讲究了。

  1. 调用下游服务响应延迟高

这个我上述图二已经有详细描述了

解决方案

  • 调整Client 消费线程数,从原来的5调整到20个线程
  • 增加KAFKA的分片数,临时方案,目前已经让中间件从原来的分片数20调整到60,积压下降的明显。因为消费组内的消费者实例一个承担了基本3-4个分区消息数。

作者:星巴克男孩

博客:https://www.cnblogs.com/StarbucksBoy/ 

文章来源:博客园

原文链接:https://www.cnblogs.com/StarbucksBoy/p/15836125.html

分类:
标签:
请先登录,再评论

👍

2月前

为你推荐

大数据中台之Kafka,到底好在哪里?
Hello,大家好,今天给大家分享一个大数据里面很火的技术——Kafka,Kafka 是一个分布式的消息系统,其高性能在圈内很出名。本人阅读过多个大数据生态的开源技术的源码,个人感觉 Kafka 的源
跟Kafka学技术系列之时间轮
kafka的延迟队列使用时间轮实现,能够支持大量任务的高效触发,但是在kafka延迟队列实现方案里还是看到了delayQueue的影子,使用delayQueue是对时间轮里面的bucket放入延迟队列,以此来推动时间轮滚动,但是基于将插入和删除操作则放入时间轮中,将这些操作的时间复杂度都降为O(1)
什么?搞不定Kafka重复消费?
今天我们聊一个话题,如何保证 Kafka 消息不重复消费?在使用 Kafka 的时候一般都会设置重试的次数,但是因为网络的一些原因,设置了重试就有可能导致有些消息重复发送了(当然导致消息重复也有可能是其他原因),那么怎么解决消息重复这个问题呢?
Kafka的生产者优秀架构设计
前言 Kafka 是一个高吞吐量的分布式的发布订阅消息系统,在全世界都很流行,在大数据项目里面使用尤其频繁。笔者看过多个大数据开源产品的源码,感觉 Kafka 的源码是其中质量比较上乘的一个,这得益于
Kafka 顺序消费线程模型的实践与优化
各类消息中间件对顺序消息实现的做法是将具有顺序性的一类消息发往相同的主题分区中,只需要将这类消息设置相同的 Key 即可,而 Kafka 会在任意时刻保证一个消费组同时只能有一个消费者监听消费,因此可
kill -9 导致 Kakfa 重启失败的惨痛经历!
背景在 2 月10 号下午大概 1 点半左右,收到用户方反馈,发现日志 kafka 集群 A 主题 的 34 分区选举不了 leader,导致某些消息发送到该分区时,会报如下 no leader 的错
《吃透 MQ 系列》之 Kafka 存储选型的奥秘
谈到 Kafka 的存储设计,了解不多的同学,可能会有这样的疑惑:为什么 Kafka 会采用 Logging(日志文件)这种很原始的方式来存储消息,而没考虑用数据库或者 KV 来做存储?
《吃透 MQ 系列》之核心基础篇
上一篇文章谈到了《吃透系列》的讲解思路:先找到每个技术栈最本质的东西,然后以此为出发点,逐渐延伸出其他核心知识。所以,整个系列侧重于思考力的训练,不仅仅是讲清楚 What,而是更关注 Why 和 How,以帮助大家构建出牢固的知识体系。回到正文,这是技术系列《吃透 MQ》的开篇。