写点什么

kafka Controller 作用

  • 2022 年 1 月 15 日
  • 本文字数:1624 字

    阅读完需:约 5 分钟

原创:石头哥 @大数据架构师  2021 年 8 月 2 日   微信:nevian668899

概念和作用


1、Kafka Controller 是 Kakfa 服务端 Broker 的概念,Broker 集群有多台,但只有一台 Broker 可以扮演控制器的角色;

2、某台 Broker 一旦成为 Controller,它用于以下权力:完成对集群成员管理、主题维护和分区的管理,如集群 broker 信息、Topic 维护、Partition 维护、分区选举 ISR、同步元信息给其他 Broker 等。

为何要引入 Controller 角色?

我们暂且不深入分析他的作用,先思考下为何要引入控制器角色。前面也简单提到,它是控制器,完成对集群 Broker、主题和分区等管理工作,而且只有一个 leader 对外提供服务,是否我们可以猜测元数据的管理工作集中化管理和维护,再分布式同步给所有控制器,这样有利于维护元数据的一致性和稳定性。进一步,我们回溯 Kafka 的历史版本,以前版本的架构是严重依赖 zk 的 watch 机制,这里不再赘述 watch 监听的原理,不清楚可以自行查找资料熟悉下。先看下 Kafka 旧版本的元数据维护架构图:

图 1:老版本的 Kafka 元数据同步机制

历史版本的实现架构如上图所示,对于分区和副本的状态的管理依赖于 zookeeper 的 Watcher 和队列:每一个 broker 都会在 zookeeper 注册 Watcher,所以 zookeeper 就会出现大量的 Watcher, 如果宕机的 broker 上的 partition 比较多,会造成多个 Watcher 触发,造成集群内大规模调整;每一个 replica 都要去再次 zookeeper 上注册监视器,当集群规模很大的时候,zookeeper 负担很重。所以严重依赖 zk 实现元数据的协调同步,这样做的弊端有以下几点:


  1. 当 Kafka 集群规模很大的时候,zookeeper 负担很重。因为所有 Broker 的所有主题分区都要与 zk 建立连接,分区上下线和 Broker 的宕机或重新启动,会触发多个 watch,给 zk 带来大量的写压力;

  2. zk 压力大,容易引起网络风暴,不利于 Kafka 元数据的稳定性;

  3. 这种设计容易出现脑裂(zk 集群的 brain-split 原理,请自行补充知识)和羊群效应

架构优化

Kafka 官方团队也意识到严重依赖 zk 带来的弊端,于是对架构做了优化和调整。核心思想:

  • 降低对 zk 的依赖程度,减少 zk 压力

  • 元数据的控制和管理由中心化节点维护;

  • 异步化同步元数据给集群所有节点,并做好同步的容错处理。


基于控制器概念的新版架构如下图所示:


图 2:基于控制器的元数据维护架构图

Kafka 集群中多个 broker,每个 broker 启动时都会创建 KafkaController 对象,但只有一个会被选举为 Controller leader,其他节点为 Controller Follower。

控制器的启动初始化

1、当 broker 启动的时候,都会创建 KafkaController 对象;

2、每个节点上的 KafkaController 会在指定的 zookeeper 路径下创建临时节点,只有第一个成功创建的节点的 KafkaController 才可以成为 leader,其余的都是 follower;

3、集群中只能有一个 leader 对外提供服务;

控制器运行时对元信息的处理流程

只有 Controller leader 向 zk 注册 watch 并监听元数据的变化,其他 broker 不用监听 zookeeper 的状态变化。大概流程:

  1. 用户通过命令或控制台执行集群的管理操作,比如:扩锁容 Broker 集群、创建/删除 Topic、扩/缩容 Partition;

  2. 第一步会触发集群在 zk 对应路径上变更节点信息,比如/brokers/topics;

  3. Controller leader 收到 watch 的监听推送消息,通过监听接口收到对应的变更信息,比如主题信息、分区信息、集群 Broker 信息等;

  4. Controller leader 根据推送的事件类型,做不同的逻辑处理。比如:Broker 加入或删除的相关流程、Topic 新增或删除的相关流程、 分区重分配引起的重分配相关流程 、Partition 扩展的相关流程(即分区 leader 选举和 ISR 同步);

  5. Controller leader 同步元信息至集群的 Controller Follower 节点。

控制器 Leader 如何 Failover

如果控制器 Leader 所在 broker 退出、崩溃或与 ZK 会话失效则 ZK 会删除/controller 内该子节点,各个 broker 的监视器收到这种变化后,每个 broker 开始竞争直到有一个竞争成为新的控制器 Leader,并向/controller 注册子节点,以及向/controller_EPOCH 注册子节点。此时,新一轮的 controller 周期开始运行,新的 leader 节点继续肩负起监听元数据变化、处理元信息并同步给集群的任务。

发布于: 刚刚阅读数: 3
用户头像

如切如磋;如琢如磨 2019.10.21 加入

还未添加个人简介

评论

发布
暂无评论
kafka Controller作用