Kafka4.x配置详解
server.properties
xml
# 服务器的角色，设置此项表示启用 KRaft 模式。
# Kafka 4.x 已删除 ZooKeeper，Kafka 进程可以具有两种角色：
## broker：正常的数据、topic、分区服务
## controller：管理集群元数据（替代 ZooKeeper）
# 注意：如果是多节点集群至少需要 1 个 controller 节点：process.roles=broker,controller
process.roles=broker
# KRaft 模式下，node.id 替代了旧的 broker.id。需保证唯一
node.id=2
# 这定义了 controller quorum（类似 ZooKeeper 的职责）节点地址。
## 但 broker-only 节点只需要这个简单配置，实际 controller 节点必须使用
## controller.listener.names=CONTROLLER
# 集群部署中必须配置多个 controller 节点
## controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093
controller.quorum.bootstrap.servers=localhost:9093
############################# Socket Server Settings #############################
# 指定 Socket 服务监听的地址
# Kafka 为不同协议提供多个 Listener，例如：PLAINTEXT、SSL、SASL_SSL、CONTROLLER（KRaft 特有）
# 生产环境推荐使用：
## 1.内部 broker 通信：INTERNAL 2.外部客户端连接：CLIENT 3.Control plane：CONTROLLER
# 注意：如果主机名为0.0.0.0，那么将绑定所以的网络接口地址；若主机名为空，则绑定默认的网络接口地址；如果端口地址小于1024，则必须使用root权限启动Kafka（不建议端口小于1024）.
# 推荐：应设置成内网 IP 或 0.0.0.0
listeners=PLAINTEXT://localhost:9092
# Broker 之间内部通信使用的 listener 名称。
# 必须是 listeners= 中定义的一个 listener
inter.broker.listener.name=PLAINTEXT
# Broker 对外暴露给客户端的访问地址。
# 对容器、K8s、生产环境非常关键，必须是客户端能访问到的地址（不能用 localhost）
advertised.listeners=PLAINTEXT://localhost:9092
# 控制器使用的监听列表。
## 注意：如果是纯 broker 节点：不会用到 CONTROLLER；controller 节点必须配置 CONTROLLER 监听端口；
controller.listener.names=CONTROLLER
# 监听器与安全协议映射。
# 如果没有为监听器（listeners=localhost:9092）指定安全协议，则还需要额外配置以下的参数
## 安全协议PLAINTEXT、SSL、SASL_SSL、CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
# 网络线程数，默认足够，流量高可调大
num.network.threads=3
# IO 请求线程数，与磁盘数量相关（物理上独立的存储设备数量（非文件夹之类的））
## 设置应大致等于或略大于 Broker 所使用的物理磁盘数量
## 每个 I/O 线程可以并行处理一个磁盘的 I/O 请求
### Kafka 的日志（log）数据通常分布在多个磁盘上（通过配置 log.dirs 指定多个目录，每个目录挂载在不同物理磁盘上）
### 如果你有 N 块物理磁盘，并且 Kafka 的日志目录分别位于这些磁盘上，那么理论上你可以并行地对这 N 块磁盘进行读写。
### 如果 num.io.threads < 磁盘数，则某些磁盘可能需要排队等待 I/O 线程，无法充分利用磁盘并行能力。
### 如果 num.io.threads > 磁盘数，虽然不会出错，但额外的线程可能处于空闲状态，浪费资源（不过影响通常不大）
## 避免 I/O 成为瓶颈
### Kafka 是高吞吐系统，其性能受限于磁盘 I/O 能力。
### 设置合适的 num.io.threads 可以让 Kafka 充分利用多磁盘的并发 I/O 能力，提升整体吞吐量。
num.io.threads=8
# 发送缓冲区
## TCP 缓冲区的理想大小 ≈ 带宽 × 往返延迟（RTT）
### 本地局域网（低延迟，<1ms） 128 KB ~ 256 KB（131072 ~ 262144）
### 跨机房/云环境（RTT 1~10ms） 1 MB ~ 2 MB（1048576 ~ 2097152）
### 高带宽长距离（如跨区域） 2 MB ~ 4 MB（2097152 ~ 4194304）
# 注意：操作系统对 socket buffer 有最大限制（可通过 net.core.wmem_max 查看），需确保 Kafka 设置不超过系统上限。
socket.send.buffer.bytes=102400
# 接收缓冲区
# 推荐与socket.send.buffer.bytes设为相同值
# 特殊情况下
## 写多读少（如日志收集） receive > send（如 2MB vs 1MB）
## 读多写少（如实时数仓消费） send > receive（如 2MB vs 1MB）
## 副本同步压力大（多副本、跨机房） 两者都调高（因 Leader ↔ Follower 双向通信）
socket.receive.buffer.bytes=102400
# 最大请求大小，保护 Broker 不被大消息打垮
# 必须 ≥ message.max.bytes 和 replica.fetch.max.bytes
## message.max.bytes（Broker）单条消息最大大小（Producer 端需 ≤ 此值）
## replica.fetch.max.bytes Follower 拉取副本时单次请求最大字节数
## fetch.max.bytes（Consumer） Consumer 单次拉取最大字节数
socket.request.max.bytes=104857600
############################# Log Basics #############################
# 日志文件存储目录。
## 1.必须配置成独立磁盘路径，生产不要用 /tmp！ 2.多目录用逗号分隔
# 如果指定了多个路径，那么broker会根据"最少使用"原则，把同一分区的日志片段保存到同一个路径下。
# 注意：broker会向数量最少的目录新增分区，而不是向可用磁盘空间最小的目录新增分区，所以并不能保证数据会被均衡地分布在多个目录中
log.dirs=/data/kafka1,/data/kafka2
# 创建 Topic 的默认分区数
# 注意：可以增加主题的分区，不能减少
# 通过分区来实现集群的负载均衡，分区数量设置为集群broker数量或倍数，这样可以让分区均衡地分布到broker上
num.partitions=1
# Kafka使用线程池来处理日志片段，影响 Kafka "冷启动"或"故障恢复"的速度
## 当服务器启动时，用于打开每个分区的日志片段；
## 当服务器奔溃并重启时，用于检查和截短每个分区的日志片段（快速恢复已刷盘但未完全提交的状态）
## 当服务器正常关闭时，用于关闭日志片段。
# 总恢复线程数 = num.recovery.threads.per.data.dir × log.dirs
num.recovery.threads.per.data.dir=1
############################# Internal Topic Settings #############################
# 消费者 offset 主题 副本数，生产必须 ≥3
offsets.topic.replication.factor=1
# 事务日志副本，生产必须 ≥3
transaction.state.log.replication.factor=1
# 事务 ISR 最小副本，必须比 replication.factor 小 1
transaction.state.log.min.isr=1
# 用于支持多消费者共享消费同一个分区（类似 RocketMQ 的集群消费模式）
# 设置内部状态 Topic __share_group_state 的副本数，决定该 Topic 在多少个 Broker 上保存副本。
share.coordinator.state.topic.replication.factor=1
# 设置该内部 Topic 写入时要求的最小 ISR（In-Sync Replicas）数量。如果 ISR 数量 < 此值，写入会失败（抛出 NotEnoughReplicasException）
share.coordinator.state.topic.min.isr=1
############################# Log Flush Policy #############################
# Kafka Broker 中控制 日志刷盘（flush）频率
## Long.MaxValue（≈永不按条数刷），每个分区累计达到 N 条消息后，强制刷盘
## null（依赖 OS 默认策略），每个分区距离上次刷盘超过 N 毫秒后，强制刷盘
## Kafka 默认不主动刷盘，而是依赖操作系统的 Page Cache + 后台 flush 机制（通常 30 秒一次）。这两个参数用于覆盖默认行为，强制更频繁刷盘。
# 潜在问题：性能下降，fsync() 是昂贵的同步 I/O 操作，会阻塞写入线程；每秒刷一次对高吞吐场景（如 >10MB/s）会造成显著瓶颈。
# 收益有限：现代操作系统和文件系统（ext4/XFS + journal）已提供强可靠性；Kafka 副本机制（replication）本身就能容忍单机宕机，刷盘并非唯一保障。
# 推荐不配置
#log.flush.interval.messages=10000
#log.flush.interval.ms=1000
############################# Log Retention Policy #############################
# 用于控制 Topic 日志的保留策略
## 按时间保留：消息写入后超过 N 小时即标记为可删除
log.retention.hours=168
# 按大小保留：分区总大小超过 N 字节后，删除最旧的日志段
# 原则 1：优先使用时间保留，谨慎使用字节保留
# 原则 2：如需限制磁盘空间，应通过监控 + 告警 + 扩容解决，而非强制删数据
# 原则 3：如果必须设置 log.retention.bytes，请按分区计算合理值
# 原则 4：不同 Topic 应差异化配置
#log.retention.bytes=1073741824
# 影响Kafka的 存储效率、I/O 性能、恢复速度和磁盘管理。
## 一旦日志片段被关闭，就开始进入过期倒计时。这个参数的值越小，关闭和分配新文件就会越频繁，从而降低整体的磁盘写入效率（日志片段被关闭之前消息是不会过期的）
# 日志段（Log Segment）的大小，每个日志段（.log 文件）的最大字节数。每当segment写满，Kafka就会关闭它并创建新的segment
# 每个 segment 对应一组文件：.log（数据）、.index（偏移索引）、.timeindex（时间戳索引）
## 1 GiB 适合大多数生产场景
log.segment.bytes=1073741824
# 保留策略检查频率
# Broker 检查是否需要删除过期/超量日志段的频率。
log.retention.check.interval.ms=300000
## 即使消息已过期，只要所在 segment 未 closed（未写满），就不会被删除。
## 日志片段的大小也会影响时间戳获取偏移量的行为。当使用时间戳获取日志偏移量时，Kafka会查找在指定时间戳写入的日志片段文件，也就是创建时间在指定时间戳之前且最后修改时间在指定时间戳之后的文件。然后，Kafka会返回这个日志片段开发的偏移量（也就是文件名）。broker.properties
xml
# 该服务器的角色。设置它将使 Kafka 进入 KRaft 模式。
process.roles=broker
# 与该实例角色关联的节点 ID。
node.id=2
# KRaft 控制器法定数（quorum）的引导服务器列表。
## Broker 启动时通过此地址找到 Controller 集群
controller.quorum.bootstrap.servers=localhost:9093
############################# Socket Server Settings #############################
# Broker 监听的地址。
listeners=PLAINTEXT://localhost:9092
# Broker 之间通信使用的监听名称。决定 Broker 内部复制与协调时用哪个 listener
inter.broker.listener.name=PLAINTEXT
# Listener name, hostname and port the broker will advertise to clients.
# If not set, it uses the value for "listeners".
advertised.listeners=PLAINTEXT://localhost:9092
# 控制器使用的监听器名称集合。Controller 与 Broker 之间通信使用 CONTROLLER listener;在纯 broker 节点仅使用第一个值
controller.listener.names=CONTROLLER
# 监听器名称到安全协议的映射表。指定 listener 使用的安全协议，如 PLAINTEXT、SSL、SASL
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
# 处理网络请求的线程数。
num.network.threads=3
# 处理磁盘 I/O 和请求逻辑。
num.io.threads=8
# Socket 缓冲区大小
socket.send.buffer.bytes=102400
# 每个请求最大
## 如果消息大于 10MB，建议避免使用 Kafka
## 若必须处理大消息，建议加大为 200MB+
socket.receive.buffer.bytes=102400
# 每个请求最大
socket.request.max.bytes=104857600
############################# Log Basics #############################
# 存放 Kafka 数据文件的目录
log.dirs=/tmp/kraft-broker-logs
# 默认创建 Topic 的分区数
num.partitions=1
# 启动重建日志 segment 的线程
num.recovery.threads.per.data.dir=1
############################# Internal Topic Settings #############################
# 系统主题的副本因子
offsets.topic.replication.factor=1
# 消费者 offset 的副本数
transaction.state.log.replication.factor=1
# 事务状态日志副本数
transaction.state.log.min.isr=1
share.coordinator.state.topic.replication.factor=1
share.coordinator.state.topic.min.isr=1
############################# Log Flush Policy #############################
# 多少条消息后触发刷盘
#log.flush.interval.messages=10000
# 消息在 log 中停留多久必须刷盘。
#log.flush.interval.ms=1000
############################# Log Retention Policy #############################
# 日志保留时间段
log.retention.hours=168
# 按大小清理
#log.retention.bytes=1073741824
# 每个segment最大值
log.segment.bytes=1073741824
# 每 5 分钟检查一次过期 segment。
log.retention.check.interval.ms=300000consumer.properties
xml
# 同一个 group.id 下的所有 consumer 共同消费同一组分区，即：每条消息只会被这个 group 中的一个 consumer 接收。
group.id=test-consumer-group
# 当该 group 在某个分区上：没有已提交 offset；或者 offset 已经过期 / 被删除时，Kafka 决定 从哪里开始消费。
## 推荐：数据仓库 / Snowflake / 大屏 / 报表型：auto.offset.reset=earliest
## 实时通知 / 风控 / 推送型：auto.offset.reset=latest
#auto.offset.reset=
# 当没有已提交 offset 时，从哪里开始消费：earliest / latest / none
# 历史+实时都要：earliest
# 只要新数据：latest
# auto.offset.reset=earliest
# key 反序列化类
# key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
# value 反序列化类
# value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
# 是否自动定期提交 offset
# enable.auto.commit=true
# 自动提交间隔（毫秒），仅在 enable.auto.commit=true 时生效
# auto.commit.interval.ms=5000
# 是否自动定期提交 offset
# enable.auto.commit=true
# 自动提交间隔（毫秒），仅在 enable.auto.commit=true 时生效
# auto.commit.interval.ms=5000
# 单次 poll 最大返回多少条记录
# max.poll.records=500
# 允许应用处理一批消息的最长时间
# 超过该时间还没 poll，下次会被认为挂了，触发 rebalance
# max.poll.interval.ms=300000 # 5 分钟
# consumer 与 broker 的会话超时时间
# session.timeout.ms=10000
# 心跳间隔（必须小于 session.timeout.ms）
# heartbeat.interval.ms=3000
# 单个分区一次 fetch 的最小字节数（可提高批量效率）
# fetch.min.bytes=1
# fetch 调用等待的最长时间（配合 fetch.min.bytes）
# fetch.max.wait.ms=500
# 单次 fetch 返回数据的最大总字节数（必须 >= broker 的 message.max.bytes）
# fetch.max.bytes=52428800 # 50MB
# 如果要保证只读已提交的事务消息，使用 read_committed
# isolation.level=read_committedproducer.properties
xml
bootstrap.servers=localhost:9092
# producer 将 record batch 先压缩 → 再发送给 broker
# broker 按原样存储该压缩数据 → consumer 拉取时解压
# 压缩的目标：减小网络带宽、磁盘占用，提高整体吞吐。
## none ： 不压缩，CPU 开销最小；网络和磁盘占用最大
## gzip ： 压缩率高，但 CPU 开销大、延迟高；适合离线批处理、日志归档
## snappy ： 压缩比 & CPU 开销平衡比较好；被很多老项目用作默认
## lz4 ： 压缩速度快、解压快，压缩率也不错；非常适合高吞吐在线流处理
## zstd ： 新一代算法，压缩率好，性能也不错（Kafka 新版本里推荐）
compression.type=none
# batch 大小和 linger 增大一点提高吞吐
# batch.size=32768
# linger.ms=10
# key/value 序列化
# key.serializer=org.apache.kafka.common.serialization.StringSerializer
# value.serializer=org.apache.kafka.common.serialization.StringSerializer