星星博客 »  > 

kafka陡增和坠崖问题分析

场景:某个业务量激增,是原来的3倍以上,造成了消息的积压,TOPIC有两个消费分组,都扩容消费端的机器,之后分别出现了陡增和坠崖两种问题,所以这里记录一下,这里的broker你就任务是某个消费分组的积压数

一、坠崖图片分析在这里插入图片描述

在这里插入图片描述
原因:使用flink消费,但是消费端的auto.offset.reset没有设置,说明采用是默认的latest,关于这个可以看Kafka auto.offset.reset值详解
当时采取的策略是启动新的flink任务,双流消费,原来消费任务不停,消费策略还是latest,等到下午四点我看没有消息积压,就把新的任务停掉,旧的任务扩容重启,全程没有保存savepoint (因为数据量大,savepoint可能失败),后面就出现坠崖问题了,
之后找消息队列技术支持查看了一下原因,是因为消费位点重置了,让我把auto.offset.reset改成earliest ,这样不会丢数据,顶多重复消费,

二、陡增图片分析

在这里插入图片描述
原因:这个分组是别人把数据写入ES,写入ES达到瓶颈,这里如果写入失败会重试,但是不会给消息队列发送ack,而且别人消费端配置的消费策略是earliest,由于没有找到新的消费位点,那只能从上一次的提交的重新消费

三、总结

1、消费端的auto.offset.reset 不同的策略会引起不同的问题,

  1. latest会引起坠崖问题
  2. earliest会引起陡增问题

2、对于不同的场景要有不同的消费位点策略,

  1. 新创建的消费分组auto.offset.reset=latest,这样可以不消费在创建此消费分组之前的数据
  2. 非新创建的消费分组,采用auto.offset.reset=earliest 顶多重复消费,不会出现丢失数据的问题

3、个人的思考

flink任务对于日志或者需要把数据存储下去的,不能丢失数据的,应该在停止时savepoint,因为原来的flink消费端auto.offset.reset没有配置,这样就要全部依靠flink的savepoint,如果在saveponit失败的情况下,就会丢失数据。现在已经重新修改,改成自定义配置策略,双重保险,保证最少消费一次

而对于告警等需要实时最新的,积压的旧数据要不要都行,可以配置成auto.offset.reset=latest

相关文章