4. 环境准备与集群部署：压测环境硬件选型建议、Kafka集群参数调优、ZooKeeper/KRaft模式选择
本章聚焦于搭建一套可用于吞吐量压测与分布式事务验证的 Kafka 集群。我们将从硬件选型、集群参数调优、元数据管理模式选择三个维度展开，确保后续压测结果具备可重复性与参考价值。
4.1 压测环境硬件选型建议
压测环境的硬件配置直接影响测试结果的真实性。建议遵循“瓶颈不在被测系统”原则，即客户端与网络资源应足够充裕，使压力能够真正施加到 Kafka Broker 上。
| 组件 | 推荐配置 | 说明 |
|---|---|---|
| Broker 节点 CPU | ≥ 8 核 (物理核优先) | Kafka 对 CPU 要求中等，但压缩、解压缩及请求处理线程需要多核支持。 |
| Broker 节点内存 | ≥ 32 GB | 操作系统页缓存是 Kafka 高性能的核心，建议预留 16-24 GB 用于页缓存。 |
| 磁盘 | ≥ 2 块 NVMe SSD (RAID 0 或 JBOD) | 顺序读写场景下，SSD 延迟远低于 HDD；建议数据与日志分离。 |
| 网络 | ≥ 10 GbE | 压测时网络吞吐常成为瓶颈，10GbE 是保证万兆吞吐的基础。 |
| 压测客户端 | 独立机器，配置不低于 Broker | 避免客户端资源争抢导致压测结果失真。 |
实践建议： 若使用云服务器，优先选择 IO 优化型 实例，并开启 预配置 IOPS。磁盘延迟应控制在 2ms 以内，否则压测曲线会出现明显抖动。
4.2 Kafka 集群核心参数调优
以下参数直接影响吞吐量、数据可靠性与存储效率。调优前需明确压测目标：是追求极致吞吐，还是模拟生产环境的事务一致性场景。
4.2.1 num.partitions —— 分区数
- 作用： 决定 Topic 的并行度上限。每个分区只能被一个消费者实例消费。
- 压测建议： 分区数应 ≥ Broker 数 × 消费者线程数。例如 3 个 Broker，每个 Broker 运行 4 个消费者线程，则分区数建议 ≥ 12。
- 注意： 分区过多会增加 Leader 选举耗时和文件句柄开销，建议单 Broker 分区数不超过 2000。
4.2.2 replication.factor —— 副本因子
- 作用： 控制数据冗余度。RF=3 可容忍 2 个副本故障。
- 压测建议： 纯压测场景可设为 1 以消除副本同步开销；事务场景建议设为 3 并配合
min.insync.replicas=2。 - 性能影响： 每增加一个副本，生产者需等待更多副本确认，吞吐量约下降 15%-25%。
4.2.3 log.segment.bytes —— 日志段大小
- 作用： 控制单个日志文件的大小，触发滚动后旧段可被清理或压缩。
- 压测建议： 默认 1GB 适合大多数场景。若消息体较大（>100KB），可调至 512MB 以减少滚动频率。
- 关联参数：
log.retention.bytes和log.retention.hours需同步调整，避免磁盘写满。
4.2.4 其他关键参数速查表
| 参数名 | 推荐值（压测） | 推荐值（事务） |
|---|---|---|
num.network.threads |
8 | 8 |
num.io.threads |
16 | 16 |
socket.send.buffer.bytes |
1024 × 1024 | 1024 × 1024 |
socket.receive.buffer.bytes |
1024 × 1024 | 1024 × 1024 |
queued.max.requests |
500 | 500 |
fetch.message.max.bytes |
10485760 | 10485760 |
replica.fetch.max.bytes |
10485760 | 10485760 |
log.flush.interval.messages |
Long.MAX_VALUE | 10000 |
log.flush.interval.ms |
Long.MAX_VALUE | 1000 |
避坑提醒： 压测时不要开启
unclean.leader.election.enable=true，否则可能因 ISR 列表不完整导致数据不一致，干扰事务场景测试。
4.3 ZooKeeper 与 KRaft 模式选择
Kafka 2.8 开始引入 KRaft 模式，旨在移除对 ZooKeeper 的依赖。截至 Kafka 3.x，KRaft 已可用于生产环境，但 ZooKeeper 模式仍广泛存在。下表对比两种模式在压测与事务场景下的差异。
| 对比维度 | ZooKeeper 模式 | KRaft 模式 |
|---|---|---|
| 元数据存储 | 外部 ZooKeeper 集群 | Kafka 内部 Raft 日志 |
| 部署复杂度 | 需额外维护 ZK 集群（至少 3 节点） | 仅需 Kafka 节点，统一运维 |
| Controller 选举 | 依赖 ZK 临时节点与 Watch | 基于 Raft 协议，选举更快 |
| 压测影响 | 元数据操作（创建 Topic、分区重分配）受 ZK 性能制约 | 元数据操作延迟更低，适合频繁变更的场景 |
| 事务支持 | 成熟稳定，生产验证充分 | Kafka 3.x 已支持，但部分旧客户端不兼容 |
| 推荐场景 | 存量系统、对稳定性要求极高的生产环境 | 新项目、容器化部署、希望简化架构的团队 |
选型结论： 本课程压测环境推荐使用 KRaft 模式（Kafka 3.5+），以减少组件数量，便于后续在 Docker Compose 或 Kubernetes 中快速重建集群。若你所在团队仍使用 ZooKeeper 模式，课程中的参数调优与压测方法同样适用，仅需额外关注 ZK 的 JVM 堆大小与磁盘 IO。
4.4 集群部署架构示意
下图展示了一个 3 节点 KRaft 模式 Kafka 集群的部署架构，包含压测客户端与监控组件的关系。
4.5 快速部署参考（KRaft 模式）
以下为 3 节点 KRaft 集群的 server.properties 核心配置片段，可直接用于压测环境。
# 每个 Broker 唯一 ID
broker.id=1
# KRaft 模式必须配置
process.roles=broker,controller
node.id=1
# 所有节点一致的 controller 列表
controller.quorum.voters=1@192.168.1.10:9093,2@192.168.1.11:9093,3@192.168.1.12:9093
# 监听地址
listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
advertised.listeners=PLAINTEXT://192.168.1.10:9092
# 日志目录
log.dirs=/data/kafka/logs
# 分区与副本
num.partitions=12
default.replication.factor=3
min.insync.replicas=2
# 日志段
log.segment.bytes=1073741824
log.retention.hours=72
# 网络与 IO
num.network.threads=8
num.io.threads=16
# 事务相关
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
启动顺序： KRaft 模式首次启动需执行
bin/kafka-storage.sh format -t <uuid> -c config/server.properties 格式化存储。所有节点格式化完成后，依次启动即可自动完成 Controller 选举。