3. Kafka安装与配置：单机部署、集群部署、关键配置参数与JMX监控

好，咱们进入正题。Kafka的安装配置，说难不难，说简单也不简单。我见过不少团队，装是装上了，跑起来也正常，但一遇到生产流量就崩了。为什么？配置没吃透。

这一章，我会带你从单机部署开始，再到集群搭建，最后深入几个关键参数。嗯，还有JMX监控，这个在线上环境里特别重要。

3.1 单机部署：先跑起来再说

我个人习惯，学任何中间件都先搭单机。不是为了生产，是为了理解它的启动流程。

Kafka依赖ZooKeeper（或者KRaft模式，但咱们先讲经典的）。所以第一步，你得先有个ZooKeeper。

# 下载Kafka（里面自带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

你看，就这么几行。启动后，验证一下：

# 创建一个测试topic
bin/kafka-topics.sh --create --topic test-topic --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1

# 查看topic列表
bin/kafka-topics.sh --list --bootstrap-server localhost:9092

能列出topic，说明单机部署成功了。这里有个小坑——记得检查防火墙。我曾经在客户现场，折腾了半天连不上，最后发现是9092端口没开。

我的习惯：单机部署时，我会把log.dirs指向一个独立的磁盘分区。别跟系统盘混在一起，否则日志一多，系统盘满了，整个机器都卡。

3.2 集群部署：真正能扛事儿的方案

单机跑通了，咱们上集群。集群部署说白了就是多启动几个Broker，然后让它们互相认识。

假设你有三台机器：node1、node2、node3。每台机器上都要解压Kafka，但server.properties要改几个关键地方：

参数 node1 node2 node3
broker.id 1 2 3
listeners PLAINTEXT://node1:9092 PLAINTEXT://node2:9092 PLAINTEXT://node3:9092
log.dirs /data/kafka/logs /data/kafka/logs /data/kafka/logs
zookeeper.connect node1:2181,node2:2181,node3:2181 node1:2181,node2:2181,node3:2181 node1:2181,node2:2181,node3:2181

然后依次启动：

# 在每台机器上执行
bin/kafka-server-start.sh -daemon config/server.properties

启动后，用这个命令检查集群状态：

bin/kafka-broker-api-versions.sh --bootstrap-server node1:9092,node2:9092,node3:9092

能看到三个Broker的信息，就对了。

注意：集群部署时，zookeeper.connect要写所有ZooKeeper节点的地址。我曾经见过有人只写了一个，结果那个ZooKeeper挂了，整个Kafka集群都连不上。

3.3 关键配置参数：这些参数决定了你的系统能扛多大压力

配置参数很多，但真正关键的，我总结下来就三个：acks、retries、batch.size。这三个参数，说白了就是「可靠性」、「重试策略」和「吞吐量」的平衡。

3.3.1 acks：你到底要等几个副本确认？

acks参数控制生产者发送消息后，需要等待多少个副本确认才算成功。有三个取值：

取值 含义 可靠性 性能
0 不等待确认，发完就算成功 最低 最高
1 等待Leader副本确认 中等 中等
all（或-1） 等待所有ISR副本确认 最高 最低

我在量化交易系统里，核心订单数据用acks=all，因为丢一条订单可能损失几十万。但行情数据，我敢用acks=1，甚至acks=0——丢几条行情无所谓，速度才是王道。

一句话总结：数据值钱就用all，数据量大就用0，折中就用1。

3.3.2 retries：失败了怎么办？

retries控制生产者发送失败后的重试次数。默认是0，也就是不重试。

你想想看，网络抖动是常态。不重试的话，一条消息丢了就真丢了。我建议至少设成3：

retries=3
retry.backoff.ms=100  # 每次重试间隔100ms

但要注意，重试可能导致消息重复。如果你的下游系统不支持幂等，记得开启enable.idempotence=true。嗯，这个我踩过坑——有一次没开幂等，结果重试导致订单重复入库，排查了半天。

3.3.3 batch.size：攒够了再发

batch.size是生产者批量发送消息的缓冲区大小。默认是16KB。

这个参数很有意思。设得太小，每条消息都单独发，网络开销大。设得太大，消息攒在内存里，延迟变高。

我一般这样调：

  • 低延迟场景（比如交易信号）：batch.size设小一点，比如4KB
  • 高吞吐场景（比如日志收集）：batch.size设大一点，比如64KB甚至128KB

还有一个配套参数linger.ms，控制消息在缓冲区里最多等多久。默认是0，也就是立即发。如果你想攒批，可以设成5-10ms：

batch.size=32768   # 32KB
linger.ms=5        # 最多等5ms
我的经验：这两个参数要配合着调。先确定你能接受的延迟上限，再根据这个上限去算batch.size。别盲目设大，否则内存会爆。

3.4 JMX监控：让Kafka的状态一目了然

Kafka本身暴露了大量JMX指标，但默认没开远程访问。你需要手动开启。

在bin/kafka-server-start.sh里，加上JMX配置：

export JMX_PORT=9999
export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote
  -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false
  -Dcom.sun.management.jmxremote.port=9999
  -Dcom.sun.management.jmxremote.rmi.port=9999
  -Djava.rmi.server.hostname=你的IP"

然后重启Kafka。用jconsole或者jmxterm连上去，就能看到一堆指标。

我个人最关注的几个指标：

指标 MBean路径 说明
消息入站速率 kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec 看流量是否突增
请求队列大小 kafka.network:type=RequestChannel,name=RequestQueueSize 队列积压说明处理不过来
分区Leader数量 kafka.controller:type=KafkaController,name=ActiveControllerCount 正常应该是1，多了说明有问题
日志磁盘使用率 kafka.log:type=LogManager,name=LogDirOffline 磁盘满了会出大事
安全提醒：生产环境别开authenticate=false和ssl=false。我见过有人图省事，结果JMX端口暴露在公网上，被扫了。至少加个防火墙限制IP。

如果你用Prometheus+Grafana，可以用jmx_exporter把指标拉出来。这样可视化更直观。嗯，这个后面章节会细讲。

3.5 本章小结

这一章，咱们从单机部署开始，到集群搭建，再到三个核心参数和JMX监控。说白了，安装配置只是第一步，真正重要的是理解每个参数背后的权衡。

我个人建议，你可以在测试环境里反复调acks、retries、batch.size这三个参数，看看它们对吞吐量和延迟的影响。亲手试过，印象才深。

好，这一章就到这里。下一章咱们聊Kafka的生产者原理，到时候会深入源码层面。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →