Kafka中产生数据积压的原因以及解决方案

这篇具有很好参考价值的文章主要介绍了Kafka中产生数据积压的原因以及解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Kafka中产生数据积压的原因以及解决方案

1、kafka中数据积压的原因

kafka作为消息队列,其中数据积压也是经常遇到的问题之一。

我们都知道,数据积压的直接原因,一定是系统中的某个部分出现了性能问题,来不及处理上游发送的数据,才会导致数据积压。

那么我们就需要分析在使用kafka时,如何通过优化代码以及参数配置来最大程度的避免数据积压来对业务中的影响。

2、kafka中数据积压的解决方案

	首先我们在上面分析得出,是由于上游生产者producer发送数据过快,以及下游消费者consumer拉取数据过慢,实质上就是,生产者生产数据速度>>消费者消费数据速度。那么就可以把问题定位到生产者producer以及消费者consumer这两方面上。

1、生产者producer:吞吐量
	可以通过修改以下参数配置提提升生产者的吞吐量:
	
	1)batch.memory修改缓冲区大小
	
	设置发送消息的缓冲区,默认值是33554432,就是32MB

	如果发送消息出去的速度小于写入消息进去的速度,就会导致缓冲区写满,此时生产消息就会阻塞住,所以说这里就应该多做一些压测,尽可能保证说这块缓冲区不会被写满导致生产行为被阻塞住。
	
	2)compression.type压缩格式
	
	默认是none,不压缩,但是也可以使用lz4压缩,效率还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大producer端的cpu开销。
	
	3)batch.size批次大小
	
	设置merge batch合并批次消息的大小
	
	如果 batch 批次太小,会导致频繁网络请求,吞吐量下降;

	如果batch批次太大,会导致一条消息需要等待很久才能被发送出去,而且会让内存缓冲区有很大压力,过多数据缓冲在内存里。

	默认值是:16384,就是16kb,也就是一个batch批次满了16kb就发送出去,一般在实际生产环境,这个batch批次的值可以增大一些来提升吞吐量,可以自己压测一下。
	
	4)linger.ms等待时长
	
	这个值默认是0,意思就是消息必须立即被发送,但是这是不对的。

	一般设置一个100毫秒之类的,这样的话就是说,这个消息被发送出去后进入一个batch批次,如果100毫秒内,这个batch批次满了16kb,自然就会发送出去。

	但是如果100毫秒内,batch没满,那么也必须把消息发送出去了,不能让消息的发送延迟时间太长,也避免给内存造成过大的一个压力。

2、消费者consum	:扩容,扩分区;增加consumer

	1)提升消费者组中的消费者数以及Topic中的分区数,让二者相等,假设设置为3个分区 = 3CPU。
	
	2)提高消费者拉取数据的能力,比如Flume每次拉取的数据可以由1000条改为3000条、Spark中将限流的参数增大、Flink中保证数据的处理效率等。

3、数据积压分析V2.0

	日常系统正常运转的时候,没有积压或者只有少量积压很快就消费掉了,但是某一个时刻,突然就开始积压消息并且积压持续上涨。

	这种情况下需要你在短时间内找到消息积压的原因,迅速解决问题才不至于影响业务。

	导致突然积压的原因肯定是多种多样的,不同的系统、不同的情况有不同的原因,不能一概而论。

	但是,我们排查消息积压原因,是有一些相对固定而且比较有效的方法的。

	能导致积压突然增加,最粗粒度的原因,只有两种:

	1、要么是发送变快了,2、要么是消费变慢了。

	大部分消息队列都内置了监控的功能,只要通过监控数据,很容易确定是哪种原因。

	如果是单位时间发送的消息增多,比如说是赶上大促或者抢购,短时间内不太可能优化消费端的代码来提升消费性能,唯一的方法是通过扩容消费端的实例数来提升总体的消费能力。

	如果短时间内没有足够的服务器资源进行扩容,没办法的办法是,将系统降级,通过关闭一些不重要的业务,减少发送方发送的数据量,最低限度让系统还能正常运转,服务一些重要业务。

	还有一种不太常见的情况,你通过监控发现,无论是发送消息的速度还是消费消息的速度和原来都没什么变化,这时候你需要检查一下你的消费端,是不是消费失败导致的一条消息反复消费这种情况比较多,这种情况也会拖慢整个系统的消费速度。

	如果监控到消费变慢了,你需要检查你的消费实例,分析一下是什么原因导致消费变慢。

	优先检查一下日志是否有大量的消费错误,如果没有错误的话,可以通过打印堆栈信息,看一下你的消费线程是不是卡在什么地方不动了,比如触发了死锁或者卡在等待某些资源上了。

文章来源地址https://www.toymoban.com/news/detail-512178.html

到了这里,关于Kafka中产生数据积压的原因以及解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kafka消息积压的原因和处理的方法

            Kafka作为目前主流的消息中间件,被广泛的应用在了生产环境中。消息积压是日常生产经常遇到的问题,下面我们来展开了说一下。 上游数据激增(生产侧原因):由于业务系统,访问量徒增,如热点事件,热门活动等,导致了大量的数据涌入业务系统,有可能导致

    2024年02月11日
    浏览(29)
  • Kafka顺序消费以及消息积压问题

    什么场景下需要顺序消费? 比如说:订单有很多状态,比如:下单(未支付)、完成(已支付)、撤销等,不可能下单的消息都没读取到,就先读取支付或撤销的消息吧,要保证消息顺序消费 如何保证顺序消费? kafka的topic是无序的,但是一个topic包含多个partition, 每个pa

    2024年04月29日
    浏览(30)
  • Kafka消息发送失败的常见原因及解决方案

    1.1、网络故障 网络故障是Kafka消息发送失败的最常见原因之一。当网络出现故障时,Kafka就无法将消息发送到目标主题或分区。 解决方法: - 检查网络连接是否正常。 - 增加Kafka生产者的重试次数和超时时间。 1.2、分区副本不可用 如果Kafka生产者将消息发送到一个不可用的分

    2024年02月03日
    浏览(41)
  • kafka乱序消费可能的原因和解决方案

    Kafka乱序消费可能的原因有以下几个: 分区顺序:Kafka中的消息按照分区进行存储和分发,每个分区内的消息是有序的,但不同分区之间的消息顺序是无法保证的。如果消费者在多个分区上进行并行消费,并且不处理消息的顺序,那么消费顺序可能会混乱。 消费者并发度:当

    2024年01月25日
    浏览(26)
  • Kafka rebalance 的几种原因与解决方案

    网上有很多文章讲述 Kafka rebalance 的原理,本文是列举常见的几种 rebalance 场景。 rebalance 期间,当前 consumer group 的所有 consumer 都要暂停消费,开销较大。因此应该尽量减少 rebalance ,而 relalance 的原因通常是 consumer 数量变化,常见的几种情况如下: 如果一个 consumer 刚启动,

    2024年02月01日
    浏览(41)
  • Kafka消息丢失:原因、解决方案和零丢失的配置

    在使用Apache Kafka作为分布式消息系统时,消息丢失是一种常见的问题。消息丢失可能会导致数据不一致或功能故障,因此对于许多应用程序来说是不可接受的。本文将介绍Kafka消息丢失的原因、解决方案以及如何配置Kafka以实现零丢失。 Kafka消息丢失可能由多种原因引起。下面

    2024年02月13日
    浏览(23)
  • #详细介绍!!! 造成死锁的原因以及解决方案!

    本篇主要是介绍什么是死锁,已经死锁产生的原因,如果避免死锁。根据上述的几个问题让我们来阅读本篇文章。 目录 1. 什么是死锁 2. 形成死锁的原因(四个必要条件) 3. 如果有效避免死锁   死锁主要是锁彼此间进行锁等待,导致每个锁都不能正常执行的情况 例子1:多个

    2023年04月20日
    浏览(27)
  • 浪涌电流Inrush Current产生原因以及解决方案

    1、对Inrush Current电流的直观感受 当电灯在电路中工作时,如果突然启动马达或者变压器时,会出现电灯暗一下,此时电灯出现暗的情况就是因为马达或者变压器启动时,在电路中产生较大Inrush Current,具体分析可以参考下图: 当马达刚开始上电时,转子是静止的,处于正要启

    2024年02月03日
    浏览(28)
  • Redis中的缓存穿透、雪崩、击穿的原因以及解决方案

    是指用户查询数据,在数据库没有,自然在缓存中也不会有。这样就导致用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,然后返回空(相当于进行了两次无用的查询)。这样请求就绕过缓存直接查数据库,这也是经常提的缓存命中率问题。 我们可以简单的

    2024年02月12日
    浏览(28)
  • redis中缓存雪崩,缓存穿透,缓存击穿的原因以及解决方案

    在redis中,新,旧数据交替时候,旧数据进行了删除,新数据没有更新过来,造成在高并发环境下,大量请求查询redis没有数据,直接查询mysql,造成mysql的压力骤增,给mysql造成极大的压力,造成一连串的后续异常反应。 1.大多数系统设计者 考虑用加锁 (最多的解决方案)或

    2024年02月15日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包