记一次kafka 消息堆积以及解决过程

本文讲述了在实现业务需求时遇到的Kafka消息消费问题,最初的设计导致了下游接口压力过大和消息堆积。通过引入Guava的RateLimiter进行限流以及使用线程池异步发送HTTP请求,但仍然出现消息消费缓慢的情况。经过分析和调整,发现是单条消费的策略影响了效率,改为批量拉取后成功解决了消息堆积问题,实现了平稳的消息消费。
摘要由CSDN通过智能技术生成

在做业务需求的中,由于对kafka 不够熟悉,导致出现了事故,通过这篇博客与大家分享一下在做整个需求,以及解决问题的过程。做个复盘总结,以免今后再犯错。

一、需求:订阅kafka 队列消息。将数据调用外部http接口同步过去。

接到这需求,第一时间反应很简单,无非要做两件事情。1、订阅消费指定kafka topic 消息 2、调用外部http 接口。
以下图为初始方案伪代码:
在这里插入图片描述
仔细琢磨,发现这样写有问题。老铁们有没看出有什么问题?

问题:1、直接消费kafka 消息调用外部接口,没做任何限流控制,当流量大的时候,很容易打垮下游接口。
2、http 接口请求响应需要时间。假如直接同步单线程处理,主线程需要等待响应后,才会ack 。这样当kafka 消息量大的时候必然会出现堆积。

方案优化伪代码如下:1、限流控制采用的是谷歌guava 框架 RateLimiter。 2、使用线程数异步发送请求。
在这里插入图片描述

本以为这方案非常完美。上线灰度时候瞬间打脸。kafka 消息消费太慢出现堆积。

在这里插入图片描述

猜想:为什么会出现堆积呢?发http 请求用线程池,难道是线程数不够?任务堆积?
于是将核心线程数调整到200. 最大线程数400. 验证依旧消费不过来堆积。
看来不是线程数的问题?那是什么问题呢?研究许久没有答案,果断求助小组大佬。

大佬果然是大佬,粗略看了下后就知道什么问题。巴拉巴拉~~

原来是consumer 采用来单条记录消费方式,每次拉取一条,消费后再拉。
这里应该改成批量拉取的方式即可解决。

在这里插入图片描述
fetch-min-bytes

改成批量后,消息可正常消费没有堆积。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

86码记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值