Kafka学习笔记(九)—Kafka控制器

Kafka控制器

在Kafka集群中会有一个或者多个broker,其中有一个broker会被选举为控制器(Kafka Controller),它负责管理整个集群中所有分区和副本的状态

Kafka控制器内部组件

Kafka学习笔记(九)—Kafka控制器_第1张图片

可以看出控制制器内部还是有些复杂的,后续需要仔细研究下

Kafka控制器职责

  • 监听partition相关的变化。为Zookeeper中的/admin/reassign_partitions节点注册PartitionReassignmentListener,用来处理分区重分配的动作

  • 监听topic相关的变化。Zookeeper中的/brokers/topics节点添加TopicChangeListener,用来处理topic增减的变化

  • 监听broker相关的变化。为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener,用来处理broker增减的变化。当某个分区的leader副本出现故障时,由控制器负责为该分区选举新的leader副本

  • 从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理

  • 启动并管理分区状态机和副本状态机

  • 更新集群的元数据信息

  • 参数auto.leader.rebalance.enable设置为true,则还会开启一个名为“auto-leader-rebalance-task”的定时任务来负责维护分区的优先副本的均衡

Kafka控制器选举

kafka每个broker启动的时候,都会实例化一个KafkaController,并将broker的id注册到zookeeper,集群在启动过程中,通过选举机制选举出其中一个broker作为leader

三种情况触发控制器选举:

  • 集群启动
  • 控制器所在代理发生故障
  • zookeeper心跳感知,控制器与自己的session过期

选举过程:

  1. 每个broker都从zookeeper获取/controller临时节点信息,查询是否存在leader
  2. 不存在leader节点信息,返回-1
  3. 每个broker均会触发向临时节点/controller写入自己的信息,最先写入的就会成为leader
  4. 后来的broker发现已经存在leader节点信息,会抛出会抛出ZkNodeExistsException异常,写入失败
  5. controller_epoch节点,存储了leader的变更次数,初始值为1,每次选举leader都会将该值+1

控制器在选举成功之后会读取Zookeeper中各个节点的数据来初始化上下文信息ControllerContext,此对象存储了控制器工作需要的所有上下文信息,包括存活的代理、所有主题及分区分配方案、每个分区的AR、leader、ISR等信息。

比如为某个topic增加了若干个分区,控制器在负责创建这些分区的同时也要更新上下文信息,并且也需要将这些变更信息同步到其他普通的broker节点中

监听器触发的事件,还是定时任务触发的事件,亦或者是其他事件(比如ControlledShutdown)都会读取或者更新控制器中的上下文信息,这样就会涉及到多线程间的同步,如果单纯的使用锁机制来实现,那么整体的性能也会大打折扣。针对这一现象,Kafka的控制器使用单线程基于事件队列的模型,将每个事件都做一层封装,然后按照事件发生的先后顺序暂存到LinkedBlockingQueue中,然后使用一个专用的线程(ControllerEventThread)按照FIFO(First Input First Output, 先入先出)的原则顺序处理各个事件,这样可以不需要锁机制就可以在多线程间维护线程安全

你可能感兴趣的:(Kafka)