kafka专题：kafka的总控制器Controller、消费者重分配策略等核心设计原理详解

1. Kafka核心总控制器Controller

        在kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。由于zookeeper中存储了kafka的元信息，所以总控制器Controller也被存储在zookeeper的 /controller目录下：

具备控制器身份的broker需要比其他普通的broker多一份职责，具体细节如下：

1. 监听broker相关的变化。
   （1）为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener，用来处理broker增减的变化。
2. 监听topic相关的变化。
   （1）为Zookeeper中的/brokers/topics节点添加TopicChangeListener，用来处理topic增减的变化；
   （2）为Zookeeper中的/admin/delete_topics节点添加TopicDeletionListener，用来处理删除topic的动作。
3. 监听topic下Partition的变化
   （1）对于所有topic 所对应的Zookeeper中的/brokers/topics/[topic]节点添加PartitionModificationsListener，用来监听topic中的分区分配变化
4. 选举Partition分区的Leader。
   （1）当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本
5. 更新集群的元数据信息，同步到其他普通的broker节点中

1.1 核心总控制器Controller的Leader选举

        核心总控制器有这么多功能，那么它是如何被选举来的呢？在kafka集群启动的时候，会自动选举一台broker作为controller来管理整个集群，选举的过程是集群中每个broker都会尝试在zookeeper上创建一个 /controller 临时节点，zookeeper会保证有且仅有一个broker能创建成功（因为所有命令在zk内部是顺序执行的），这个broker 就会成为集群的总控器controller。

        当这个controller角色的broker宕机了，此时zookeeper中 /controller 临时节点会消失，同时zookeeper目录 /brokers/ids中记录的节点数据也会随着消失一个

        又因为集群里其他broker会一直监听这个临时节点 /controller节点 和 /brokers/ids节点，发现临时节点消失了，就竞争再次创建临时节点，就是我们上面说的选举机制，zookeeper又会保证有一个broker成为新的controller。

1.2 Partition副本选举Leader机制

        topic下有多个partition分区，每个partition分区又有多个副本，partition副本之间会选举出一个Leader用来负责当前分区的所有读写请求，其他副本负责备份容灾，那么分区副本Leader是如何被选举的呢？

        首先，分区Leader的选举是由总控制器Controller完成的。controller会从ISR列表中选择第一个分区作为分区Leader，ISR列表中的节点代表已经同步完该Partition数据的节点，同步完的broker最先放进ISR列表，位于ISR列表的第一个位置，所以会选择第一个节点，因为它可能是同步数据最多的副本！（ISR列表详解）

注意两种设置：

1. 参数unclean.leader.election.enable=false：默认，只能在ISR列表中选举分区Leader，如果ISR无值，就会阻塞。如上图。
2. 参数unclean.leader.election.enable=true：先在ISR列表中选举分区Leader，如果ISR列表里所有副本都挂了的时候可以在ISR列表以外的副本Replicas中选leader。这种设置，可以提高可用性，但是选出的新leader有可能数据少很多。

        如果分区leader所在的broker挂了，该节点会在zookeeper的节点/brokers/ids中消失，因为总控制器controller又监听着/brokers/ids目录的数据变化，所以也会及时感知到，并执行上面的分区Leader选举过程！

分区副本进入ISR列表有两个条件：

1. 必须能与zookeeper保持会话以及跟leader副本网络连通
2. 副本能复制leader上的所有写操作，并且不能落后太多。(与leader副本同步滞后的副本，是由 replica.lag.time.max.ms 配置决定的，超过这个时间都没有跟leader同步过的一次的副本会被移出ISR列表)

2. 消费者消费偏移量offset记录机制

        offset是消费偏移量，记录着消息的消费位置。每个consumer会定期将自己消费分区的offset提交给kafka内部的__consumer_offsets_xxx。内容为key-value形式的！kafka会定期清理topic里的消息，最后就保留最新的那条数据

1. key：consumerGroupId+topic+分区号
2. value：当前offset的值

通过如下公式可以选出consumer消费的offset要提交到__consumer_offsets的哪个分区

公式：hash(consumerGroupId) % __consumer_offsets主题的分区数

        因为__consumer_offsets可能会接收高并发的请求，kafka默认给其分配50个分区(可以通过offsets.topic.num.partitions设置)，这样可以通过加机器的方式抗大并发。

3. 消费者rebalance机制

        消费者rebalance机制就是消费者的重平衡机制。就是说如果消费组里的消费者数量有变化或消费的分区数有变化，kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了，此时会自动把分配给他的分区交给其他的消费者，如果他又重启了，那么又会把一些分区重新交还给他。

如下情况可能会触发消费者rebalance：

1. 消费组里的consumer增加或减少了
2. 动态给topic增加了分区
3. 消费组订阅了更多的topic

注意：

1. rebalance只针对subscribe这种不指定分区消费的情况，如果通过assign这种消费方式指定了分区，kafka不会进行rebanlance。
2. rebalance过程中，消费者无法从kafka消费消息，这对kafka的TPS会有影响，如果kafka集群内节点较多，比如数百个，那重平衡可能会耗时极多，所以应尽量避免在系统高峰期的重平衡发生。

消费者Rebalance分区分配策略：

1. range(官方默认)
   比如有0-9这10个分区，a、b、c三个消费者
   n＝分区数／消费者数量 = 10/3 = 3
   m＝分区数 % 消费者数量 = 10%3 = 1
   前 n个消费者分配 n+1 个分区，后面的消费者分配 n 个分区 range分配策略会做以下分配
   a：0、1、2、3
   b：4、5、6
   c：7、8、9
2. round-robin
   轮询分配，round-robin分配策略会做以下分配
   a：0、1、2、9
   b：3、4、5
   c：6、7、8
   注意和range分配策略的区别
3. sticky
   初始时分配策略与round-robin类似，但是在rebalance的时候，比如消费者c挂掉，那么只会重分配消费者c的分区，原有的已分配好的分区不会被打乱，而range 和 round-robin则会打乱所有已分配好的分区，这也是sticky的优点，他能减少reblance的时间，增加kafka的TPS!

消费者reblance全过程

        kafka为了减轻自己的压力，把reblance策略的制定任务交给各个消费组，自身不承担压力，要么给zookeeper，要么给消费者(好奸诈呀！)，这也是它性能高的原因之一

过程如下：

1. 由消费组中的消费者选出一个kafka集群节点作为组长，这个broker组长并不是总控制器Controller，他只负责接受并下发分区方案。注意：每一个消费组选择的broker组长可能不一样
   选择依据是：consumer消费的offset要提交到__consumer_offsets的哪个分区，这个分区leader对应的broker就是这个组长
2. 由这个broker组长在消费者集群中选一个作为消费者这边的“组长”，消费者组长负责制定分区方案。
   选择依据是：那个消费者最先和borker的组长建立连接，这个消费者就是消费者这边的“组长”！
3. 消费者组长设置好分区方案，并把方案发送给broker组长。
   由于消费者组中的消费者无法建立通信，所以需要把分区方案发给broker组长，并由他来通知其他的消费者！
4. broker组长通过其他消费者的心跳通信，下发分区方案给其他消费者

4. HW高水位机制

在了解HW高水位机制之前，先要知道producer向Topic下的分区中发布消息的过程！

4.1 生产者producer发消息过程

1. 写入方式
        producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。

        producer 发送消息到 broker 时，如果指定了 patition，则直接使用发送到分区；如果未指定patition，会根据分区算法选择将其存储到哪一个 partition。

2. 写入流程

1. producer 先从 zookeeper 的 “/brokers/…/state” 节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后 向leader 发送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK

4.2 消息发送与HW

        HW俗称高水位，consumer最多只能消费到HW所在的位置。HW机制要求：对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。如下图所示：

如果没有HW高水位，那么消息的可靠性将无法得到保障，具体如下图所示，如果出现leader宕机，那么消息还未同步，便已丢失！

5. zookeeper节点与Kafka元数据关系图