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

---