记一次生产 Kafka 挂掉的那几分钟

Hello,大家好,我是阿粉,作为一个后端工程师不经历几次生产事故怎么能成长!阿粉工作几年来,大大小小,重要不重要的事故也经历了不少,有损失几十万的,有对业务毫无影响但是不应该发生的,每一次事故都是一次成长,而且从每次的事故中阿粉都能学到很多东西,不单单是解决问题,更重要的是对线上有了更深的敬意!

背景

上周下午两点多的时候,阿粉正在悠闲的敲着代码,零星的看到几条报警机器人发的 Kafka 集群负载高的报警信息,看到是负载高而已就没怎么在意,更何况这个点还不是高峰期,想着过会应该就好了。谁知道过了一会不见好,而且还越来越多,赶紧拿着电脑跑到运维处去看看是什么情况。不看不知道,一看吓一跳,集群中某个 topic 的数据写不进去了!但是生产者端没有任何报错,看上去还在正常写入,集群却在报错,而且消费端也没有消费到数据。

报错内容如下:

1
2
[2020-10-28 15:12:32,923] ERROR [KafkaApi-2] Error when handling request {replica_id=-1,max_wait_time=500,min_bytes=1,topics=[{topic=xxxx,partitions=[{partition=0,fetch_offset=409292609,max_bytes=1048576}]}]} (kafka.server.KafkaApis)
java.lang.IllegalArgumentException: Magic v1 does not support record headers

看到这程序肯定是没有问题的,因为最近没有升级,尝试重启集群和服务但是问题依旧存在, 这个时候为了保证业务的稳定,考虑到这个 topic 可能有问题,决定删掉这个 topic 然后自动重新创建,虽然会丢失部分数据,但是并不会产生大的影响,但是如果服务长时间写不进去数据将会更严重。

处理

好在我们的服务是基于 Nacos 做的服务配置与发现,修改 Nacos 里面的 Kafka 集群配置临时切换到另一套集群里面,然后重启服务,因为我们没有开启 Nacos 配置自动生效。切换过后数据正常写入到新的集群,然后手动将旧集群中的有错误的 topic 删掉,删掉出错的 topic 过后集群变得一切正常,没有出现上面的错误。既然没有错误了,通过修改 Nacos 将集群配置切换回来,一切也正常。

整个事故从发现到解决差不多经历了二十几分钟,但是因为刚开始忽略了报警信息,导致差不多影响了一个小时的数据,好在这个数据对线上业务本身不会出现大的影响,而且通过切换到临时集群以及日志数据,还可以找回来一部分。

事后复盘了一下,主要总结了以下几点,分享给大家,共勉:

  1. 敬畏线上!线上环境报警信息第一时间查看确保没问题!
  2. 保证线上数据安全,及时备份和切换临时环境(这块一定要做好动态配置,别慢慢的还要走发布流程,推荐使用 Nacos);
  3. 事后复盘,回顾整个处理过程,哪些地方可以优化,哪些地方做的不对浪费了时间,下次再遇到这种情况是否可以快速解决。生产上时间就是金钱,事故多一分钟就多一分钟风险,有点时候一分钟可以改变很多东西。

上面的错误网上大部分说的都是版本冲突,但是阿粉这边并没有升级过,所以这个问题就比较玄学了。

总结

遇到问题不可怕,没有人能保证服务不出问题,我们要做的就是在遇到问题的时候沉着泠静,想到应对策略,在最短的时间的想到最好的解决方案,减少风险和损失才是最重要的。另外我们一定懂得敬畏线上,特别的那些非常重要的业务,不然一旦出现问题后果都是很严重的。

写在最后

最后邀请你加入我们的知识星球,这里有 1800+ 优秀的人与你一起进步,如果你是小白那你是稳赚了,很多业内经验和干活分享给你;如果你是大佬,那可以进来我们一起交流分享你的经验,说不定日后我们还可以有合作,给你的人生多一个可能。

Java Geek Tech wechat
欢迎订阅 Java 极客技术,这里分享关于 Java 的一切。