3、Kafka安装与部署：单机模式安装、集群模式部署、ZooKeeper角色、KRaft模式介绍
好，咱们进入实操环节。说实话，很多初学者在Kafka安装这一步就被劝退了——不是装不上，而是装完之后一脸懵：这玩意儿到底怎么跑起来的？ZooKeeper又是干嘛的？
这一章，我会带你亲手搭一遍。单机、集群、ZooKeeper、KRaft，全走一遍。你跟着做就行。
3.1 单机模式安装
先来个最简单的。单机模式，说白了就是在一台机器上把Kafka跑起来。开发环境、学习测试，用这个就够了。
3.1.1 前置条件
- JDK 8+：Kafka是JVM系的东西，必须装Java。我个人习惯用JDK 11，稳。
- ZooKeeper：Kafka 2.8之前，ZooKeeper是硬依赖。后面会讲KRaft模式可以去掉它，但单机我们先保留。
- 下载Kafka：去Apache官网下载二进制包，别下源码包。
3.1.2 安装步骤
- 解压：
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：
bin/kafka-server-start.sh config/server.properties
3.1.3 验证安装
启动之后，创建一个topic试试：
bin/kafka-topics.sh --create --topic test-topic --bootstrap-server localhost:9092 --partitions 1 --replication-factor 1能创建成功，说明单机模式跑通了。
3.2 集群模式部署
单机玩够了，咱们上集群。生产环境至少3台broker起步。为什么是3台？你想想看，如果只有2台，挂了一台，剩下那台就成了单点，集群的意义就没了。
3.2.1 集群规划
| 节点 | IP | broker.id | 端口 |
|---|---|---|---|
| broker-1 | 192.168.1.101 | 1 | 9092 |
| broker-2 | 192.168.1.102 | 2 | 9092 |
| broker-3 | 192.168.1.103 | 3 | 9092 |
3.2.2 配置要点
每个broker的 server.properties 里，有几个关键参数必须改：
broker.id：集群内唯一，不能重复listeners：监听地址，别写成localhost，否则其他节点连不上log.dirs：数据目录，建议用独立磁盘zookeeper.connect：指向同一个ZooKeeper集群
3.2.3 启动集群
依次在每个节点上启动：
# 节点1
bin/kafka-server-start.sh config/server.properties
# 节点2
bin/kafka-server-start.sh config/server.properties
# 节点3
bin/kafka-server-start.sh config/server.properties启动完成后，用 kafka-topics.sh --describe 查看topic的副本分布，就能看到数据被分散到不同broker上了。
3.3 ZooKeeper角色
很多新手搞不清ZooKeeper在Kafka里到底干嘛的。我打个比方：ZooKeeper就像Kafka集群的「居委会大妈」——谁在、谁不在、谁负责什么，它全记着。
3.3.1 ZooKeeper的核心职责
- 集群元数据管理：记录哪些broker活着，哪些挂了
- Controller选举：选出一个broker当老大，负责分区leader的分配
- Topic配置存储：topic的分区数、副本数、配置信息都存在ZooKeeper里
- 消费者组协调：记录消费者组的offset和成员信息（新版Kafka已逐步移交给broker自己管理）
3.3.2 ZooKeeper的局限性
ZooKeeper虽然好用，但有个硬伤——它本身也是一个分布式系统，需要额外维护。而且当Kafka集群规模大了之后，ZooKeeper会成为性能瓶颈。
我记得有一次线上Kafka集群频繁抖动，查到最后发现是ZooKeeper的写压力太大，导致Controller选举超时。那之后我就开始关注KRaft模式了。
3.4 KRaft模式介绍
KRaft模式，是Kafka 2.8引入、3.0开始稳定的新特性。它的核心思想是：去掉ZooKeeper，让Kafka自己管自己。
3.4.1 为什么需要KRaft？
- 简化架构：少维护一个分布式系统，运维成本直线下降
- 提升性能：元数据操作不再经过ZooKeeper，延迟更低
- 更安全：避免了ZooKeeper和Kafka之间的网络故障风险
3.4.2 KRaft架构
在KRaft模式下，Kafka内部自己实现了一套共识协议（基于Raft）。集群中的broker分为两种角色：
- Controller（控制器）：负责管理元数据，类似以前的ZooKeeper角色
- Broker（代理）：负责处理生产消费请求，和以前一样
一个节点可以同时扮演Controller和Broker，也可以只扮演一种。
关键点：KRaft模式下，Controller节点之间通过Raft协议选举leader。这个leader负责处理所有元数据写请求。其他Controller节点作为follower，同步数据。
3.4.3 KRaft vs ZooKeeper 对比
| 对比维度 | ZooKeeper模式 | KRaft模式 |
|---|---|---|
| 依赖组件 | 需要额外部署ZooKeeper集群 | 无需外部依赖 |
| 元数据存储 | 存储在ZooKeeper | 存储在Kafka内部topic |
| Controller选举 | 通过ZooKeeper临时节点 | 通过Raft共识协议 |
| 运维复杂度 | 高（需要维护两套系统） | 低（一套系统搞定） |
| 生产环境成熟度 | 非常成熟 | 逐步成熟（3.0+推荐） |
3.4.4 KRaft模式配置示例
如果你用的是Kafka 3.0+，可以试试KRaft模式。配置起来很简单：
# 生成集群ID
bin/kafka-storage.sh random-uuid
# 格式化日志目录（只需执行一次）
bin/kafka-storage.sh format -t <uuid> -c config/kraft/server.properties
# 启动Kafka（不再需要启动ZooKeeper）
bin/kafka-server-start.sh config/kraft/server.properties3.5 本章知识体系
下面这张图，把本章的核心逻辑串起来了。你一看就明白：
3.6 避坑指南
最后，分享几个我踩过的坑，你遇到了能少走弯路：
- 端口被占用：Kafka默认9092，ZooKeeper默认2181。如果启动报错，先检查端口。
- 磁盘空间不足：Kafka的日志文件默认保留7天，如果数据量大，磁盘很容易爆。记得配置
log.retention.hours和log.segment.bytes。 - 网络不通：集群模式下，broker之间需要互通。别把
listeners配成localhost。 - JVM内存不够：Kafka默认堆内存1G，如果机器内存小，记得调小
KAFKA_HEAP_OPTS。
嗯，安装部署这部分就这些。你跟着搭一遍，遇到问题别慌，大概率是端口、配置、网络这三样。搞定了，Kafka就跑起来了。