消息队列-kafka脑裂问题
本文介绍了我在公司内遇到的kafka实际难题以及是如何解决的，以此记录一下。
`什么是脑裂？
脑裂是分布式系统高可用（High Avaliablity）场景下容易出现的问题。我们知道，在分布式系统中常常用多副本来解决容错性问题，多副本中会选举出一个Leader负责与客户端进行交互，但由于各种原因分布式集群中会出现脑裂的情况
zookeeper脑裂问题 - tantexian的博客空间 - OSCHINAmy.oschina.net/tantexian/blog/2876309
这篇文章给出了详细的解释。这里再简单概述以下，基本上是由于网络或者其他原因导致master出现假死，这时候会触发系统进行新的master选举，此时系统中就会出现两个master，产生一系列问题。
什么是kafka controller？
kafka controller相当于整个kafka集群的master，负责topic的创建、删除、以及partition的状态机转换，broker的上线、下线等。那么controller是如何选举出来的呢？它是通过抢占方式在zookeeper上注册临时节点来实现的，第一个注册成功的即为controller。关键之处来了，由于zookeeper临时节点的有效性是通过session来判断的，若在session timeout时间内，controller所在的broker断掉，则会触发新的controller选举。
kafka Controller脑裂带来什么问题？
什么服务会受到影响？Topic元数据信息新增或者改变时，会在对应的zookeeper path下添加或者更新数据，而controller都对这个路径进行了watch，当有数据变化时，controller会进行partition、replica state的转化，进而对所有存活的broker发送LeaderISR请求，这时第二个controller会发生错误，进而元数据更新失败，对应的partition无法变为online状态。
- 创建新的topic成功，客户端往topic内写数据时；
- 给某个topic增加分区，zk显示已有增加的分区信息，但是依旧报找不到新增加的分区信息错误
什么服务不会受到影响？
现有的topic读写不受影响，因为读写时获取partition的元数据信息在任意broker上都可以获取到
什么情况下会导致这个问题？如何解决？
- Controller进行Full GC停顿时间太长超过zookeeper session timeout 出现假死
- Controller 所在broker网络出现故障
解决方案1：在zk上找到最新的controller所在的broker， 将其余几个过期的controller重启，找其余controller办法，通过上图jmx指标获取value=1的 broker
添加图片注释，不超过 140 字（可选）
解决方案2:
升级新版本，新版本解决了这个BUG