Kafka【四】Controller的选举机制

【1】控制器:Controller

Kafka是分布式消息传输系统,所以存在多个Broker服务节点,但是它的软件架构采用的是分布式系统中比较常见的主从(Master - Slave)架构,也就是说需要从多个Broker中找到一个用于管理整个Kafka集群的Master节点,这个节点,我们就称之为Controller。

它是Apache Kafka的核心组件非常重要。它的主要作用是在Apache Zookeeper的帮助下管理和协调控制整个Kafka集群。

如果在运行过程中,Controller节点出现了故障,那么Kafka会依托于ZooKeeper软件选举其他的节点作为新的Controller,让Kafka集群实现高可用。

Kafka集群中Controller的基本功能:

  • Broker管理
    • 监听 /brokers/ids节点相关的变化:
    • Broker数量增加或减少的变化
    • Broker对应的数据变化
  • Topic管理
    • 新增:监听 /brokers/topics节点相关的变化
    • 修改:监听 /brokers/topics节点相关的变化
    • 删除:监听 /admin/delete_topics节点相关的变化
  • Partation管理
    • 监听 /admin/reassign_partitions节点相关的变化
    • 监听 /isr_change_notification节点相关的变化
    • 监听 /preferred_replica_election节点相关的变化
  • 数据服务
    • 启动分区状态机和副本状态机

【2】选举机制

① 如何实现Kafka的节点选举

Kafka集群中含有多个服务节点,而分布式系统中经典的主从(Master - Slave)架构就要求从多个服务节点中找一个节点作为集群管理Master,Kafka集群中的这个Master,我们称之为集群控制器Controller

如果此时Controller节点出现故障,它就不能再管理集群功能,那么其他的Slave节点该如何是好呢?

如果从剩余的2个Slave节点中选一个节点出来作为新的集群控制器是不是一个不错的方案,我们将这个选择的过程称之为:选举(elect)。Kafka是依赖于ZooKeeper软件实现Broker节点选举功能。

ZooKeeper如何实现Kafka的节点选举呢?这就要说到我们用到ZooKeeper的3个功能:

  • 一个是在ZooKeeper软件中创建节点Node,创建一个Node时,我们会设定这个节点是持久化创建,还是临时创建。所谓的持久化创建,就是Node一旦创建后会一直存在,而临时创建,是根据当前的客户端连接创建的临时节点Node,一旦客户端连接断开,那么这个临时节点Node也会被自动删除,所以这样的节点称之为临时节点。
  • ZooKeeper节点是不允许有重复的,所以多个客户端创建同一个节点,只能有一个创建成功。
  • 另外一个是客户端可以在ZooKeeper的节点上增加监听器,用于监听节点的状态变化,一旦监听的节点状态发生变化,那么监听器就会触发响应,实现特定监听功能。

Kafka是如何利用ZooKeeper实现Controller节点的选举的:

  1. 第一次启动Kafka集群时,会同时启动多个Broker节点,每一个Broker节点就会连接ZooKeeper,并尝试创建一个临时节点 /controller
  2. 因为ZooKeeper中一个节点不允许重复创建,所以多个Broker节点,最终只能有一个Broker节点可以创建成功,那么这个创建成功的Broker节点就会自动作为Kafka集群控制器节点,用于管理整个Kafka集群。
  3. 没有选举成功的其他Slave节点会创建Node监听器,用于监听 /controller节点的状态变化。
  4. 一旦Controller节点出现故障或挂掉了,那么对应的ZooKeeper客户端连接就会中断。ZooKeeper中的 /controller 节点就会自动被删除,而其他的那些Slave节点因为增加了监听器,所以当监听到 /controller 节点被删除后,就会马上向ZooKeeper发出创建 /controller 节点的请求,一旦创建成功,那么该Broker就变成了新的Controller节点了。


总结来讲就是broker节点进行抢占,谁先抢占到谁就是Controller,其他则监听该节点。如果Controller挂掉,其他节点继续抢占去成为Controller。

脑裂现象

有一种特殊的情况,就是Controller节点并没有宕掉,而是因为网络的抖动,不稳定,导致和ZooKeeper之间的会话超时。那么此时,整个Kafka集群就会认为之前的Controller已经下线(退出)从而选举出新的Controller,而之前的Controller的网络又恢复了,以为自己还是Controller了,继续管理整个集群。

那么此时,整个Kafka集群就有两个controller进行管理,那么其他的broker就懵了,不知道听谁的了,这种情况,我们称之为脑裂现象。

为了解决这个问题,Kafka通过一个任期(epoch:纪元)的概念来解决。也就是说,每一个Broker当选Controller时,会告诉当前Broker是第几任Controller。一旦重新选举时,这个任期会自动增1。那么不同任期的Controller的epoch值是不同的,那么旧的controller一旦发现集群中有新任controller的时候,那么它就会完成退出操作(清空缓存,中断和broker的连接,并重新加载最新的缓存),让自己重新变成一个普通的Broker。

相关推荐
明达智控技术1 小时前
MR30分布式IO在全自动中药煎药机中的应用
分布式·物联网·自动化
jakeswang2 小时前
细说分布式ID
分布式
失散133 小时前
分布式专题——1.2 Redis7核心数据结构
java·数据结构·redis·分布式·架构
王中阳Go4 小时前
头一次见问这么多kafka的问题
分布式·kafka
鼠鼠我捏,要死了捏4 小时前
Kafka Exactly-Once 语义深度解析与性能优化实践指南
kafka·exactly-once·performance-optimization
boonya5 小时前
Kafka核心原理与常见面试问题解析
分布式·面试·kafka
KIDAKN6 小时前
RabbitMQ 重试机制 和 TTL
分布式·rabbitmq
lifallen6 小时前
Kafka 内存池MemoryPool 设计
数据结构·kafka·apache
JAVA学习通6 小时前
【RabbitMQ】----初识 RabbitMQ
分布式·rabbitmq
项目題供诗11 小时前
Hadoop(八)
大数据·hadoop·分布式