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

本文转载自微信公众号「Java极客技术」，作者鸭血粉丝。转载本文请联系Java极客技术公众号。 

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

背景

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

报错内容如下：

[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. 事后复盘，回顾整个处理过程，哪些地方可以优化，哪些地方做的不对浪费了时间，下次再遇到这种情况是否可以快速解决。生产上时间就是金钱，事故多一分钟就多一分钟风险，有点时候一分钟可以改变很多东西。

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

总结