第4章 Kafka 环境搭建与配置

4. Kafka 环境搭建与配置：单机与集群部署、关键参数调优、监控与运维

各位同学，今天我们来聊聊Kafka环境搭建。说实话，这部分内容看起来简单，但坑特别多。我当年第一次搭Kafka集群时，就因为一个参数没配好，导致生产环境消息积压了整整两个小时。嗯，从那以后，我对每个参数都格外小心。

单机部署是入门的第一步。我个人习惯先用单机验证配置，再扩展到集群。这样排查问题会快很多。

首先，你需要下载Kafka。注意版本选择——我建议用2.8.0以上版本，因为从2.8开始，Kafka逐步移除了对ZooKeeper的依赖。不过今天我们先讲传统架构，毕竟大部分生产环境还在用ZooKeeper。

# 下载并解压
wget https://downloads.apache.org/kafka/3.5.0/kafka_2.13-3.5.0.tgz
tar -xzf kafka_2.13-3.5.0.tgz
cd kafka_2.13-3.5.0

启动ZooKeeper（单机模式）：

bin/zookeeper-server-start.sh config/zookeeper.properties

然后启动Kafka Broker：

bin/kafka-server-start.sh config/server.properties

这里有个小细节——server.properties里有个参数叫log.dirs，默认是/tmp/kafka-logs。我曾经在生产环境吃过亏，系统重启后/tmp被清空，所有数据都没了。所以，务必改成持久化目录。

⚠️ 避坑指南： 千万不要用默认的/tmp目录！我曾经因为这个问题，导致某次服务器重启后，所有Topic数据丢失，被运维同事追着骂了一周。

生产环境至少三个节点。为什么是三个？因为Kafka的ISR（In-Sync Replicas）机制需要多数节点存活才能正常工作。两个节点的话，挂一个就完蛋了。

集群配置的核心是server.properties。每个节点需要修改以下几个关键参数：

启动集群时，我建议按顺序来：先启动所有ZooKeeper，再逐个启动Kafka Broker。为什么？因为Kafka启动时会向ZooKeeper注册，如果ZooKeeper还没准备好，Broker会反复重试，浪费时间。

💡 小技巧： 可以用systemd管理Kafka进程，设置自动重启。我习惯写一个简单的service文件，这样即使进程挂了，系统也能自动拉起来。

Kafka的默认参数其实挺保守的。说白了，它为了兼容性，很多参数都设得很低。生产环境必须调优。

我个人最关注的三个参数：

num.partitions：默认是1，但生产环境建议设为3-6。分区数太少，并发能力上不去；太多，又会导致文件句柄浪费。我一般按Topic的预期吞吐量来算——每个分区每秒能处理约10MB数据。
log.retention.hours：默认168小时（7天）。如果你做实时监控，其实不需要存那么久。我通常设为24小时，节省磁盘空间。
message.max.bytes：默认1MB。如果你要传输大消息（比如日志文件），这个值得调大。我曾经遇到一个场景，业务方往Kafka塞了5MB的消息，结果一直报错，排查了半天才发现是这个参数没改。

# 生产环境推荐配置（部分）
num.partitions=6
log.retention.hours=24
message.max.bytes=10485760  # 10MB
replica.fetch.max.bytes=10485760
compression.type=snappy

  🔑 核心原则： 调优不是一次性的。我建议上线后持续观察监控指标，根据实际情况微调。比如，如果发现消费者经常落后，可以适当增加分区数或调整fetch参数。

监控是Kafka运维的重中之重。你想想看，如果消息积压了，你还在手动查日志，那黄花菜都凉了。

我常用的监控手段：

JMX指标：Kafka原生支持JMX，可以暴露Broker、Producer、Consumer的各种指标。比如kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec，这个指标能告诉你每秒写入多少条消息。
命令行工具：kafka-consumer-groups.sh可以查看消费者组的Lag（滞后量）。我习惯写个脚本，每5分钟检查一次Lag，超过阈值就报警。
第三方工具：比如Kafka Manager、Burrow、Kafka Eagle。我个人比较喜欢Burrow，它专门做消费者Lag监控，算法很成熟。

运维中还有一个常见问题——磁盘空间不足。Kafka的数据是顺序写入的，但如果日志清理不及时，磁盘很容易爆。我建议设置磁盘使用率告警，比如超过80%就发通知。

⚠️ 避坑指南： 我曾经遇到一个案例，某台Broker的磁盘满了，导致所有写入该节点的分区都不可用。后来我加了一个定时任务，每天凌晨清理过期的日志文件，再也没出过问题。

下面这张图是我自己画的，把Kafka环境搭建的核心知识点串起来了。你可以把它当作一个检查清单，部署时逐项核对。

好了，Kafka环境搭建这部分就讲到这里。记住，部署只是开始，真正的挑战在于后续的调优和运维。多观察、多总结，慢慢你就能摸清它的脾气了。