之前被问到Kafka的脑裂问题，知道“脑裂”，知道“Kafka controller”，合并在一起，还真是很难一时想清楚，所以决定借机温故而知新，进而深入了解下Kafka在实践中可能出现的问题。

1. 脑裂

脑裂是分布式系统高可用（High Avaliablity）场景下容易出现的问题。我们知道，在分布式系统中常常用多副本来解决容错性问题，多副本中会选举出一个Leader负责与客户端进行交互，但由于各种原因分布式集群中会出现脑裂的情况。
这里简单概述以下，基本上是由于网络或者其他原因导致master出现假死，这时候会触发系统进行新的master选举，此时系统中就会出现两个master，产生一系列问题。

2. kafka broker controller

kafka controller相当于整个kafka集群的master，负责:

topic 的创建和更新

partition的状态维护

partition中leader的选举，ISR列表的维护；

3. 如何选举controller

Zookeeper负责维护和协调broker，负责Broker Controller的选举。

Kafka通过抢占在zookeeper上注册临时节点来实现，第一个注册成功的即为controller。

由于zookeeper临时节点的有效性是通过session来判断的，若在session timeout时间内，controller所在的broker断掉，则会触发新的controller选举。

4. 带来的问题

4.1 受影响的服务

当Topic元数据信息新增或者改变时，controller会进行partition、replica state的转化，进而对所有存活的broker发送LeaderISR请求，这时第二个controller会发生错误，进而元数据更新失败，对应的partition无法变为online状态。

  1. 创建新的topic成功，客户端往topic内写数据时；
  2. 给某个topic增加分区，zk显示已有增加的分区信息，但是依旧报找不到新增加的分区信息错误

4.2 不受影响的服务

现有的topic读写不受影响，因为读写时获取partition的元数据信息在任意broker上都可以获取到

5. 产生原因

  • Controller进行Full GC停顿时间太长超过zookeeper session timeout 出现假死
  • Controller所在broker网络出现故障

6. 解决

在zk上找到最新的controller所在的broker， 将其余几个过期的controller重启。