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

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

256600

背景现象

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

现象一:

623511C0-F60F-4741-920E-00BCDFA93C0C.png

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

EC0E0444-98F1-4634-B481-EC2D0787A4F4.png


 简要说明一下上述两个图
 

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

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

BC4F88FF-9434-4D78-B135-5A614ADDB521.png

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

1FD77887-C6CD-4DB9-BD9A-70BDEB613B44.png

原因分析
 

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

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


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

1CBBB36D-463B-4ABE-A870-40B3EBF2038C.png

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

2、调用下游服务响应延迟高:这个我上述图二已经有详细描述了

解决方案


调整Client 消费线程数,从原来的5调整到20个线程

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

💥看到这里的你,如果对于我写的内容很感兴趣,有任何疑问,欢迎在下面留言📥,会第一次时间给大家解答,谢谢!

 

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

D炸天的Redis,该如何监控?
本文重点讲述Redis的哪些metrics需要重要监控(篇幅有限,不能涵盖所有),以及我们如何获取这些metrics数据。从而确保对我们应用至关重要的Redis是否健康运行,以及当出现问题时能及时通知
Redis进阶:深入解读阿里云Redis开发规范(修订版)
Key命名设计:可读性、可管理性、简介性规范建议使用冒号即:进行分割拼接,因为很多Redis客户端是根据冒号分类的。比如有几个Key:apps:app:1、apps:app:2和apps:app:3。
构建企业级业务高可用的延时消息中台
业务场景剖析公司业务系统(比如:电商系统)中有大量涉及定时任务的业务场景,例如:实现买卖双方在线沟通的IM系统,为了确保接收方能够收到消息,服务端一般都会有重试策略,即服务端在消息发出的一段时间内,如
Redis client链接池配置不当引起的频繁full gc
现象笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age =2 的对象还真
记一次线上请求偶尔变慢的排查
前言最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过
空中楼阁之纸上谈兵 redis中hash的思考
思考点:------与jdk中hashmap的区别?(提示从添加元素、扩容这两个行为开始分析)为什么使用这种添加方式?为什么这样扩容?扩容的时机?具体标准是?是否还有缩容呢?若有,则时机和标准呢?hg
RedLock: 看完这篇文章后请不要有任何疑惑了
后台经常会有小伙伴咨询RedLock相关问题,笔者在此再来一篇文章剖析一下RedLock,希望此文能解决你对它所有的疑惑和误解。 为什么需要RedLock这一点很好理解,因为普通的分布式锁算法在加锁时
Redis OOM(out of memory)内存占用过高,故障分析过程。
本文正在参加「Java应用线上问题排查经验/工具分享」活动先点赞再看,养成好习惯背景全国最大的短信平台,大家都用过我们的产品。数据量比较大,最多时候一天近7亿条短信。简单介绍一下redis(我们平台用
0
0