2. Kafka环境搭建与基础配置：单节点与集群部署、关键配置参数、JMX监控开启
好，咱们直接动手。这一章我带你从零搭一套Kafka环境。单节点、集群、关键参数、JMX监控，一步到位。我自己带团队时，新人入职第一周就是过这套流程——搞懂了这些，后面数据治理的管道搭建才不会跑偏。
2.1 单节点部署：先跑起来再说
单节点部署说白了就是本地开发环境。我习惯先用它验证配置、跑通流程，再上集群。你想想看，如果单节点都跑不稳，集群只会更乱。
前置条件：JDK 8+、ZooKeeper（Kafka 2.8+ 虽支持KRaft模式，但生产上我仍推荐ZK模式，更成熟）。
步骤：
- 下载解压：
wget https://downloads.apache.org/kafka/3.5.0/kafka_2.13-3.5.0.tgz，解压到/opt/kafka。 - 启动ZooKeeper：
bin/zookeeper-server-start.sh config/zookeeper.properties。 - 启动Kafka：
bin/kafka-server-start.sh config/server.properties。
验证一下：
# 创建测试topic
bin/kafka-topics.sh --create --topic test-topic --bootstrap-server localhost:9092 --partitions 1 --replication-factor 1
# 查看topic列表
bin/kafka-topics.sh --list --bootstrap-server localhost:9092看到 test-topic 输出，说明单节点跑通了。
2.2 集群部署：三节点起步
生产环境我至少用三节点。为什么？你想想看，如果只有两个节点，挂一个就剩单点，脑裂风险高。三节点能容忍一台故障，还能保证多数投票。
集群规划：
| 节点 | IP | broker.id | 端口 |
|---|---|---|---|
| broker-1 | 192.168.1.10 | 1 | 9092 |
| broker-2 | 192.168.1.11 | 2 | 9092 |
| broker-3 | 192.168.1.12 | 3 | 9092 |
关键配置差异：每个节点的 server.properties 中，broker.id 必须唯一，listeners 指向本机IP，zookeeper.connect 指向同一ZK集群。
# broker-1 的 server.properties 核心配置
broker.id=1
listeners=PLAINTEXT://192.168.1.10:9092
log.dirs=/data/kafka/logs
zookeeper.connect=192.168.1.10:2181,192.168.1.11:2181,192.168.1.12:2181broker.id 都配成了0。结果启动后只有最后一个节点注册成功，前两个一直报错。每个节点的ID必须全局唯一。
启动集群后，用 kafka-broker-api-versions.sh 检查各节点是否都在线。
2.3 关键配置参数：这两个参数决定数据生死
配置参数很多，但数据治理场景下，有两个参数你必须吃透。我每次做架构评审，必问这两个值。
2.3.1 log.retention.hours
这个参数控制数据保留时长。默认168小时（7天）。数据治理中，合规要求可能让你保留30天、90天甚至更久。
配置方式：
# 全局配置（server.properties）
log.retention.hours=720 # 30天
# topic级别覆盖（创建时指定）
bin/kafka-topics.sh --create --topic audit-log \
--bootstrap-server localhost:9092 \
--config retention.ms=2592000000 # 30天，单位毫秒我遇到过一家金融客户，他们把所有topic都设了90天保留期，结果磁盘一个月就爆了。后来我们按数据分级：交易日志30天，审计日志90天，监控指标7天。磁盘压力立刻降下来。
2.3.2 default.replication.factor
这个参数决定topic的默认副本数。生产环境我建议至少设2，最好3。
为什么？ 副本数=2时，挂一个broker还能读；副本数=3时，挂一个broker不影响写入（ISR多数还在）。
# server.properties
default.replication.factor=3
# 创建topic时手动指定
bin/kafka-topics.sh --create --topic critical-data \
--bootstrap-server localhost:9092 \
--replication-factor 3 \
--partitions 62.4 JMX监控开启：让数据可见
没有监控的Kafka集群，就像蒙眼开车。JMX（Java Management Extensions）是Kafka内置的监控接口，配合Prometheus + Grafana，你能看到吞吐量、延迟、分区状态等关键指标。
开启方式：在启动脚本中设置JMX参数。
# 方式一：环境变量
export JMX_PORT=9999
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9999 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false"
bin/kafka-server-start.sh config/server.properties
# 方式二：直接修改 kafka-server-start.sh
# 在 exec 行前加入
export KAFKA_JMX_OPTS="$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port=9999"验证JMX是否生效：
# 使用 jconsole 连接
jconsole 192.168.1.10:9999
# 或者用命令行
jstat -snap 192.168.1.10:9999如果能看到 kafka.server、kafka.consumer 等MBean，说明JMX已开启。
2.5 本章知识体系
下面这张图帮你理清本章的核心逻辑：从单节点到集群，再到关键参数和监控，是一条完整链路。
这张图把本章内容串起来了。你从单节点起步，理解基础流程；然后扩展到三节点集群，掌握分布式核心；接着吃透两个关键参数——它们直接决定数据治理的合规性和可用性；最后开启JMX监控，让集群状态一目了然。