Kafka 4.1.1 生产环境调优与最佳实践指南

本文档详细介绍了 Kafka 4.1.1 在生产环境中的完整调优方案与最佳实践，涵盖 Broker 核心配置、KRaft 模式部署、Producer/Consumer 性能优化、监控告警体系、常见问题排查、安全加固（SASL + ACL）以及运维操作规范。重点解决了高可用配置、数据一致性保障、消费滞后处理、磁盘空间管理等关键问题，并提供了经过验证的配置参数和实用命令，适用于构建稳定、高性能、安全的 Kafka 生产集群。

1. 生产环境配置最佳实践

1.1 Broker 核心配置

Broker 是 Kafka 集群的核心组件，负责消息的存储、复制和分发。合理的 Broker 配置直接影响集群的性能、稳定性和数据可靠性。以下配置针对生产环境进行了优化，涵盖了网络监听、副本管理、日志保留和线程池等关键参数。

• server.properties配置优化

# server.properties

# ========== 基础配置 ==========
############################# 网络监听器 #############################
# 外部客户端访问端口 (9092) 和 Controller内部通信端口 (9093)
listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093
inter.broker.listener.name=SASL_PLAINTEXT
# 【关键】各节点需改为自己的主机名/IP
advertised.listeners=SASL_PLAINTEXT://kafka-node-01:9092
listener.security.protocol.map=CONTROLLER:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT

#分区数通常建议为Broker数量的2倍
num.partitions=6
###Kafka 集群的高可用 + 强一致性### 每个分区 3 个副本，至少 2 个同步副本确认写入。
#每个分区共有 3 个副本,1 个 Leader 负责读写，2 个 Follower 负责异步同步。
default.replication.factor=3
#Producer 写入时，最少需要多少个同步副本（ISR 中的副本）确认，才认为该消息写入成功
min.insync.replicas=2

# ========== 日志保留策略 ==========
log.retention.hours=168          # 保留 7 天
log.retention.bytes=107374182400 # 每个分区最大 100GB
log.segment.bytes=1073741824     # 每个 segment 1GB
log.cleanup.policy=delete        # 或 compact（根据业务需求）

# ========== 网络与线程配置 ==========
#网络线程池大小，对于生产环境，8-16 是常见范围。
num.network.threads=8
# #IO 线程池大小，通常为CPU 核心数的 1.5 到 2 倍左右
num.io.threads=12
#TCP 发送缓冲区大小 (SO_SNDBUF)  约 1 MB
socket.send.buffer.bytes=102400
#TCP 接收缓冲区大小 (SO_RCVBUF)  约 1 MB
socket.receive.buffer.bytes=102400
#单个网络请求的最大字节数,保持默认 100 MB
socket.request.max.bytes=104857600

# ========== 副本同步配置 ==========
#副本被踢出 ISR 的滞后阈值，30 秒是稳妥默认值
replica.lag.time.max.ms=30000
#禁止从非同步副本中选举 Leader，保证数据不丢失
unclean.leader.election.enable=false  

• JVM 配置优化

JVM 参数直接影响 Kafka Broker 的垃圾回收行为和内存使用效率。合理的堆内存设置和 GC 调优可以显著减少停顿时间，提升吞吐量。以下配置针对 8GB 堆内存进行了优化，适用于中等规模的生产环境。

# ========== JVM 配置 ==========
# 在 kafka-server-start.sh 中设置
#堆内存设置，通常设置为服务器内存的一半
export KAFKA_HEAP_OPTS="-Xms8g -Xmx8g"
#GC与JVM性能参数
export KAFKA_JVM_PERFORMANCE_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35"

1.2 KRaft 模式选择

KRaft（Kafka Raft）是 Kafka 4.x 版本引入的新元数据管理模式，彻底移除了对 ZooKeeper 的依赖。相比传统的 ZooKeeper 模式，KRaft 简化了架构、提升了元数据操作性能，并增强了集群的可扩展性。以下配置适用于 3 节点 KRaft 集群，实现了去 ZooKeeper 化，并具备了 SASL 认证能力。

Kafka 4.1.1 推荐使用 KRaft 模式（无 ZooKeeper），该配置适用于 3 节点 KRaft 集群，实现了去 ZooKeeper 化，并具备了 SASL 认证能力。

配置描述了一个 生产级、去 ZooKeeper 的 KRaft 集群，具备：

• 高可用：3 副本因子（需配合 Topic 创建时指定），可容忍 1~2 台故障。
• 基础安全：基于 SASL/SCRAM 的客户端与 broker 间认证，broker 间通信也认证。
• 网络分离：业务端口（9092）与控制端口（9093）独立。
• 内网部署 ：CONTROLLER 使用明文，SASL_PLAINTEXT 使用 SASL 但不加密，适合内网可信环境；如需传输加密应改为 SASL_SSL。

# kraft/server.properties
#指定当前 Kafka 进程同时扮演 broker 和 controller 两个角色
process.roles=broker,controller
#当前节点在集群中的唯一标识符（数字）
node.id=1
# 【关键】所有节点必须完全一致！列出所有Controller节点
#每个节点通过此配置知道所有 controller 节点的地址，用于 Raft 共识通信
controller.quorum.voters=1@kafka-node-01:9093,2@kafka-node-02:9093,3@kafka-node-03:9093
#用于 controller 之间 Raft 通信 的监听器名称
controller.listener.names=CONTROLLER
#SASL_PLAINTEXT://:9092：用于 客户端和 broker 之间的业务流量；CONTROLLER://:9093：用于 controller 之间的 Raft 内部通信
listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093
#broker 之间（数据复制） 使用的监听器名称
inter.broker.listener.name=SASL_PLAINTEXT
#将当前节点的 对外公布地址 注册到集群元数据中，供客户端和其他 broker 使用。
advertised.listeners=SASL_PLAINTEXT://kafka-node-01:9092
#将 监听器名称 映射到具体的安全协议，CONTROLLER → PLAINTEXT（无认证、无加密，内网专用），SASL_PLAINTEXT → SASL_PLAINTEXT（SASL 认证，但不加密）
listener.security.protocol.map=CONTROLLER:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT

# ====== SASL 配置 ======
sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512

优势：

• ✅ 简化架构，减少依赖
• ✅ 更快的元数据操作
• ✅ 更好的可扩展性
• ✅ 更低的延迟

1.3 Topic 配置最佳实践

Topic 是 Kafka 中消息的逻辑分类单元，合理的 Topic 配置对性能和数据管理至关重要。分区数决定并行度，副本数决定可用性，保留策略决定数据存储时长。以下示例展示了如何创建高可用 Topic，并提供了关键参数的说明。

# 创建高可用 Topic
/data/software/kafka_4.1.1/bin/kafka-topics.sh --create \
  --bootstrap-server kafka-node-01:9092 \
  --topic event_es_index \
  --partitions 6 \
  --replication-factor 3\ 
  --command-config /data/software/kafka_4.1.1/config/client-scram.properties

# 查看 Topic 配置
kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe \
  --topic event_es_index

关键参数说明（配置文件默认值已设置为合适值，没特殊需求可以直接写为默认值）：

• partitions: 根据吞吐量和并行度需求设置（建议 6-24）
• replication-factor: 生产环境至少 3
• min.insync.replicas: 设置为 replication-factor-1

---

2. 性能调优

2.1 Producer 优化

Producer（生产者）负责将消息发送到 Kafka 集群。优化 Producer 配置可以提升吞吐量、降低延迟，并确保数据可靠性。关键优化点包括批量发送、压缩算法、幂等性保证和超时控制。以下配置针对高吞吐场景进行了调优。

producer.properties 配置：

# producer.properties
bootstrap.servers = 172.16.130.3:9092,172.16.130.13:9092,172.16.130.15:9092
acks=all                                 # 消息发送需等待所有副本同步完成，最强数据一致性
retries=3                                # 发送失败最大重试次数，提升发送可靠性
batch.size=32768                         # 批量发送消息最大字节数，此处设定32KB
linger.ms=10                             # 发送线程空闲等待时长，等待10ms凑满批次再发送
buffer.memory=67108864                   # 生产者总发送缓冲区内存大小，配置为64MB
compression.type=lz4                     # 消息压缩算法选用LZ4，兼顾压缩速率与压缩比例
max.in.flight.requests.per.connection=5  # 单个连接中允许未确认的最大请求数，平衡吞吐与有序性
enable.idempotence=true                  # 开启生产者幂等性，杜绝网络重试造成消息重复
request.timeout.ms=30000                 # 单次消息请求响应超时时间，单位毫秒
delivery.timeout.ms=120000               # 消息整体投递最大超时时间，超时判定发送失败

性能调优要点：

• acks=all: 确保数据不丢失
• batch.size + linger.ms: 提高吞吐量
• compression.type: lz4 或 zstd（推荐）
• enable.idempotence: 防止重复消息

2.2 Consumer 优化

Consumer（消费者）负责从 Kafka 集群读取并处理消息。优化 Consumer 配置可以提升消费效率、减少 Rebalance 频率，并确保消息处理的精确性。关键优化点包括拉取策略、手动提交、超时控制和分区分配策略。以下配置针对稳定消费场景进行了调优。

consumer.properties 配置：

# consumer.properties

group.id=irs_task-group                  # 消费组唯一标识，同组内共享消费进度
auto.offset.reset=earliest               # 无偏移量时从最早消息开始消费
enable.auto.commit=false                 # 关闭自动提交，采用手动提交保证精确一次
max.poll.records=500                     # 单次 poll 拉取最大消息数，平衡处理效率与内存占用
max.poll.interval.ms=300000              # 两次 poll 间隔最大超时时间，超时触发 Rebalance
session.timeout.ms=30000                 # 消费者会话超时时间，超时判定消费者下线
heartbeat.interval.ms=10000              # 心跳发送间隔，需小于 session.timeout.ms 的 1/3
fetch.min.bytes=1                        # 最小拉取字节数，设为 1 表示有消息立即返回
fetch.max.wait.ms=500                    # 最大等待时长，凑够 fetch.min.bytes 或超时后返回
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor  # 使用协作式分配策略，减少 Rebalance 影响范围

消费组监控：

# 查看消费组 lag
/data/software/kafka_4.1.1/bin/kafka-consumer-groups.sh      --bootstrap-server 172.16.130.3:9092      --group canal_irs_group --describe     --command-config /data/software/kafka_4.1.1/config/client-scram.properties

2.3 Broker 性能调优

Broker 的性能直接影响整个 Kafka 集群的吞吐量和延迟。性能调优包括 JVM 参数优化、操作系统内核参数调整和磁盘 I/O 优化。合理的调优可以显著提升集群处理能力，降低 GC 停顿时间，并提高网络传输效率。

JVM 参数优化：

# kafka-server-start.sh
# JVM堆内存配置：-Xms和-Xmx均设为8GB，避免运行时动态调整带来的性能抖动
# GC调优参数：使用G1收集器，目标暂停时间20ms，堆使用率35%触发并发标记，System.gc()转为并发GC，方法内联层级15
export KAFKA_HEAP_OPTS="-Xms8g -Xmx8g"
export KAFKA_JVM_PERFORMANCE_OPTS="\
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=20 \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:+ExplicitGCInvokesConcurrent \
  -XX:MaxInlineLevel=15"

操作系统优化：

# /etc/sysctl.conf - 内核网络与内存参数优化
tee -a /etc/sysctl.conf << EOF
# 网络接收缓冲区默认大小 256KB，提升网络读取性能
net.core.rmem_default=262144
# 网络发送缓冲区默认大小 256KB，提升网络写入性能
net.core.wmem_default=262144
# 网络接收缓冲区最大值 16MB，应对突发流量
net.core.rmem_max=16777216
# 网络发送缓冲区最大值 16MB，应对突发流量
net.core.wmem_max=16777216
# TCP接收缓冲区最小值、默认值、最大值（4KB/85KB/16MB），自动调整
net.ipv4.tcp_rmem=4096 87380 16777216
# TCP发送缓冲区最小值、默认值、最大值（4KB/64KB/16MB），自动调整
net.ipv4.tcp_wmem=4096 65536 16777216
# 降低swap使用倾向，优先使用物理内存，减少GC停顿
vm.swappiness=1
EOF
# 应用配置
sysctl -p

# vim /etc/security/limits.conf - 文件句柄与进程数限制
# 所有用户软限制：最大打开文件数655350，满足高并发连接需求
* soft nofile 655350
# 所有用户硬限制：最大打开文件数655350
* hard nofile 655350

磁盘 I/O 优化：

• 使用 SSD 磁盘
• RAID 10 或 RAID 0（有备份情况下）
• 单独的磁盘用于日志和数据

---

3. 监控与告警

3.1 关键监控指标

监控是保障 Kafka 集群稳定运行的关键。通过采集 Broker、Topic 和 Consumer 的关键指标，可以及时发现问题并进行预警。以下列出了生产环境必须监控的核心指标，包括副本同步状态、控制器选举、网络吞吐和消费滞后等。

Broker 级别：

# Prometheus JMX Exporter 配置

# Under Replicated Partitions（未完全复制的分区）
kafka_server_replicamanager_underreplicatedpartitions > 0

# Active Controller Count（应为 1）
kafka_controller_kafkacontroller_activecontrollercount != 1

# Request Handler Idle Ratio（请求处理空闲率 < 0.3 告警）
kafka_network_requestmetrics_requestpersec{request="Produce"} 

# ISR Shrink Rate（ISR 收缩速率）
kafka_server_replicamanager_isrshrinkspersec

# Network Processor Idle Ratio
kafka_network_socketserver_networkprocessoravgidlepercent < 0.3

Topic/Partition 级别：

# Messages In Per Sec
kafka_server_brokertopicmetrics_messagesinpersec

# Bytes In/Out Per Sec
kafka_server_brokertopicmetrics_bytesinpersec
kafka_server_brokertopicmetrics_bytesoutpersec

# Log End Offset vs Current Offset (Consumer Lag)
kafka_consumer_group_lag

3.2 Grafana 监控面板

Grafana 提供了直观的可视化界面，可以将 Prometheus 采集的 Kafka 指标以图表形式展示。通过导入预置的面板模板，可以快速搭建完整的监控体系。以下推荐了三个核心面板，覆盖了集群概览、消费滞后和 JVM 性能监控。

推荐导入的面板 ID：

• Kafka Overview: ID 7589
• Kafka Consumer Lag: ID 14707
• JVM Metrics: ID 8563

关键告警规则：

# alertmanager.yml

groups:
  - name: kafka_alerts
    rules:
      - alert: KafkaUnderReplicatedPartitions
        expr: kafka_server_replicamanager_underreplicatedpartitions > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Kafka 存在未完全复制的分区"
          description: "Broker {{ $labels.instance }} 有 {{ $value }} 个未完全复制的分区"

      - alert: KafkaConsumerLagHigh
        expr: kafka_consumer_group_lag > 10000
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "消费者滞后过高"
          description: "消费组 {{ $labels.group }} 滞后 {{ $value }} 条消息"

      - alert: KafkaBrokerDown
        expr: up{job="kafka"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Kafka Broker 宕机"
          description: "Broker {{ $labels.instance }} 已宕机"

4. 常见问题排查

4.1 Producer 发送失败

Producer 发送失败是生产环境常见的问题，通常由网络异常、Broker 负载过高或配置不当引起。快速定位问题需要检查网络连接、Broker 状态和日志信息。以下提供了完整的排查流程和解决方案。

症状：

org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s)

排查步骤：

# 1. 检查 Broker 是否可达
telnet kafka-broker-1 9092

# 2. 检查 Topic 是否存在
kafka-topics.sh --bootstrap-server kafka-broker-1:9092 --list

# 3. 检查 Broker 负载
kafka-broker-api-versions.sh --bootstrap-server kafka-broker-1:9092

# 4. 查看 Broker 日志
tail -f /var/log/kafka/server.log | grep -i "timeout\|error"

# 5. 检查网络带宽
iftop -i eth0

解决方案：

• 增加 request.timeout.ms 和 delivery.timeout.ms
• 检查网络带宽和延迟
• 增加 Broker 数量分散负载
• 调整 batch.size 和 linger.ms

4.2 Consumer Lag 持续增长

Consumer Lag（消费滞后）是指消费者处理消息的速度跟不上生产者发送速度，导致未处理消息堆积。持续增长的 Lag 会导致数据延迟，甚至引发内存溢出。排查时需要检查消费者处理能力、GC 情况和业务逻辑耗时。

症状：

kafka-consumer-groups.sh --describe --group my-group
# LAG 持续增加

排查步骤：

# 1. 检查消费者状态
kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe \
  --group my-group

# 2. 检查消费者日志
tail -f /var/log/my-app/consumer.log

# 3. 检查处理耗时
# 在代码中添加监控
long startTime = System.currentTimeMillis();
// 处理逻辑
long processingTime = System.currentTimeMillis() - startTime;
logger.info("Processing time: {} ms", processingTime);

# 4. 检查 GC 情况
jstat -gcutil <pid> 1000

解决方案：

• 增加消费者实例数（不超过 partition 数）
• 优化消费逻辑，减少处理时间
• 增加 max.poll.records
• 增加 max.poll.interval.ms
• 检查是否有慢查询或阻塞操作

4.3 Broker 重启后数据丢失

Broker 重启后数据丢失是严重的数据一致性问题，通常由副本配置不当或非安全 Leader 选举引起。预防此类问题需要正确配置 acks、min.insync.replicas 和 unclean.leader.election.enable 参数。

症状：

• 重启后部分消息丢失
• Consumer 读取到旧数据

原因：

• acks 未设置为 all
• unclean.leader.election.enable=true
• min.insync.replicas 配置不当

预防措施：

# Broker 配置
unclean.leader.election.enable=false
min.insync.replicas=2

# Producer 配置
acks=all
enable.idempotence=true

# Topic 配置
kafka-configs.sh --bootstrap-server kafka-broker-1:9092 \
  --alter \
  --entity-type topics \
  --entity-name my-topic \
  --add-config min.insync.replicas=2

4.4 Rebalance 频繁发生

Rebalance（重平衡）是 Consumer Group 在成员变化或分区分配调整时触发的过程。频繁的 Rebalance 会导致消费中断、重复处理和性能下降。优化超时参数和使用协作式分配策略可以有效减少 Rebalance 频率。

症状：

org.apache.kafka.clients.consumer.CoordinatorNotAvailableException

原因：

• 消费者处理时间过长
• 网络不稳定
• 消费者频繁上下线

解决方案：

// 增加超时时间
props.put("session.timeout.ms", 30000);
props.put("heartbeat.interval.ms", 10000);
props.put("max.poll.interval.ms", 300000);

// 使用 CooperativeStickyAssignor（Kafka 2.4+）
props.put("partition.assignment.strategy", 
  "org.apache.kafka.clients.consumer.CooperativeStickyAssignor");

4.5 磁盘空间不足

Kafka 日志文件会持续增长，如果不及时清理或扩容，会导致磁盘空间耗尽，进而影响集群正常运行。监控磁盘使用率并制定合理的保留策略是预防此类问题的关键。

监控：

# 检查磁盘使用
df -h /data/kafka-logs

# 检查各 Topic 占用
du -sh /data/kafka-logs/* | sort -rh | head -20

解决方案：

# 1. 缩短保留时间
kafka-configs.sh --bootstrap-server kafka-broker-1:9092 \
  --alter \
  --entity-type topics \
  --entity-name my-topic \
  --add-config retention.ms=86400000  # 1 天

# 2. 启用日志压缩（适用于 key-value 场景）
kafka-configs.sh --alter \
  --entity-type topics \
  --entity-name my-topic \
  --add-config cleanup.policy=compact

# 3. 删除无用 Topic
kafka-topics.sh --delete --topic unused-topic

# 4. 扩容磁盘

---

5. 安全加固

5.1 SASL 认证

SASL（Simple Authentication and Security Layer）是 Kafka 提供的身份认证机制，可以防止未授权用户访问集群。SCRAM-SHA-512 是推荐的认证算法，提供了较高的安全性。以下配置展示了如何启用 SASL 认证并创建用户。

SASL/SCRAM 配置：

# 1. 创建用户
# 在任一节点，使用PLAINTEXT连接先创建用户（集群安全启用前操作）
/data/software/kafka_4.1.1/bin/kafka-configs.sh \
    --bootstrap-server kafka-node-01:9092 \
    --entity-type users --entity-name admin \
    --alter --add-config 'SCRAM-SHA-512=[password=xxx]'

# 2. 配置 JAAS
 cat > /data/software/kafka_4.1.1/config/kafka_server_jaas.conf << 'EOF'
KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="admin"
    password="xxx"; 
};
EOF
chmod 600 /data/software/kafka_4.1.1/config/kafka_server_jaas.conf

# 3. 启动 Broker
export KAFKA_OPTS="-Djava.security.auth.login.config=/data/software/kafka_4.1.1/config/kafka_server_jaas.conf"  
[worker@kafka-node-01 kafka_4.1.1]$ ./kafka-cluster-ctl.sh stop
[worker@kafka-node-01 kafka_4.1.1]$ ./kafka-cluster-ctl.sh start

客户端连接配置：

#01 添加连接配置
[worker@kafka-node-01 config]$ cat > client-scram.properties << 'EOF'
bootstrap.servers=kafka-node-01:9092,kafka-node-02:9092,kafka-node-03:9092
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
    username="admin" \
    password="xxx";
EOF
#02 连接测试
#01 测试列出Topic (最基本的连接和认证测试)
/data/software/kafka_4.1.1/bin/kafka-topics.sh --list \
    --bootstrap-server kafka-node-01:9092 \
    --command-config /data/software/kafka_4.1.1/config/client-scram.properties
    
#02 canal连接配置如下，主配置文件中配置 canal.properties
kafka.security.protocol=SASL_PLAINTEXT
kafka.sasl.mechanism=SCRAM-SHA-512
kafka.sasl.jaas.config = org.apache.kafka.common.security.scram.ScramLoginModule required username="kafka_canal" password="xxx";

5.2 ACL 权限控制

ACL（Access Control List）是 Kafka 的授权机制，用于控制用户对资源的访问权限。通过 ACL 可以实现多租户隔离、防止数据泄露和误操作。以下详细介绍了 ACL 的概念、组成部分和常用命令。

01 概念

简单来说，Kafka 的 ACL（Access Control List，访问控制列表） 机制，就是用来控制"谁"能对"什么资源"做"什么操作"。

它是 Kafka 实现授权 的核心。在配置了 SASL（身份认证）之后，ACL 就是决定"这个认证通过的用户，具体能干什么"的那把锁。你可以把它理解为文件系统的权限：只有拥有"读"权限的用户才能读取文件，只有拥有"写"权限的用户才能修改文件。

02 解决的问题

在生产环境中，ACL 可以实现多租户隔离和权限控制，防止数据泄露、误操作或恶意破坏。典型场景包括：

• 数据隔离 ：允许消费者应用（如 user_analytics） 读取 user-events 主题，但禁止它写入或删除该主题。
• 操作隔离 ：只允许管理员用户（如 admin） 创建或删除主题，普通用户只能生产或消费数据。
• 应用隔离 ：允许 App1（consumer_app1）消费 topicA，同时禁止 App2（consumer_app2）消费同一个主题。

03 ACL组成部分

一个完整的 ACL 规则由这四个部分构成：

• 主体 (Principal) ：就是 "谁" 。通常是经过 SASL 认证的用户名（例如 User:alice）。
• 资源 (Resource) ：就是 "什么对象" 。Kafka 支持多种资源类型：
  • Topic：最常用，控制对消息主题的访问。
  • Group：控制对消费者组（Consumer Group）的访问。
  • Cluster：控制集群级别操作（如查看元数据、管理分区）。
• 操作 (Operation) ：就是 "做什么" 。例如：Read（读）、Write（写）、Create（创建）、Delete（删除）、Alter（修改）、Describe（查看描述）等。
• 权限类型 (Permission Type) ：主要是 Allow（允许） 和 Deny（拒绝）

04 常用命令

# 允许用户 production-app 向 topic orders-topic 发送消息
/data/software/kafka_4.1.1/bin/kafka-acls.sh  \
  --bootstrap-server kafka-node-01:9092 \
  --add \
  --allow-principal User:kafka_canal\
  --operation Write \
  --topic irs_task-topic

# 允许用户 analytics-app 从 topic orders-topic 消费
/data/software/kafka_4.1.1/bin/kafka-acls.sh \
  --bootstrap-server kafka-node-01:9092 \
  --add \
  --allow-principal User:kafka-ui \
  --operation Read \
  --topic irs_task-topic \
  --group irs_task-group

# 查看 ACL
/data/software/kafka_4.1.1/bin/kafka-acls.sh --list \
   --bootstrap-server kafka-node-01:9092 \
   --command-config /data/software/kafka_4.1.1/config/client-scram.properties

启用 ACL：

# server.properties
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:admin

---

总而言之，ACL 是 Kafka 在生产环境中实现安全隔离和数据合规的基石。它让你能精细地控制每个应用对数据的访问权限，是构建一个安全、稳定、多租户 Kafka 集群的必备组件。

6. 运维操作规范

6.1 滚动升级

滚动升级是在不影响集群服务的前提下，逐个升级 Broker 节点的过程。正确的升级流程可以避免数据丢失和服务中断。以下提供了详细的升级步骤和注意事项。

升级步骤：

# 1. 准备新版本
wget https://downloads.apache.org/kafka/4.1.1/kafka_2.13-4.1.1.tgz
tar -xzf kafka_2.13-4.1.1.tgz

# 2. 逐个升级 Broker（每次一个）

# Broker 1: 停止服务
systemctl stop kafka

# 备份配置
cp -r /etc/kafka /etc/kafka.backup

# 替换二进制文件
rm -rf /opt/kafka
mv kafka_2.13-4.1.1 /opt/kafka

# 恢复配置
cp /etc/kafka.backup/server.properties /opt/kafka/config/

# 启动服务
systemctl start kafka

# 3. 验证 Broker 加入集群
kafka-broker-api-versions.sh --bootstrap-server kafka-broker-1:9092

# 4. 等待 ISR 完全同步
watch -n 5 'kafka-topics.sh --describe | grep Isr'

# 5. 继续下一个 Broker

注意事项：

• ⚠️ 确保 unclean.leader.election.enable=false
• ⚠️ 等待 ISR 完全同步后再升级下一个
• ⚠️ 先在测试环境验证
• ⚠️ 准备好回滚方案

6.2 扩容操作

当集群负载过高或存储不足时，需要添加新的 Broker 节点进行扩容。扩容后需要重新分配分区以平衡负载。以下展示了如何添加新 Broker 并执行分区重分配。

添加新 Broker：

# 1. 安装并启动新 Broker
# 配置新的 broker.id

# 2. 重新分配分区
cat > topics-to-move.json << EOF
{
  "topics": [
    {"topic": "orders-topic"},
    {"topic": "payments-topic"}
  ],
  "version": 1
}
EOF

# 3. 生成分配计划
kafka-reassign-partitions.sh --bootstrap-server kafka-broker-1:9092 \
  --topics-to-move-json-file topics-to-move.json \
  --broker-list "1,2,3,4" \
  --generate

# 4. 执行重新分配
kafka-reassign-partitions.sh --bootstrap-server kafka-broker-1:9092 \
  --reassignment-json-file reassignment.json \
  --execute

# 5. 验证进度
kafka-reassign-partitions.sh --bootstrap-server kafka-broker-1:9092 \
  --reassignment-json-file reassignment.json \
  --verify

6.3 备份与恢复

定期备份是保障数据安全的重要措施。Kafka 的备份包括元数据备份和 Topic 数据备份。以下提供了 KRaft 模式下的备份和恢复流程。

元数据备份：

# KRaft 模式
# 备份元数据目录
tar czf kafka-metadata-backup-$(date +%Y%m%d).tar.gz /data/kafka-metadata/

# ZooKeeper 模式
# 备份 ZooKeeper 数据
tar czf zk-data-backup-$(date +%Y%m%d).tar.gz /data/zookeeper/

Topic 数据备份：

# 使用 MirrorMaker 备份到另一个集群
# 或使用 kafka-console-consumer + 文件存储

# 导出 Topic 数据
kafka-console-consumer.sh --bootstrap-server kafka-broker-1:9092 \
  --topic orders-topic \
  --from-beginning \
  --timeout-ms 60000 > orders-topic-backup.json

恢复流程：

# 1. 恢复元数据
tar xzf kafka-metadata-backup-20260514.tar.gz -C /

# 2. 重建 Topic
kafka-topics.sh --create --topic orders-topic --partitions 12 --replication-factor 3

# 3. 导入数据
kafka-console-producer.sh --bootstrap-server kafka-broker-1:9092 \
  --topic orders-topic < orders-topic-backup.json

6.4 日常巡检清单

定期巡检可以及时发现潜在问题，保障集群稳定运行。以下提供了每日、每周和每月的巡检清单，涵盖了 Broker 状态、副本同步、消费滞后、磁盘空间和错误日志等关键检查项。

每日检查：

#!/bin/bash
# daily-check.sh

echo "=== Kafka 日常巡检 ==="
echo ""

# 1. 检查 Broker 状态
echo "1. Broker 状态:"
kafka-broker-api-versions.sh --bootstrap-server kafka-broker-1:9092 | grep "broker.id"

# 2. 检查 Under Replicated Partitions
echo ""
echo "2. Under Replicated Partitions:"
kafka-topics.sh --describe --under-replicated-partitions --bootstrap-server kafka-broker-1:9092

# 3. 检查 Consumer Lag
echo ""
echo "3. Consumer Lag (Top 10):"
kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --all-groups --describe | awk '$6 > 100 {print}' | sort -k6 -rn | head -10

# 4. 检查磁盘空间
echo ""
echo "4. 磁盘使用:"
df -h /data/kafka-logs

# 5. 检查错误日志
echo ""
echo "5. 最近错误日志:"
tail -100 /var/log/kafka/server.log | grep -i "error\|exception" | tail -10

echo ""
echo "=== 巡检完成 ==="

每周检查：

• 审查告警记录
• 检查 Topic 增长趋势
• 验证备份完整性
• 清理过期日志
• 更新监控面板

每月检查：

• 执行故障转移演练
• 性能基准测试
• 安全审计（ACL、证书有效期）
• 容量规划评估
• 版本升级评估

---

7. 快速参考命令

本节汇总了 Kafka 日常运维中常用的管理命令和性能测试工具，方便快速查阅和执行。所有命令均已针对 SASL 认证环境进行了适配。

7.1 常用管理命令

# Topic 管理
kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --describe --topic my-topic
kafka-topics.sh --create --topic my-topic --partitions 6 --replication-factor 3
kafka-topics.sh --delete --topic my-topic

# Consumer Group 管理
kafka-consumer-groups.sh --list
kafka-consumer-groups.sh --describe --group my-group
kafka-consumer-groups.sh --reset-offsets --group my-group --to-latest --execute

# 配置管理
kafka-configs.sh --describe --entity-type topics --entity-name my-topic
kafka-configs.sh --alter --entity-type topics --entity-name my-topic --add-config retention.ms=86400000

# 分区重分配
kafka-reassign-partitions.sh --generate --topics-to-move-json-file topics.json --broker-list "1,2,3"
kafka-reassign-partitions.sh --execute --reassignment-json-file reassignment.json
kafka-reassign-partitions.sh --verify --reassignment-json-file reassignment.json

# 首选副本选举
kafka-leader-election.sh --election-type preferred --all-topic-partitions

# 日志目录管理
kafka-log-dirs.sh --describe --broker-list 1,2,3

# 集群信息
kafka-metadata.sh --snapshot /data/kafka-metadata/__cluster_metadata-0/00000000000000000000.log --command "broker-list"

7.2 性能测试工具

Kafka 提供了内置的性能测试工具，可以评估集群的吞吐量和延迟。在进行容量规划或调优后，建议使用这些工具进行基准测试。

# Producer 性能测试
kafka-producer-perf-test.sh \
  --topic test-topic \
  --num-records 1000000 \
  --record-size 1024 \
  --throughput -1 \
  --producer-props bootstrap.servers=kafka-broker-1:9092 acks=all

# Consumer 性能测试
kafka-consumer-perf-test.sh \
  --topic test-topic \
  --messages 1000000 \
  --broker-list kafka-broker-1:9092 \
  --group test-group

---

8.总结

Kafka 4.1.1 生产环境运维的关键要点：

✅ 配置最佳实践：

• 使用 KRaft 模式替代 ZooKeeper
• replication-factor=3, min.insync.replicas=2
• unclean.leader.election.enable=false

✅ 性能调优：

• Producer: batch.size + linger.ms + compression
• Consumer: max.poll.records + 手动提交
• Broker: G1GC + 合适的堆大小

✅ 监控告警：

• Under Replicated Partitions
• Consumer Lag
• Broker 可用性
• 磁盘空间

✅ 安全保障：

• SASL 认证
• ACL 权限控制