当前位置: 首页 > news >正文

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也改成拉模式了


相关文章:

  • 【JavaEE】计算机的工作原理
  • [SpringMVC]请求响应参数传递
  • 系统架构师2025年论文《论基于UML的需求分析》
  • SF6气体回收装置参数特点分享
  • 内网穿透快解析免费开放硬件集成SDK
  • STM32——新建工程并使用寄存器以及库函数进行点灯
  • 目标检测中的损失函数(二) | BIoU RIoU α-IoU
  • redis队列 和 秒杀应用
  • 高保真动态项目管理图表集
  • (七)深入了解AVFoundation-采集:采集系统架构与 AVCaptureSession 全面梳理
  • 【解决方法】关于解决QGC地面站4.4.3中文BUG,无法标注航点的问题
  • 【大语言模型DeepSeek+ChatGPT+python】最新AI-Python机器学习与深度学习技术在植被参数反演中的核心技术应用
  • 效率就是竞争力
  • 算法题(130):激光炸弹
  • 每日一题(小白)回溯篇7
  • Vue中如何优雅地阻止特定标签的移除并恢复其原始位置
  • 剑指Offer(数据结构与算法面试题精讲)C++版——day17
  • [c语言日寄]免费文档生成器——Doxygen在c语言程序中的使用
  • 特伦斯便携钢琴V20有哪些优势
  • [预备知识]1. 线性代数基础
  • 上海市政府常务会议部署多措并举促进消费,提高居民收入,减轻家庭负担
  • 海港主场不敌蓉城遭遇联赛首败,好消息是武磊终于复出了
  • 纪念沈渭滨︱志于道而游曳于士和氓间的晚年沈先生
  • 徐州沛县一村委会因无资质处理固废,被环保部门罚款19万元
  • 江西修水警方:一民房内发生刑案,犯罪嫌疑人已被抓获
  • 北京航空航天大学强基计划今年新增4个招生培养方向