面试题:Kafka中Controller的作用是什么?选举流程是怎样的?以及如何避免脑裂问题?

题目来源

网上冲浪:还不懂分布系统,速看深度剖析Kafka Controller选举过程

在查找关于Kafka单机分区的上限以及分区多了会有怎样的问题的时候,发现了这个比较有趣的问题,就记录了下来。

一般所有的分布式系统,都会涉及到这个问题:脑裂、以及如何避免脑裂问题。

题目描述

  • Kafka中Controller的作用是什么?
  • Kafka中Controller的选举流程是什么?
  • Kafka脑裂是什么?
  • Kafka如何避免脑裂问题?

题目答案

  • Kafka中Controller中的作用是什么?

    -- 管理partition的ISR列表:当Follower副本无法及时跟随Leader副本时,Controller会将其从ISR列表中移除。

    -- 分区重平衡:当添加或者删除Broker节点时,Controller负责对Partition的分布进行重平衡,以确保数据的均匀分布。

    -- 当集群中有一个副本的leader挂掉了,controller需要在集群中选举出一个新的leader,选举的规则是从isr集合中最左边获得。

    -- 当集群中新增或者减少broker,controller将该信息同步给其他broker。

    -- 当集群中有分区新增或者减少,controller将该信息同步给其他broker。

    -- 存储集群元数据

    Controller保存了集群中最全的元数据信息,并通过发送请求同步到其他Broker上面

    -- 从我参考文章中的信息来看,Controller节点不负责存储数据。但是好像之前看bilibili视频的时候,Controller节点又是存储数据的。重新思考之后,Controller可能是一个子进程,由Broker进程在竞选Controller成功后创建,可以跟Broker处于同一个节点上面。

  • Kafka集群的Controller选举过程是怎样的?

    -- 注册Controller节点

    Kafka集群刚上线时,每个Broker启动时会向zookeeper尝试注册一个/controller节点,因为同一时刻只能存在一个/controller节点,所以只有一个Broker可以成功创建节点并成为Controller,获得的序号最小的那个broker将会作为集群中的controller。

    -- 监听Controller节点

    所有非Controller的Broker都会在Zookeeper中对/controller路径设置一个Watcher事件,这样当Controller节点发生变化时(例如Controller失效),所有非Controller就会收到一个Watcher事件。

    -- 选举新的Controller

    当某个Broker接收到Controller节点变化的通知后,它会再次尝试在Zookeeper中的/controller路径下创建临时节点。与Kafka集群刚上线时的"注册Controller节点"类似,只有一个Broker能够成功在Zookeeper中创建/controller临时节点,并成为新的Controller。新的Controller会在选举成功后接管集群元数据的管理工作。

    -- 更新集群元数据

    新Controller在选举成功后,需要更新集群元数据,包括分区状态、副本状态等。同时,新控制器会通知所有相关的Broker更新他们的元数据信息。这样,集群中所有的Broker都能够知道新Controller的身份,并进行协同工作。

    -- 备注

    临时节点的特点是在创建它的客户端(即Broker节点)断开连接时,它会自动被Zookeeper节点删除。这种机制保证了只有一个Broker节点能够成为Controller,以避免多个控制器同时对集群元数据进行操作引发问题。

  • Kafka脑裂是什么?

    脑裂问题是分布式系统中经常出现的现象,Kafka脑裂问题是由于网络或其他原因(比如Full GC)导致多个Broker认为自己是Controller,从而导致元数据不一致和分区状态混乱的问题。

  • Kafka脑裂是怎么产生的?Kafka和Zookeeper是如何避免脑裂问题?

    -- 假设有三个Broker,a、b、c,其中a是Controller。此时的epoch number是1(Kafka是通过epoch number(纪元编号)解决脑裂问题)。

    -- 现在a因为full gc时间过程,导致与zookeeper的会话超时了。zookeeper就会删除/controller节点,并通知b和c竞选Controller节点。

    -- b和c 参加竞选,假设b成为了新的Controller,将epoch number的值设置为2。之后b就会向c同步新的元数据信息,通c更新元数据信息。

    -- a结束Full GC后,继续向b和c同步数据,b和c发现epoch number小于自己当前保存的epoch number的值,就会拒绝a的管理,并通知a当前最新的epoch number是2了,a就会知道自己已经不是Controller了,最后与b重新建立连接,并从b同步最新的元数据。这样就解决了脑裂的问题。

参考

题目来源:还不懂分布系统,速看深度剖析Kafka Controller选举过程

相关推荐
kruptos2 小时前
分布式系统怎么“选主“?Raft 共识一次讲清
开发语言·分布式·php·共识算法
小智老师PMP4 小时前
2026深度解析|PMP第八版与NPDP核心侧重点本质区别(管理类证书怎么选)
开发语言·分布式·算法·职场和发展·产品经理
会周易的程序员6 小时前
5Draft(五帝)测试报告
服务器·c++·分布式·raft·共识算法·共识·算力服务器
想要打 Acm 的小周同学呀12 小时前
Kafka消息队列出现挤压如何解决?
分布式·kafka
stark张宇16 小时前
分布式事务最全图解(6种方案):从强一致的2PC到最终对账,彻底搞懂数据一致性
分布式·后端
会周易的程序员16 小时前
5Draft使用说明书
服务器·c++·分布式·raft·共识
富士康质检员张全蛋16 小时前
Kafka实战 自定义分区器 几种常见的分区器
分布式·kafka
努力努力再努力wz17 小时前
【Redis入门系列】:从 RESP 协议到 redis-plus-plus:Redis 客户端编程与 C++ 接口设计
开发语言·数据库·c++·redis·分布式·缓存·架构
starzy199017 小时前
Flink基础之Flink批流数据读取处理案例剖析:从文件到 Kafka 的完整代码
大数据·flink·kafka
青禾83717 小时前
Git 与 SVN 完全指南:从集中式到分布式的版本控制
分布式·git·svn