搭建 KRaft 模式的 Kafka 集群，看这一篇就够了.....

前言

我在上一篇文章研究 Debezium 采集 MySQL 的时候，使用 docker 搭建单点 Kafka 遇到了一点问题，可能是因为之前生产上用的是版本很老的 Kafka，依赖的都是 Zookeeper。 所以在面对 kRaft 的时候，显得我略微生疏，换句话说就是根本没有了解过，所以今天就来学习一下 Kafka 的 KRaft 模式。

KRaft

在我实习期间自学大数据的时候，想要搭建一个 Kafka 集群必须先需要搭建 Zookeeper 集群， Kafka 集群的元数据就会存储在 zookeeper 里。在工作期间，曾多次参与到停掉生产重建 Kafka 集群的工作，在重建之前，就要去 zookeeper 里面删除掉这些关于 Kafka 的目录，例如 topic 信息、消费组信息等。包括 Kafka 的 Controller 的选择也要依靠 zookeeper。

在 Kafka 3.3.1 版本，KRaft 被标记为生产就绪版本，也就是意味着可以引入生产。

如果你经常下载 Kafka 的安装包，就知道在 config 目录下的 server.properties 是利用 ZooKeeper 搭建 Kafka 的配置文件，在后来的版本中，config 下就多了一个 kraft 目录，其中的 server.prorperties 就是 KRaft 模式的文件。

配置

在这里，我们不对两种模式的配置差异做过多解释，大家如果想要了解这两个配置文件做了哪些改动，可以自行查看官网文档：Differences Between KRaft mode and ZooKeeper mode。

在这里，我们只讲两种模式下的一些必选配置，首先是ZK模式，除了 broker.id 就是 zookeeper.connect，我们指定 zk 集群的地址，启动服务就可以了。

而对于 KRaft 模式，必需的配置就多了很多。

1. process.roles

在 Kraft 模式下，集群中必须有两个角色：controller 和 broker。一个节点可以担任其中的一个角色或者直接担任两个角色，在之前搭建单点的时候，我们使用的 server.properties 中就担任的两个角色。

如图所示，kraft 目录下有三个配置文件，每个配置文件的 process.roles 都是不同的，想担任什么角色，就使用哪个配置文件。而被指定为 controller 的节点就要参加到元数据的管理了。

2. node.id

首先是 node.id，这个我理解和 broker.id 差不多，但是zk模式的 kafka 集群中，节点被称为broker，但是在 Kraft 模式下，每个节点可以被指定为broker 或者 controller，所以再叫 broker 就不太合适了，所以这里就叫做 node.id。

3. controller.quorum.bootstrap.servers

在学 zk 的时候，我们知道 zk 可以被用来实现分布式锁，所以这种特性也被用作 Kafka 集群的 controller 选举上：

1. Kafka 启动后尝试注册 /controller 节点（临时顺序节点）。
2. 所有 broker 会竞争 /controller 的写入权，谁先写成功，谁就是 controller

而在 KRaft 模式中，使用 Raft 协议替代了 zk，并引入了仲裁的方式来选举主 controller。

1. process.roles=controller 的节点，加入 Raft
2. 每个节点都会等待一个随机时间，然后发起选举请求
3. 多数节点投票后，该节点成为 Leader，负责元数据的写入与同步

仲裁又分为静态仲裁和动态仲裁。

静态仲裁

如果是静态仲裁，需要使用 controller.quorum.voters 列出所有的 controller 节点。

controller.quorum.voters=1@node1:9093,2@node2:9093,3@node3:9093

格式: {node.id}@{host}:{port}

动态仲裁

如果使用动态仲裁，就使用 controller.quorum.bootstrap.servers 列出部分 controller 节点就可以，和我们使用 Kafka 时指定 bootstrap.servers 一样，都是会自动发现的。

controller.quorum.bootstrap.servers=host1:port1,host2:port2,host3:port3

所以，controller.quorum.voters 和 controller.quorum.bootstrap.servers 二者选一，再生产仲还是建议使用动态仲裁。

假如我们的集群中指定了A/B/C三个节点作为 controller，在A/B/C中，必须有一个主控制器，如果A是主控制器，那么B/C就是热备控制器，当A故障的时候可以随时接管。3个控制器最多允许1个故障，5个允许2个。

除了从配置上，我们还可以运行命令查看：

kafka-features.sh --bootstrap-controller localhost:9093 describe

如果 FinalizedVersionLevel 为 0 或者没有，则使用的静态，大于0就是动态，如下图所示，我搭建的单点 kafka 使用的就是静态仲裁。

去配置文件中验证了一下，也确实如此：

4. listeners

在之前云服务器搭建 kafka 容器时，遇到了外网无法访问的问题，然后兜兜转转发现就是两个配置没搞明白，就是 listeners 和 advertised.listeners。

1. listeners：可以理解为本地监听地址，用于集群间通信，需要配置 broker 和 controller 地址。
2. advertised.listeners：指定 Kafka 广播给客户端和其他 broker 的地址，如果是云服务器，需要配置为公网IP。

我在云服务器上的 Kafka 配置如下：

listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
advertised.listeners=PLAINTEXT://公网IP:9092,CONTROLLER://localhost:9093

每个配置定义了两个端口，一个是 broker 的，一个是 controller 的。上面需要关注的时配置的格式： {LISTENER_NAME}://{hostname}:{port}, LISTENER_NAME 表示的就是安全协议，像 PLAINTEXT 就是普通文本没有认证，我们生产中用的 Kerberos 认证，就需要使用 SASL_PLAINTEXT 协议。

在 listener.security.protocol.map 中，定义了 LISTENER_NAME 和 安全协议 之间的映射关系。

默认定义映射名字是相同的，如果是为了做一些区分，你也可以自定义 LISTENER_NAME。

结语

本篇文章文章的初衷就是记录一下 KRaft 模式下的 kafka 配置，弥补一下自己在这一块的知识空白。