生产故障｜Kafka消息发送延迟达到几十秒的罪魁祸首居然是....

1、故障现象

笔者在双十一期间负责的kafka集群的响应时间飙升到了10～30s，严重影响消息的写入。

通过对日志分析发现存在大面积分区Leader选举，__consumer_offsets主题的分区也大量进行分区Leader选举，从而导致消息发送几乎停止，大量消费组触发重平衡，整个集群接近瘫痪，最终确定了根因：Broker节点与Zookeeper会话超时，触发大量分区重新选举。

本文借此故障，与大家一起剖析一下Zookeeper在Kafka中起了哪些作用，以及确定“罪魁祸首”的过程，希望给大家排查问题能带来一定的启发。

2、Zookeeper在Kafka中具有举足轻重的作用

在正式进入故障分析之前，我们首先介绍一下Zookeeper在kafka架构设计中所起的角色。

核心理念：kafka的设计者对待Zookeeper的使用是非常谨慎的，即需要依靠Zookeeper进行控制器选举，Broker节点故障实时发现，但又尽量降低对Zookeeper的依赖。

基于Zookeeper进行的程序开发，我们一般可以通过查看zookeeper中的目录布局，可以窥探出哪些功能是依靠Zookeeper完成，Kafka在Zookeeper中的存储目录结构如下图所示：

上述各个节点，其背后都关联着Kafka一个核心工作机制，大家可以顺藤摸瓜进行探究，本文需要重点介绍/brokers这个目录的布局与作用，目录详情如下：

• /controller Kafka控制器的信息，Kafka控制器的选举依靠zookeeper。

• /brokers/ids/{id} 在持久节点/brokers/ids下创建众多的临时节点，每一个节点，表示一个Broker节点，节点的内容存储了Broker的基本信息，例如端口、版本、监听地址等。

• /brokers/topics/{topic}