学习Kafka-Kraft部署使用背景和意义
目前磐基平台已经提供kafka3.5.1版本能力，新版本对kakfa元数据管理、注册协调架构已经发生了很大的变化。据了解目前已有租户在使用。对于kafka新版本新特性来讲，广大磐基运维不十分了解和熟练，特别是在维护和处理问题时显得力不从心，因此需要推出一篇kafka-kraft模式的部署和使用技术文档，kraft模式是Kafka 2.8版本的新特性和功能，在kafka3.x版本中已经成熟，是kafka组件未来发展的趋势，磐基一线二线运维了解和学习新的技术可以提升运维效率和运维技术能力。因此，学习和掌握Kafka-kraft的架构原理和维护是一个必须的技能。
Kafka-Kraft架构
Karft是一个Apache基金会项目，具有Apache v2许可证。未来Kraft将作为Apache Kafka的内置共识机制将取代Zookeeper。该模式在Kafka 2.8版本发布了体验版本，Kafka 3.X系列中Kraft是一个稳定版本。Kraft运行模式的Kafka集群，不会将元数据存在zk中，部署Kakfa集群时无需再部署zk集群，Kafka将元数据存储在Controller节点的Kraft Quorum中。Kraft模式提供很多优势，如可支持更多分区，更快速切换Controller，另外还避免Controller缓存的元数据和zk存储的数据不一致带来的一系列问题。
Kafka在2.8版本之前，Kafka强依赖zookeeper来来负责集群元数据的管理，这也导致当Zookeeper集群性能发生抖动时，Kafka的性能也会收到很大的影响。2.8版本之后，kafka3.x开始提供KRaft（Kafka Raft，依赖Java 8+ ）模式，开始去除对zookeeper的依赖。最新的3.5等版本中，Kafka依然兼容zookeeper Controller，但Kafka Raft元数据模式，将依赖于ZooKeeper的控制器改造成了基于Kafka Raft的Quorm控制器，因此可以在不使用ZooKeeper的情况下实现集群。
Kafka KRaft模式是Kafka的一个新特性，它用于取代传统的Kafka集群的ZooKeeper协调器。在KRaft模式下，不再需要ZooKeeper。因为 Kafka 将元数据存储在 controller 节点的 KRaft Quorum中。KRaft 可以带来很多好处，比如可以支持更多的分区，更快速的切换 controller ，也可以避免 controller 缓存的元数据和Zookeeper存储的数据不一致带来的一系列问题。Kafka控制器在KRaft模式下由Kafka集群自己选举，这提供了更高的可用性和可靠性。
Zookeeper是一个重量级的协调系统，非常笨重，zk还要求奇数个节点的集群配置，扩容和收缩都非常不方便，另外zk的配置方式也和Kafka完全不一样。当zk和Kafka放在一个存储系统里，当topic和partition的数量上了规模，数据同步问题就会非常显著。Zookeeper是强一致性的组件（符合CP理论），如果集群中数据发生变化，那么必须要等到其它节点都同步，至少超过一半同步完成，这样节点数多性能差。
kafka的角色：
controller节点 相当于主机（主机类似 zk 功能）
broker 节点相当于从机
混合节点：上述二者兼有
角色作用：
Broker节点：即代理节点，是Kafka中的工作节点，充当消息队列的角色，负责储存和处理消息，每个Broker都是一个独立的Kafka服务器，可以在不同的机器上运行，除此之外Broker还负责分区（partition）的管理，将主题（topic）划分为多个分区，并分布在集群的不同Broker上
Controller节点：即控制器节点，是集群中的特殊节点，负责储存和管理整个集群元数据和状态，它能够监控整个集群中的Broker，在需要时还能够进行平衡操作
混合节点：即同时担任Broker和Controller节点角色的节点
zookeeper+kafka与Kafka-Kraft模式对比
zookeeper+Kafka 现有架构机制：
元数据在 zookeeper 中，运行时动态选举 controller，由controller 进行 Kafka 集群管理。在当前架构中，Kafka集群包含多个broker节点和一个ZooKeeper 集群。我们在这张图中描绘了一个典型的集群结构：4个broker节点和3个ZooKeeper节点。Kafka 集群的controller (橙色)在被选中后，会从 ZooKeeper 中加载它的状态。controller 指向其他 broker节点的箭头表示 controller 在通知其他 broker 发生了变更。
运维部署：3 个 ZK 节点；2…N 个 Broker 节点，其中一个 Broker 承担 Controller 的角色。除了拉起一套最小生产的 Kafka 集群需要至少 3 + N 的资源外，Kafka 的运维人员要同时掌握 ZK 和 Kafka Broker 两套完全不同的系统的运维方式。
通信协调：ZK 节点之间通过 ZAB 协议进行一致性协调；Broker 会通过 ZK 来选出一个 Controller 负责全局的协调，同时也会直接修改 ZK 里的数据；Controller 也会监听和修改 ZK 里的数据，并调用 Broker 来完成集群的协调。虽然 ZK 之间的一致性由 ZAB 来保障了，但是 ZK 与 Controller 之间和 Controller 与 Broker 之间的一致性是相对比较脆弱的。
kafka+kraft 模式架构机制：
不再依赖 zookeeper 集群，而是用三台 controller 节点代替 zookeeper，元数据保存在 controller 中，由 controller 直接进行 Kafka 集群管理。 controller相关的元数据信息以kafka日志的形式存在（即：以消息队列消息的形式存在）。使用Kraft协议代替zookeeper进行集群的Controller选举。
在新的架构中，三个 controller 节点替代三个ZooKeeper节点。控制器节点和 broker 节点运行在不同的进程中。controller 节点中会选择一个成为Leader(橙色)。新的架构中，控制器不会向 broker 推送更新，而是 broker 从这个 controller Leader 拉取元数据的更新信息。
运维部署：3 个 Controller 节点；0…N 个 Broker 节点。Kafka 节点可以同时承担 Controller 和 Broker 两个角色，因此一套最小生产集群只需要 3 个节点。在测试环境更可以只以 1 节点模式就可以轻量地拉起一个 Kafka 集群。
通信协调：Controller 节点底层通过 Raft 协议达成一致，Controller 的内存状态通过 #replay Raft Log 来构建，因此 Controller 之间的内存状态都是一致的；Broker 订阅 KRaft Log 维护和 Controller 一致的内存状态，并且通过事件驱动的方式执行 Partition Reassignment 之类的操作来实现集群最终一致性协调。整个集群的状态维护和一致性协调都是基于 KRaft 中的事件。
Kraft 模式优势：
- （1）Kafka不再依赖外部框架，而是能够独立运行。这样减少Zookeeper性能抖动对Kafka集群性能的影响，同时Kafka产品的版本迭代也更自由；
- （2）controller 管理集群时，不再需要从 zookeeper 中先读取数据，集群性能上升；
- （3）由于不依赖 zookeeper，集群扩展时不再受到 zookeeper 读写能力限制；
- （4）controller 不再由zookeeper动态选举，而是由配置文件固定产生。这样可以有针对性的加强controller节点的配置，而不是像以前一样对随机 controller 节点的高负载束手无策。
- （5）Zookeeper的产品特性决定了他不适合存储大量的数据，这对Kafka的集群规模(确切的说应该是Partition规模)是极大的限制。摆脱Zookeeper后，集群扩展时元数据的读写能力得到增强。因此，对于kaka组件而言，kafka-kraft模式是未来发展的趋势，KRaft模式通过提供去中心化的元数据管理和高可用性，减少了对于外部ZooKeeper的依赖，这对于提高系统的可靠性和稳定性具有重要意义。 四、部署kafka-kraft集群演示：
环境：三controller节点，三broker节点分离部署方案：
每个服务器节点分别启动两个kafka进程，分别为controller、broker。9093是controller端口，9092是broker端口。
192.168.40.11 id=1 角色controller id=2 角色broker
192.168.40.14 id=3 角色controller id=4 角色broker
192.168.40.18 id=5 角色controller id=6 角色broker
创建kafka数据目录：
mkdir /kafkacontroller //每个kafka创建controller数据目录
mkdir /kafkabroker //每个创建broker数据目录
每个节点复制两个程序：
tar fx kafka_2.13-3.5.0.tgz -C /usr/local/
mv kafka_2.13-3.5.0 kafka3.5-kraft-controller //复制controller程序
mv kafka_2.13-3.5.0 kafka3.5-kraft //复制broker程序
配置文件配置
[root@localhost local]# cd kafka_2.13-3.5.0/[root@localhost kafka_2.13-3.5.0]# ll
total 64
drwxr-xr-x 3 root root 4096 Jun 52023 bin
drwxr-xr-x 3 root root 4096 Jun 52023 config
drwxr-xr-x 2 root root 8192 Aug 13 05:08 libs
-rw-r--r-- 1 root root 14770 Jun 52023 LICENSE
drwxr-xr-x 2 root root 284 Jun 52023 licenses
-rw-r--r-- 1 root root 28184 Jun 52023 NOTICE
drwxr-xr-x 2 root root 44 Jun 52023 site-docs
[root@localhost kafka_2.13-3.5.0]# cd config/[root@localhost config]# ll
total 72
-rw-r--r-- 1 root root 906 Jun 52023 connect-console-sink.properties
-rw-r--r-- 1 root root 909 Jun 52023 connect-console-source.properties
-rw-r--r-- 1 root root 5475 Jun 52023 connect-distributed.properties
-rw-r--r-- 1 root root 883 Jun 52023 connect-file-sink.properties
-rw-r--r-- 1 root root 881 Jun 52023 connect-file-source.properties
-rw-r--r-- 1 root root 2063 Jun 52023 connect-log4j.properties
-rw-r--r-- 1 root root 2540 Jun 52023 connect-mirror-maker.properties
-rw-r--r-- 1 root root 2262 Jun 52023 connect-standalone.properties
-rw-r--r-- 1 root root 1221 Jun 52023 consumer.properties
drwxr-xr-x 2 root root 85 Jun 52023 kraft
-rw-r--r-- 1 root root 4917 Jun 52023 log4j.properties
-rw-r--r-- 1 root root 2065 Jun 52023 producer.properties
-rw-r--r-- 1 root root 6896 Jun 52023 server.properties
-rw-r--r-- 1 root root 1032 Jun 52023 tools-log4j.properties
-rw-r--r-- 1 root root 1169 Jun 52023 trogdor.conf
-rw-r--r-- 1 root root 1205 Jun 52023 zookeeper.properties
[root@localhost config]# cd kraft/[root@localhost kraft]# ll
total 24
-rw-r--r-- 1 root root 6136 Jun 52023 broker.properties
-rw-r--r-- 1 root root 5765 Jun 52023 controller.properties
-rw-r--r-- 1 root root 6340 Jun 52023 server.properties
配置文件配置：
192.168.40.11
controller角色：
process.roles=controller //controller角色
node.id=1
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=CONTROLLER://192.168.40.11:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER
Broker角色：
process.roles=broker //broker角色
node.id=2
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=PLAINTEXT://192.168.40.11:9092
log.dirs=/kafkabroker
controller.listener.names=CONTROLLER
192.168.40.14
controller角色：
process.roles=controller //controller角色
node.id=3
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=CONTROLLER://192.168.40.14:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER
Broker角色：
process.roles=broker //broker角色
node.id=4
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=PLAINTEXT://192.168.40.14:9092
log.dirs=/kafkabroker
controller.listener.names=CONTROLLER
192.168.40.18
controller角色：
process.roles=controller //controller角色
node.id=5
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=CONTROLLER://192.168.40.18:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER
Broker角色：
process.roles=broker //broker角色
node.id=6
[email protected]:9093,[email protected]:9093,[email protected]:9093
listeners=PLAINTEXT://192.168.40.18:9092
log.dirs=/kafkabroker
controller.listener.names=CONTROLLER
Kraft基本配置参数说明：
process.roles=broker, controller //kafka 的角色（controller 相当于主机、broker 节点相当于从机，主机类似 zk 功能，负责kaka集群管理。在 KRaft 模式中，每个 Kafka 服务器都可以使用 process.roles 属性配置为 controller、broker 或这两个。设置为 broker，则服务器将充当 Broker。设置为 controller，则服务器将充当 Controller。设置为 broker,controller，则服务器同时充当 Broker 和 Controller。如果process.roles 没有设置。那么集群就假定是运行在ZooKeeper模式下。
同时充当 Broker 和 Controller 的 Kafka 服务器被称为“组合”服务器。对于像开发环境这样的小用例，组合服务器更易于操作。关键的缺点是控制器与系统的其余部分的隔离度较低。例如，在组合模式下，不可能将 Controller 与 Broker 程序分开滚动或缩放。不建议在关键部署环境中使用组合模式。
node.id=2 //broker节点 ID，任何角色的每个节点id必须不同。
controller.listener.names=CONTROLLER //controller 服务协议别名。每个角色每个kafka节点必须设置，且参数值一样 。控制器使用的侦听器名称的逗号分隔列表。如果`listener.security.protocol.map`中未设置显式映射，则默认使用PLAINTEXT协议 。如果在KRaft模式下运行，这是必需的。
controller.quorum.voters=2@hadoop102:9093,3@hadoop103:9093,4@hadoop104:9093 // Controller节点列表，投票者列表。Kafka任何角色节点必须设置，且参数值相同。前面的数字如1是这个controller控制节点ip的node. id。注意：每个broker和每个controller 都必须设置 controller.quorum.voters。
listeners=PLAINTEXT://:9092,CONTROLLER://:9093 //不同服务器绑定的端口，启动后会生成9092、9093两个端口。broker将使用9092端口，而kraft controller控制器将使用9093端口，如果明确本节点为控制节点，则控制节点9093必须写上。
# 套接字服务器侦听的地址.# 组合节点（即具有`process.roles=broker,controller`的节点）必须至少在此处列出控制器侦听器# 如果没有定义代理侦听器，那么默认侦听器将使用一个等于java.net.InetAddress.getCanonicalHostName()值的主机名,# 带有PLAINTEXT侦听器名称和端口9092# FORMAT:# listeners = listener_name://host_name:port# EXAMPLE:# listeners = PLAINTEXT://your.host.name:9092#不同服务器绑定的端口
CONTROLLER://:10000 本节点作为Controller节点，监听本机所有可用网卡的10000端口（使用10000端口作为控制器端口）
inter.broker.listener.name=PLAINTEXT //broker 服务协议别名。任何角色节点必须设置，并且参数值一致。用于代理之间通信的侦听器的名称(broker 服务协议别名)
advertised.Listeners=PLAINTEXT://hadoop102:9092 //可不配置，除非需要。broker对外暴露的地址，如果都是局域网使用，就配置PLAINTEXT://:9092即可。如果未设置，则使用"listeners"的值。
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL //#协议别名到安全协议的映射。# 将侦听器名称映射到安全协议，默认情况下它们是相同的。(协议别名到安全协议的映射)有关更多详细信息，请参阅配置文档。
log.dirs=/opt/module/kafka2/data //kafka 数据存储目录
修改日志配置文件
vim /path/config/log4j.properties
添加两条日志最大量
log4j.appender.kafkaAppender.MaxFileSize=100MB
log4j.appender.kafkaAppender.MaxBackupIndex=5
修改DatePattern
log4j.appender.kafkaAppender.DatePattern='.'yyyy-MM-dd
创建kraft集群
生成集群id：
在任意一个kafka节点上执行就行，初始化集群数据目录，首先生成存储目录唯一 ID。生成后保存生成的字符串。这个集群ID事实上是一个长度16位的字符串通过Base64编码后得来的，因此你也可以不使用上述命令，直接自定义一个16位长度的纯英文和数字组成的字符串，然后将这个字符串编码为Base64格式作为这个集群ID也可以。可以使用 菜鸟工具中的在线Base64编码工具。
[root@kafka01 bin]# /usr/local/kafka3.5-kraft-controller/bin/kafka-storage.sh random-uuid
zsP5CeHlRdG0YoVrdTgm5w
格式化所有kafka节点数据目录：
然后分别在每个kafka进程执行下面命令，用该 ID 格式化 kafka 存储目录。完成集群元数据配置，-t指定刚才生成的字符串
如果是本文档三controller节点，三broker节点分离部署方案，那么6个kafka进程都要执行，一共执行6次。
首先格式化3个controller：每个controller节点必须执行，一共执行3次。
[root@kafka01 bin]# /usr/local/kafka3.5-kraft-controller/bin/kafka-storage.sh format -t zsP5CeHlRdG0YoVrdTgm5w -c /usr/local/kafka3.5-kraft-controller/config/kraft/server.properties
Formatting /kafkacontroller with metadata.version 3.5-IV2.
其次格式化3个broker：每个broker节点必须执行，一共执行3次。
[root@kafka18 kraft]# /usr/local/kafka3.5-kraft/bin/kafka-storage.sh format -t zsP5CeHlRdG0YoVrdTgm5w -c /usr/local/kafka3.5-kraft/config/kraft/server.properties
Formatting /kafkabroker with metadata.version 3.5-IV2.
查看controller数据目录：
[root@kafka01 bin]# cd /kafkacontroller/
You have new mail in /var/spool/mail/root
[root@kafka01 kafkacontroller]# ll
total 8
-rw-r--r-- 1 root root 249 Aug 19 07:17 bootstrap.checkpoint
-rw-r--r-- 1 root root 86 Aug 19 07:17 meta.properties
[root@kafka01 kafkacontroller]# cat meta.properties ##Mon Aug 19 07:17:27 EDT 2024
node.id=1 //每个角色每个节点，此id必须唯一
version=1
cluster.id=zsP5CeHlRdG0YoVrdTgm5w //每个kafka节点id会一致，就是之前命令生成的
查看broker数据目录：
[root@kafka01 kafkacontroller]# cd /kafkabroker/[root@kafka01 kafkabroker]# ll
total 8
-rw-r--r-- 1 root root 249 Aug 19 07:21 bootstrap.checkpoint
-rw-r--r-- 1 root root 86 Aug 19 07:21 meta.properties
[root@kafka01 kafkabroker]# cat meta.properties ##Mon Aug 19 07:21:40 EDT 2024
node.id=2version=1
cluster.id=zsP5CeHlRdG0YoVrdTgm5w
启动kafka kraft集群
启动方式与传统模式启动方法一样。首先启动3个controller节点，最后启动3个broker节点
首先启动controller节点：
/usr/local/kafka3.5-kraft-controller/bin/kafka-server-start.sh -daemon /usr/local/kafka3.5-kraft-controller/config/kraft/server.properties
其次启动broker节点：
/usr/local/kafka3.5-kraft/bin/kafka-server-start.sh -daemon /usr/local/kafka3.5-kraft/config/kraft/server.properties
查看kafka进程
ps aux |grep kafka
ps -ef |grep kafka
查看日志
tail -f server.log
启动后kafka会生成9092、9093两个端口，controller通信端口：9093, 作用与zk的2181端口类似 。
[root@kafka01 kafkabroker]# ss -lnt| grep -E '9092|9093'
LISTEN 050 ::ffff:192.168.40.11:9092 :::*
LISTEN 050 ::ffff:192.168.40.11:9093 :::*
关闭kraft集群
/usr/local/kafka_2.13-3.5.0/bin/kafka-server-stop.sh
查看controller数据目录内容
[root@kafka18 kraft]# cd /kafkacontroller/[root@kafka18 kafkacontroller]# ll
total 8
-rw-r--r-- 1 root root 249 Aug 19 07:19 bootstrap.checkpoint
drwxr-xr-x 2 root root 187 Aug 19 07:56 __cluster_metadata-0
-rw-r--r-- 1 root root 86 Aug 19 07:19 meta.properties
[root@kafka18 kafkacontroller]# cd __cluster_metadata-0/[root@kafka18 __cluster_metadata-0]# ll
total 60
-rw-r--r-- 1 root root 10485760 Aug 19 08:00 00000000000000000000.index
-rw-r--r-- 1 root root 37053 Aug 19 08:00 00000000000000000000.log
-rw-r--r-- 1 root root 10485756 Aug 19 08:00 00000000000000000000.timeindex
-rw-r--r-- 1 root root 14 Aug 19 07:56 leader-epoch-checkpoint
-rw-r--r-- 1 root root 43 Aug 19 07:55 partition.metadata
-rw-r--r-- 1 root root 154 Aug 19 07:56 quorum-state
三台controller的文件相同
[root@kafka14 __cluster_metadata-0]# cat leader-epoch-checkpoint 02150213
三台controller的文件相同
[root@kafka14 __cluster_metadata-0]# cat partition.metadata
version: 0
topic_id: AAAAAAAAAAAAAAAAAAAAAQ
三台controller的文件相同
[root@kafka01 __cluster_metadata-0]# cat quorum-state {"clusterId":"","leaderId":3,"leaderEpoch":21,"votedId":-1,"appliedOffset":0,"currentVoters":[{"voterId":1},{"voterId":3},{"voterId":5}],"data_version":0}
查看broker数据目录内容
[root@kafka01 kafkabroker]# ll
total 16
-rw-r--r-- 1 root root 249 Aug 19 07:21 bootstrap.checkpoint //需要特殊命令查看
-rw-r--r-- 1 root root 0 Aug 19 07:56 cleaner-offset-checkpoint
drwxr-xr-x 2 root root 237 Aug 19 08:56 __cluster_metadata-0
-rw-r--r-- 1 root root 4 Aug 19 09:05 log-start-offset-checkpoint
-rw-r--r-- 1 root root 86 Aug 19 07:21 meta.properties
-rw-r--r-- 1 root root 4 Aug 19 09:05 recovery-point-offset-checkpoint
-rw-r--r-- 1 root root 0 Aug 19 07:56 replication-offset-checkpoint
三节点都是2个0
[root@kafka01 kafkabroker]# cat log-start-offset-checkpoint00
三节点都一样
[root@kafka01 kafkabroker]# cd __cluster_metadata-0/[root@kafka01 __cluster_metadata-0]# ll
total 1048
-rw-r--r-- 1 root root 10485760 Aug 19 09:09 00000000000000000000.index
-rw-r--r-- 1 root root 643365 Aug 19 09:10 00000000000000000000.log
-rw-r--r-- 1 root root 10485756 Aug 19 09:09 00000000000000000000.timeindex
-r-------- 1 root root 555 Aug 19 08:56 00000000000000007186-0000000021.checkpoint
-rw-r--r-- 1 root root 14 Aug 19 07:56 leader-epoch-checkpoint
-rw-r--r-- 1 root root 43 Aug 19 07:56 partition.metadata
-rw-r--r-- 1 root root 154 Aug 19 07:56 quorum-state
[root@kafka01 __cluster_metadata-0]# cat leader-epoch-checkpoint 02150213[root@kafka01 __cluster_metadata-0]# cat partition.metadata
version: 0
topic_id: AAAAAAAAAAAAAAAAAAAAAQ
[root@kafka01 __cluster_metadata-0]# cat quorum-state {"clusterId":"","leaderId":3,"leaderEpoch":21,"votedId":-1,"appliedOffset":0,"currentVoters":[{"voterId":1},{"voterId":3},{"voterId":5}],"data_version":0}
生产消费测试
1）创建topic
/usr/local/kafka3.5-kraft/bin/kafka-topics.sh --bootstrap-server 192.168.40.11:9092 --create --topic kr --replication-factor 3 --partitions 3
Created topic kr.
2）查看创建的topic
[root@kafka01 __cluster_metadata-0]# /usr/local/kafka3.5-kraft/bin/kafka-topics.sh --bootstrap-server 192.168.40.11:9092 --describe
Topic: kr TopicId: YsV3On2zSZ-PatanbdwouA PartitionCount: 3 ReplicationFactor: 3 Configs: segment.bytes=1073741824
Topic: kr Partition: 0 Leader: 4 Replicas: 4,6,2 Isr: 4,6,2
Topic: kr Partition: 1 Leader: 6 Replicas: 6,2,4 Isr: 6,2,4
Topic: kr Partition: 2 Leader: 2 Replicas: 2,4,6 Isr: 2,4,6
3）生产消息
[root@kafka01 __cluster_metadata-0]# /usr/local/kafka3.5-kraft/bin/kafka-console-producer.sh --bootstrap-server 192.168.40.11:9092 --topic kr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
>dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
>eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
4）消费消息
]# /usr/local/kafka3.5-kraft/bin/kafka-console-consumer.sh --bootstrap-server 192.168.40.11:9092 --topic kr --from-beginning
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
每个broker数据目录都生成了offset目录和topic目录
[root@kafka01 kafkabroker]# ll
total 20
-rw-r--r-- 1 root root 249 Aug 19 07:21 bootstrap.checkpoint
-rw-r--r-- 1 root root 0 Aug 19 07:56 cleaner-offset-checkpoint
drwxr-xr-x 2 root root 237 Aug 19 08:56 __cluster_metadata-0
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-1
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-11
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-12
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-17
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-18
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-21
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-24
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-28
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-32
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-34
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-38
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-41
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-42
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-47
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-49
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-5
drwxr-xr-x 2 root root 167 Aug 19 09:32 __consumer_offsets-6
drwxr-xr-x 2 root root 167 Aug 19 09:15 kr-0
drwxr-xr-x 2 root root 167 Aug 19 09:15 kr-1
drwxr-xr-x 2 root root 167 Aug 19 09:15 kr-2
-rw-r--r-- 1 root root 4 Aug 19 09:35 log-start-offset-checkpoint
-rw-r--r-- 1 root root 86 Aug 19 07:21 meta.properties
-rw-r--r-- 1 root root 431 Aug 19 09:35 recovery-point-offset-checkpoint
-rw-r--r-- 1 root root 431 Aug 19 09:35 replication-offset-checkpoint
版权归原作者 斯普信专业组 所有， 如有侵权，请联系我们删除。