Kafka-kraft模式部署与使用

于 2024-10-11 16:07:50 发布
阅读量692 收藏 6
点赞数 9
分类专栏： Kafka 文章标签： kafka 分布式 云原生 中间件
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_40477248/article/details/142855885
版权

学习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  5  2023 bin
drwxr-xr-x 3 root root  4096 Jun  5  2023 config
drwxr-xr-x 2 root root  8192 Aug 13 05:08 libs
-rw-r--r-- 1 root root 14770 Jun  5  2023 LICENSE
drwxr-xr-x 2 root root   284 Jun  5  2023 licenses
-rw-r--r-- 1 root root 28184 Jun  5  2023 NOTICE
drwxr-xr-x 2 root root    44 Jun  5  2023 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  5  2023 connect-console-sink.properties
-rw-r--r-- 1 root root  909 Jun  5  2023 connect-console-source.properties
-rw-r--r-- 1 root root 5475 Jun  5  2023 connect-distributed.properties
-rw-r--r-- 1 root root  883 Jun  5  2023 connect-file-sink.properties
-rw-r--r-- 1 root root  881 Jun  5  2023 connect-file-source.properties
-rw-r--r-- 1 root root 2063 Jun  5  2023 connect-log4j.properties
-rw-r--r-- 1 root root 2540 Jun  5  2023 connect-mirror-maker.properties
-rw-r--r-- 1 root root 2262 Jun  5  2023 connect-standalone.properties
-rw-r--r-- 1 root root 1221 Jun  5  2023 consumer.properties
drwxr-xr-x 2 root root   85 Jun  5  2023 kraft     
-rw-r--r-- 1 root root 4917 Jun  5  2023 log4j.properties
-rw-r--r-- 1 root root 2065 Jun  5  2023 producer.properties
-rw-r--r-- 1 root root 6896 Jun  5  2023 server.properties
-rw-r--r-- 1 root root 1032 Jun  5  2023 tools-log4j.properties
-rw-r--r-- 1 root root 1169 Jun  5  2023 trogdor.conf
-rw-r--r-- 1 root root 1205 Jun  5  2023 zookeeper.properties

[root@localhost config]# cd kraft/
[root@localhost kraft]# ll
total 24
-rw-r--r-- 1 root root 6136 Jun  5  2023 broker.properties
-rw-r--r-- 1 root root 5765 Jun  5  2023 controller.properties
-rw-r--r-- 1 root root 6340 Jun  5  2023 server.properties

配置文件配置：

192.168.40.11

controller角色：

process.roles=controller   //controller角色
node.id=1
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18:9093
listeners=CONTROLLER://192.168.40.11:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER

Broker角色：

process.roles=broker    //broker角色
node.id=2
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18: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
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18:9093
listeners=CONTROLLER://192.168.40.14:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER

Broker角色：

process.roles=broker     //broker角色
node.id=4
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18: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
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18:9093
listeners=CONTROLLER://192.168.40.18:9093
log.dirs=/kafkacontroller
controller.listener.names=CONTROLLER

Broker角色：

process.roles=broker     //broker角色
node.id=6
controller.quorum.voters=1@192.168.40.11:9093,3@192.168.40.14:9093,5@192.168.40.18: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=2
version=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     0      50        ::ffff:192.168.40.11:9092                    :::*                  
LISTEN     0      50        ::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 
0
2
15 0
21 3

三台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-checkpoint
0
0

三节点都一样

[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 
0
2
15 0
21 3
[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
斯普信专业组
关注
专栏目录
Kafka部署全攻略——Kafka-KRaft模式框架
bbsxb520的博客
06-20 759
kraft模式的安装配置及可视化工具的使用
Kafka-Kraft 模式架构部署
weixin_45191791的博客
03-01 1592
Kafka-Kraft 模式架构部署
Kafka-kraft模式架构及部署流程
qq_37190071的博客
08-22 1997
Kafka-kraft模式架构及部署流程
Kafka-Kraft集群部署
weixin_44371237的博客
10-11 728
Kafka-Kraft集群部署
Kafka 实战 - Kafka-Kraft模式
qq_33240556的博客
04-11 1253
总之，Kafka-Kraft 模式为 Kafka 集群提供了一种更为简洁、高效的元数据管理方案，简化了架构、提升了性能，并增强了容错性。在实战中，应充分考虑其部署、配置、迁移、监控与运维的特点，结合业务需求制定合适的策略，确保 Kafka 集群在 KRaft 模式下的稳定、高效运行。KRaft 模式旨在替代传统的依赖 ZooKeeper 的元数据管理模式，提供更为简洁、高效且高可用的 Kafka 集群管理方案。：为 KRaft 模式下的 Broker 网络通信设置专用的内网环境，减少网络延迟和干扰。
Kafka (八) ---------- Kafka-Kraft 模式
在森林里麋了鹿
08-22 724
Kafka-Kraft 模式
Kafka3.0 新特性 Kafka-Kraft 模式
weixin_45417821的博客
06-05 1050
Kafka-Kraft （keruafute）左图为 Kafka 现有架构，元数据在 zookeeper 中，运行时动态选举 controller，由controller 进行 Kafka 集群管理。右图为 kraft 模式架构（实验性），不再依赖 zookeeper 集群，而是用三台 controller 节点代替 zookeeper，元数据保存在 controller 中，由 controller 直接进行 Kafka 集群管理。这样做的好处有以下几个：1）再次解压一份 kafka 安装包 2）重命名为
Day547.Kafka-Eagle监控&Kraft模式
阿昌爱Java
02-28 3180
Kafka-Eagle监控 Kafka-Eagle框架可以监控 Kafka 集群的整体运行情况，在生产环境中经常使用。 在此之前监控工具需要MySQL作为持久化手段。 一、Kafka环境准备 1、关闭 Kafka 集群 # 停止集群 kf.sh stop 2、修改/opt/module/kafka/bin/kafka-server-start.sh vim bin/kafka-server-start.sh 修改如下参数值： if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
k8s部署elk+filebeat+logstash+kafka集群（二）kafka-kraft模式集群
filtercomp的博客
09-30 1327
k8s中部署kafka-kraft模式集群，镜像构建到对外暴露
kafka-2.12-3.6.0安装包以及linux(centos7)无zookeeper安装kafka-2.12-3.6.0(
04-18
而Kraft模式是Kafka在3.0版本引入的新特性，允许在没有Zookeeper的情况下运行Kafka集群，简化了部署和管理。 首先，我们需要下载Kafka的安装包。在本例中，我们使用的是kafka_2.12-3.6.0。你可以从Apache官方网站...
Kafka-Kraft模式
weixin_38425605的博客
03-08 499
Kafka-Kraft模式一、Kafka-Kraft架构二、Kafka-Kraft集群部署三、Kafka-Kraft集群启动停止脚本![在这里插入图片描述](https://img-blog.csdnimg.cn/48f5349d700648bd9fd7037a8b3f83db.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAU21hcnRhb3Rhbw==,size_20,color_FFFFFF,t
【Kafka-3.x-教程】-【三】Kafka-Broker、Kafka-Kraft
weixin_53543905的博客
01-10 1682
1、Broker 启动后向 ZK 进行注册，ZK 记录好存活的 Broker。 2、每个 Broker 中都有 Controller，谁的 Controller 先注册谁就是 Controller Leader。 3、Controller Leader 上线后监听已经注册的 Broker 节点的变化。 4、Controller 开始选举 Leader （1）选举规则：在 ISR 中存活着的节点，按照 AR 中排在前面的优先，Leader 也会按照 AR 中的排列顺序进行轮询。 （2）AR：Kafk
00_概览_kafka
DXH9701的博客
10-05 1164
kafka的简介 记得比较乱
kafka-windows集群部署
weixin_42924400的博客
10-05 516
部署本文步骤可以先阅读这一篇博客，这篇是关于单机kafka部署测试的。本文用到的文件均是这一篇博客中的文件修改配置部署的。kafka基本概念以及用法。
分布式常见面试题总结
最新发布
夏日 の blog
10-10 866
在分库之后，数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。就要用到分布式 ID 保证全局唯一性。UUID 是 Universally Unique Identifier（通用唯一标识符） 的缩写。UUID 包含 32 个 16 进制数字（8-4-4-4-12）。//输出示例：cb4a9ede-fa5e-4585-b9bb-d60bce986eaa虽然，UUID 可以做到全局唯一性，但是，我们一般很少会使用它。
高级java每日一道面试题-2024年10月3日-分布式篇-分布式系统中的容错策略都有哪些？
qq_43071699的博客
10-05 1266
这些容错策略可以根据具体的业务需求和技术栈灵活组合使用。理解这些策略的工作原理以及如何在实际系统中应用它们，对于设计和维护高可用的分布式系统至关重要。在面试中，除了理论知识外，展示你如何在实际项目中应用这些策略也会给面试官留下深刻印象。
【分布式微服务云原生】Redis持久化策略：RDB vs AOF
Dylaniou的博客
10-07 1020
本文深入探讨了Redis的两种主要持久化策略：RDB和AOF。我们将分析它们的工作原理、优缺点，并探讨如何在不同的应用场景中选择最合适的持久化策略。此外，文章还将提供Java代码示例和流程图，帮助读者更好地理解这些概念。读完本文，你将能够为任何需要持久化存储的Redis应用选择合适的持久化策略。
高级java每日一道面试题-2024年10月2日-分布式篇-什么是FLP 不可能性定理？
qq_43071699的博客
10-04 880
在Java高级面试中，FLP不可能性定理是一个可能涉及的重要分布式系统理论。FLP不可能性定理是分布式计算领域的一个基础理论，由迈克尔·S·菲舍尔（Michael S. Fischer）、南希·林奇（Nancy Lynch）和迈克·帕特森（Mike Paterson）在1985年提出。该定理证明了在异步网络模型中，即使只有一个节点可能发生故障，也不存在一个确定性算法能够始终解决共识问题。共识问题是指在多个进程中，即使在存在故障节点的情况下，也要使得所有非故障节点最终就某个值达成一致的问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值