kafka3.9集群部署（Kraft模式）去zookeeper模式

kafka3.9集群

KRaft模式与非KRaft模式主要区别

1.部署组件
KRaft模式：
不再依赖ZooKeeper集群。KRaft模式通过引入独立的元数据节点（Controller节点）来处理集群的元数据操作。
元数据保存在Controller节点中，由Controller节点直接进行Kafka集群管理。
非KRaft模式：
依赖ZooKeeper集群来管理Kafka集群的元数据。
Kafka集群中的broker会定期向ZooKeeper更新自己的状态信息，同时从ZooKeeper中读取其他broker的状态信息。

2.Controller选举与管理
KRaft模式：
Controller节点不再动态选举，而是由配置文件规定。这允许有针对性地加强Controller节点的配置，以提高集群的可靠性和性能。
由于Controller节点是静态配置的，因此集群扩展时不再受到ZooKeeper读写能力的限制。
非KRaft模式：
Controller（或称为leader broker）是动态选举的。当集群中的某个broker成为Controller时，它会负责处理集群的元数据操作。
如果Controller发生故障，集群会重新选举一个新的Controller。

系统:
Centos7.8
节点信息：
broker_1:localhost:9092:9093
broker_2:localhost:9292:9293
broker_3:localhost:9392:9393

kafka版本：
https://dlcdn.apache.org/kafka/3.9.0/kafka_2.13-3.9.0.tgz
tar -xzf kafka_2.13-3.9.0.tgz
cd kafka_2.13-3.9.0

cluster 集群 broker 节点1 配置示例：

cat config/kraft/server.properties
# 
process.roles=broker,controller
node.id=1
# 节点id
controller.quorum.voters=1@localhost:9093,2@localhost:9293,3@localhost:9393
# Controller 集群的投票成员列表
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
# 配置Broker 通信（PLAINTEXT）和 Controller 通信端口
inter.broker.listener.name=PLAINTEXT
# Broker 间通信使用 PLAINTEXT 协议（明文传输），生产环境存在安全风险。
advertised.listeners=PLAINTEXT://localhost:9092,CONTROLLER://localhost:9093
# 客户端和 Broker 间通信地址。需确保 IP 可访问，否则会导致网络问题
controller.listener.names=CONTROLLER
# 指定controller使用的监听器名称
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
# 映射监听器名称到安全协议
num.network.threads=3
# 网络线程数通常根据broker的流量调整，默认是3，
num.io.threads=8
# IO线程，考虑磁盘IO压力大，可以设置CPU核心数的一半
socket.send.buffer.bytes=102400
# socket缓冲区设置，发送套接字的缓冲区大小
socket.receive.buffer.bytes=102400
# 接收套接字的缓冲区大小
socket.request.max.bytes=104857600
# 请求的最大大小 如果处理大消息客适当配置
log.dirs=/tmp/kraft-combined-logs
# 日志存储路径
num.partitions=3
# 创建默认分区数
num.recovery.threads.per.data.dir=3
# 每个数据目录在启动时用于日志恢复的线程数，配置过多有可能影响到IO
offsets.topic.replication.factor=3
# offsets的副本数
transaction.state.log.replication.factor=3
# 事务状态日志副本数
transaction.state.log.min.isr=3
# 最小同步副本数
log.retention.hours=168
# 默认日志保留 168小时 7天
log.segment.bytes=1073741824
# 日志段大小
log.retention.check.interval.ms=300000
# 即5分钟检查一次日志保留
log.retention.bytes=10737418240  
# 10GB 总大小限制

broker  节点2、 节点3 配置更改对应的节点broker、Controller通信地址和端口。

创建cluster 集群的 UUID

# 节点1执行生产 uuid
./bin/kafka-storage.sh random-uuid

全节点 节点1 节点2 节点3 分别初始格式化数据元

# 在每个broker节点上执行 
./bin/kafka-storage.sh format -t 0vEHoq-NScqsNzGWFmnrnw -c ./config/kraft/server.properties

# 可以在节点配置的数据文件查看 log.dirs 默认是/ tmp
cat /tmp/kraft-combined-logs/meta.properties
#
#Tue Feb 18 21:32:50 CST 2025
cluster.id=0vEHoq-NScqsNzGWFmnrnw
# 节点ID
version=1
directory.id=2vc2FOdVERluYyDNgBFXKg
node.id=1

启动节点

分别启动各个 broker 节点的kafka集群
./bin/kafka-server-start.sh config/kraft/server.properties 

Topic 创建测试

# 创建topic
./bin/kafka-topics.sh --create --topic abcde --bootstrap-server localhost:9092
# 默认是3个副本分区，配置文件没指定也可以自定义添加参数副本分区 --replication-factor 3 --partitions 1

# 检查topic 
./bin/kafka-topics.sh --describe --topic abcde --bootstrap-server localhost:9092

# 测试生产者 生产 msg   （单独开启一个终端输入创建msg）
./bin/kafka-console-producer.sh --topic abcde--bootstrap-server localhost:9092
> this is new msg

# 读取topic  自动读取（单独开启一个终端消费输出）
./bin/kafka-console-consumer.sh --topic abcde --from-beginning --bootstrap-server localhost:9092
> this is new msg

Kafka集群并发性能测试

# 生产者测试 topic 
./bin/kafka-producer-perf-test.sh --topic test-topic --num-records 1000000 --record-size 100 --throughput -1 --producer-props bootstrap.servers=localhost:9092 acks=all

--topic：指定要发送数据的主题。
--num-records：要发送的记录数。
--record-size：每条记录的大小（字节）。
--throughput：预期吞吐量（记录/秒），这是一个目标值，实际吞吐量可能会有所不同。
--producer-props：指定生产者的配置属性，如bootstrap.servers、acks等。

消费测试

# 可在任意 broker 节点执行：
# ./bin/kafka-consumer-perf-test.sh --topic test-topic --fetch-size 1048576 --messages 1000000  --bootstrap-server localhost:9092 --group abcd-group

--topic：指定要读取数据的主题。
--fetch-size：每次拉取数据的大小（字节）。
--messages：要读取的消息数。
--threads：使用的消费者线程数。
--consumer-props：指定消费者的配置属性，如bootstrap.servers、group等。

# 输出结果：
start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec, fetch.nMsg.sec
2025-02-18 23:43:17:380, 2025-02-18 23:43:22:112, 95.3674, 20.1537, 1000000, 211327.1344, 3742, 990, 96.3307, 1010101.0101
# 参数解释
start.time：
# 表示性能测试或监控开始的时间戳。这通常是一个时间点的记录，用于后续分析性能数据时的时间参考。
end.time：
# 表示性能测试或监控结束的时间戳。与 start.time 一起，这两个时间点定义了性能测试或监控的持续时间。
data.consumed.in.MB：
# 在性能测试期间，消费者消费的总数据量（以兆字节为单位）。这衡量了消费者处理数据的能力。
MB.sec：
# 每秒消费的数据量（以兆字节为单位）。这是衡量消费者吞吐量的关键指标。
data.consumed.in.nMsg：
# 在性能测试期间，消费者消费的总消息数。这提供了关于消费者处理单个消息能力的视角。
nMsg.sec：
# 每秒消费的消息数。这是另一个衡量消费者吞吐量的重要指标，特别是当关注点是消息数量而非数据量时。
rebalance.time.ms：
# 消费者组重新平衡所需的时间（以毫秒为单位）。重新平衡是 Kafka 消费者组在成员变更时重新分配分区的过程。这个指标衡量了重新平衡操作对消费者性能的影响。
fetch.time.ms：
# 消费者从 Kafka 集群获取数据所需的总时间（以毫秒为单位）。这个指标反映了消费者拉取数据的效率。
fetch.MB.sec：
# 在拉取数据期间，消费者每秒从 Kafka 集群获取的数据量（以兆字节为单位）。这是衡量消费者拉取数据吞吐量的指标。
fetch.nMsg.sec：
# 在拉取数据期间，消费者每秒从 Kafka 集群获取的消息数。这个指标提供了关于消费者拉取消息速率的额外信息。