《Kafka异常重启后无法消费》由会员分享，可在线阅读，更多相关《Kafka异常重启后无法消费（3页珍藏版）》请在金锄头文库上搜索。
1、Kafka异常重启后无法消费事故起因2018.10.13日KafkaH无法了动问题，安稳了一天，结果第二天晚上又出现了新的问题，发现有些程序无法正常消费Kafka了。这个问题在网上找了一下，发现有类似的经历，都是Kafka进程异常挂掉之后，起来无法消费的问题，但是试了一下，发现每次事故还是都有它的独特之处，所以这里专门记录一下。调查过程基本环境信息：软件版本：使用的Kakfa的版本是1.1.0版本，之前因为从082升级过一次，所以消息格式仍然是沿用支持082的消息格式。集群：6个节点brokerid分别是：0,1,2,3,4,5节点配置：内存：64G硬盘：4T*12网卡：万兆其中0,1两个节点
2、的Kafka出现过异常挂掉。出现问题的时候，也不是所有的程序都无法消费，而是部分节点无法消费了，查了一下机器的负载情况，0号节点负载非常高，达到11了，磁盘利用率非常高，而其他的几个节点的负载都非常低。这里我们简单重温一下消费的原理：同一个组的消费者会加入到一起，向Coordinator请求加入消费组Coordinator会向每个消费者分配消费的分区。那么Coordinator是怎么确定的呢？一般一个消费者启动后，会随机想一个节点请求去获取它的Coordinator所在节点。获取Coordinator所在的节点的原理与我们的消费组的消费偏移量信息是存储_consumer_offsets对应的分
3、区上。所以最终定位到Kafka是如何选择_consumer_offsets这个topic的分区来存储对应的偏移量。以消费组名为ttt为例来说明：inthashCode=Math.abs(ttt.hashCode();intpartition=hashCode%50;先计算group的hashCode,再除以分区数(50),可以得到partition的值为：44。再通过kafka-topic.sh命令查看该partition的Ieader在哪个节点，那么就可以确定tttt这个消费组的Coordinator落在哪个节点了。在消费过程中，消费不了的原因是说对应的Coordinator无效，日志如下:
4、null)isu2018-10-1421:20:28,860INFOConsumerclientld=consumer-1,groupld=console-consumer-28334Discoveredgroupcoordinatorwxoddc2B9(783647ra2018-10-1421:20:28,860INFOConsumerclientId=consumer-1,groupId=console-consumer-28334Groupcoordinatorwxoddc2nn1:9092(id:2147483647rack2018-10-1421:20:28,962INFOConsu
5、merclientId=consumer-1,groupId=console-consumer-28334Discoveredgroupcoordinatorwxoddc2nn1:9092(id:2147483647ra2018-10-1421:20:28,962INFOConsumerclientId=consumer-1,groupId=console-consumer-28334(Re-)joinihHHnals.Absnull)isl2018-10-1421:20:29,065INFOConsumerclientId=consumer-1,groupId=console-consume
6、r-28334Discoveredgroupcoordinatorwxoddc2nn1:9092(id:2147483647ra日志中的wx0ddc2nn1主机就是我们的0号节点，客户端无法消费的原因是发现Coordinator在0号节点，但是0号节点认为该Coordinator无效,刚开始怀疑是负载较大，我们查询了一下_consumer_offsets这个topic的Ieader居然全部是0号节点，而且只有两个副本，另外一个副本在1号节点上。第一次尝试4把一些分区的leader调整到1号节点，发现也无法正常消费。基本说明了一个问题，消费问题与负载不相关，但是可能与这两个节点异常启动过有关。解
7、决问题的过程对consumer_offsets进行整体的分区调整，调整为3个分区，并且把leader和副本分区均匀分配在6个节点上，发出了调整指令左右，有部分节点的leader调整到其他节点了。我们按照前面的消费组所处_consumer_offsets的分区的计算算法，找到合适的group名，譬如：tttt，它的partition为44,发的leader落在了2号节点，然后，我们启动命令行消费者：hadoopwxoddc2dn4:/kafka_2.11-1.1.0$bin/kafka-console-consumer.sh-zookeeperzk01-topictest-max-HHHm!-g
8、roiapp:businessid:4,source:java_sdk_1.3.3,ports:;18901;,ips:;127.0.0.1;,clientname:guess.mobile_guess,srvid:86787,ti|H|5|U5|timestanapp:businessid:4,source:java_sdk_1.3.3,ports:;18901;,ips:;127.0.0.1;,clientname:guess.mobile_guess,srvid:86787,ti|H|5|H5|timestan发现就能够正常消费了，所以怀疑是0，1两个节点的问题，因为这两个节点异常启动过
9、。等待_consumer_offsets重新调整的过程很长，有一些超级大的分区，我们把一些超过3天以上的数据删除了，加快了一点速度，但是调整完毕后，仍然有一部分分区的leader是在0，1上，使用落在这些分区的消费组消费，仍然不行。第二轮调整再次把_consumer_offsets进行了分区调整，把所有的分区都迁移到其他2，3,4，5节点上。在这次调整后，使用所有的消费组名，都能够消费了。总结整个故障的解决时间比较长，而且中间做了各种尝试，所以对部分业务也造成了影响，好在我们kafka集群和数据都是双机房备份的,做了切换。现在Kafka的复杂性越来越高，不在代码层面去研究，碰到问题都很难解决，
10、像这次的问题，我们虽然没有在去基于代码层面进行研究，但是最终结果只是暂时让我们的集群恢复正常了。而0，1号节点无法消费的原因，我们还没有找到。后续会继续对这个问题进行更进一步的调研，如果有更进一步的结论，会继续完善该文档。后记经过了上次的调整以后，0和1这两个节点已经不再存储任何_consumer_offsets这个topic的分区了，我尝试把一个分区重新放回让它们做leader，结果发现也能消费了。从这个现象看起来，初步怀疑是节点的异常重启造成了_consumer_offsets的部分分区数据异常，但是经过数据的迁移之后，由于有相关的数据，再次迁移回来，数据是全新的，所以不再有异常了，总得来说，还是该版本的kafka有隐藏的bug。【20181022】最近分析发现，Kafka进程启动后一直在加载对应的consumer_offsets分区的数据，由于对应的logclean逻辑因为某个原因出对应的_consumer_offsets的清理一直没有进行，积累了大量的历史数据，最多的分区达到了2T，系统一直加载_consumer_(对应的_consumer_offsets无法正常工作，从而提示Coordinatorinvalid。解决方案很简单，删除consumer_offsets的历史文件，再启动Kafka进程即可。
