背景
上周下午两点多的时候，阿粉正在悠闲的敲着代码，零星的看到几条报警机器人发的 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 将集群配置切换回来，一切也正常。
整个事故从发现到解决差不多经历了二十几分钟，但是因为刚开始忽略了报警信息，导致差不多影响了一个小时的数据，好在这个数据对线上业务本身不会出现大的影响，而且通过切换到临时集群以及日志数据，还可以找回来一部分。
事后复盘了一下，主要总结了以下几点，分享给大家，共勉：
- 敬畏线上！线上环境报警信息第一时间查看确保没问题！
- 保证线上数据安全，及时备份和切换临时环境（这块一定要做好动态配置，别慢慢的还要走发布流程，推荐使用 Nacos）；
- 事后复盘，回顾整个处理过程，哪些地方可以优化，哪些地方做的不对浪费了时间，下次再遇到这种情况是否可以快速解决。生产上时间就是金钱，事故多一分钟就多一分钟风险，有点时候一分钟可以改变很多东西。
上面的错误网上大部分说的都是版本冲突，但是阿粉这边并没有升级过，所以这个问题就比较玄学了。
总结
遇到问题不可怕，没有人能保证服务不出问题，我们要做的就是在遇到问题的时候沉着泠静，想到应对策略，在最短的时间的想到最好的解决方案，减少风险和损失才是最重要的。另外我们一定懂得敬畏线上，特别的那些非常重要的业务，不然一旦出现问题后果都是很严重的。
最后邀请你加入我们的知识星球，这里有 1800+ 优秀的人与你一起进步，如果你是小白那你是稳赚了，很多业内经验和干货分享给你；如果你是大佬，那可以进来我们一起交流分享你的经验，说不定日后我们还可以有合作，给你的人生多一个可能。
