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