KRaft面试思路引导

Kafka实在2.8之后就用KRaft进行集群管理了

Conroller负责选举Leader,同时Controller管理集群元数据状态信息,并将元数据信息同步给各个分区的Leader

和Zookeeper管理一样,会选出一个Broker作为Controller去管理整个集群,但是元数据存储不同了

Zookeeper是树形结构存储,为每个ZNode,每个分区有一个ZNode节点

而KRaft就是用日志存储的,Controller中会有个单分区的内部主题 _cluster_metadata存储元数据信息


Zookeeper本身的限制

Zookeeper写操作串行的限制

Zookeeper 的写操作(如分区选举、Controller 变更)是串行的,成为性能瓶颈,尤其在集群规模大时(如数十万分区)

在 ZK 模式 下,Kafka 的元数据(如分区选举、Controller 变更)依赖 ZooKeeper 存储,而 ZooKeeper 的所有写操作都是串行化的

ZooKeeper 集群有一个 Leader 节点(通过 ZAB 协议选举),所有写请求(无论来自哪个 Kafka Broker)都必须由 Leader 处理

Zookeeper单线程回调机制

事件触发 :

当节点发生变化(如 Broker 宕机,节点被删除),ZooKeeper 会生成一个 Watcher 事件 (如 NodeDeleted)

事件派发 :

ZooKeeper 服务端将事件放入单线程队列 ,由 单线程的 EventThread 依次执行回调(通知 Kafka Controller)

Zookeeper模型存储限制

Zookeeper 的存储模型限制了 Kafka 分区数量的扩展(如单 Zookeeper 集群难以支撑百万级分区)

Zookeeper使用树形结构存储元数据,百万个分区就有百万个ZNode节点,会导致内存占用激增

并且Zookeeper必须将所有ZNode加载到内存中,容易OOM+停顿

Zookeeper的单Controller机制

Zookeeper是单Controller机制,Controller选举的时候没有备用方案而是所有的Broker都去参与选举,选举过程不稳定还会有脑裂问题

KRaft 中有类似备用 Controller 的概念,有一个主Controller和多个Controller副本。在 KRaft 协议中,会有一个 Leader 作为主要的 Controller 负责管理和协调工作,同时存在多个 Follower 节点可以在 Leader 出现故障时快速切换成为新的 Leader(即新的 Controller)


KRaft对比Zookeeper的优势

存储方式+并发+Controller副本机制(Kraft的性能更好)

1.日志管理元数据,支持并发写,解决Zookeeper单线程写限制。因为Kafka的Offeset的频繁更新会有大量的写操作,Zookeeper单线程写性能不足

2.Kafka将offset和元数据分开存储,而zookeeper将offset和元数据都存到ZNode中,offset写频繁,元数据读频繁,两者分开存储会提高系统效率

3.Kafka支持执行命令后并发通知,解决Zookeeper单线程回调机制

4.KRaft是一种选举算法,不像Zookeeper有本身系统的限制

KRaft中将Kafka工作产生的日志都放到了一个单分区的内部主题 _cluster_metadata

Zookeeper使用树形结构存储元数据,百万个分区就有百万个ZNode节点,会导致内存占用激增。并且Zookeeper必须将所有ZNode加载到内存中,容易OOM+停顿

5.KRaft是单主Controller+多个Controller副本,在Controller宕机后能迅速用副本恢复。而Zookeeper是单Controller机制,选举过程很慢,同时还会有脑裂问题的出现

6.Follower同步Leader机制从原本的ISR机制变成了少数服从多数投票机制


Raft和KRaft的不同

Raft算法使用推模式同步

KRaft算法使用拉模式同步

新角色Observer

因为KRaft是节点是主动去拉取日志,所以对比之前的Leader和Follower角色,还多出了一个Observer角色去Leader中去拉取日志

其实这个角色只是一个抽象的模型,实际上就是Broker去拉取日志而已


KRaft为什么不用推模式?KRaft和Raft的优缺点

Raft因为是推模式,所以节点同步的实时性会更好,但是没有考虑Follower的性能+消费能力,可能会造成压力

KRaft因为是拉模式,所以节点实时性不强,但是Follower会根据自身情况控制消费速度,减轻自身压力防止系统资源浪费

但是实际上,KRaft因为是适配Kafka的,Kafka本身日志同步就是拉模式,所以KRaft也改成拉模式了


相关推荐
微尘hjx7 小时前
【ByteTrack 04】多轨迹算法ByteTrack改进点
算法·yolo·目标检测·目标跟踪·bytetrack·ultralytics·车跟踪
云和数据.ChenGuang7 小时前
Python 重写(Override)深度解析:从 MRO 到 super() 的完整机制
java·开发语言·人工智能·python·langchain·1024程序员节
摇滚侠7 小时前
《On Java 中文版 基础卷》阅读笔记 实现隐藏 12
java·数据库·笔记
Cosolar10 小时前
不收费、不加水印、数据归你:我做了个开源的在线简历工具
后端·面试·前端框架
starzy199010 小时前
Kafka源码深度剖析:消息有异常是如何处理的
大数据·kafka
silvamux_10 小时前
10款模型写种草笔记:可发布性、返工来源与成本数据缺口复盘
java·数据库·笔记
行走的陀螺仪10 小时前
【转型攻略】2026 年,后端 / 全栈工程师转 AI Agent 方向:能力地图、按周学习路线与面试要点
人工智能·面试·职场和发展
步行cgn11 小时前
StringHttpMessageConverter 详解:Spring MVC 中字符串读写的默认转换器
java·spring·mvc
摇滚侠11 小时前
《On Java 中文版 基础卷》阅读笔记 实现隐藏 11
java·笔记·python