Kafka集群：核心架构+部署+运维全解析
Kafka集群是分布式流处理系统，由多台服务器（Broker）组成，依托ZooKeeper协调，实现高可用、高吞吐、可扩展，支撑海量消息存储与实时流转，核心优势是高并发、低延迟、容错强，适用于日志收集、消息队列、流处理等场景。
一、核心组件与架构
- 核心角色
• Broker：集群核心节点（单台服务器），存储消息、处理客户端请求，集群中Broker有唯一ID（0、1、2...），无主从之分，依赖ZooKeeper同步状态。
• Producer：消息生产者，向Broker写入消息，支持批量发送、分区路由（按Key哈希/轮询），可指定ACK确保消息可靠性。
• Consumer：消息消费者，从Broker读取消息，多消费者组成Consumer Group（消费组） ，组内消费者分摊分区消费（1个分区仅被组内1个消费者消费），组间独立消费。
• ZooKeeper：集群协调中心，存储Broker、Topic、分区元数据，选举Partition Leader，监控节点状态（Broker上下线、消费者组重平衡）。
• Topic/Partition/Replica：
◦ Topic：消息分类标识，生产者按Topic发消息，消费者按Topic订阅。
◦ Partition：Topic物理拆分，1个Topic分多个分区，分区内消息有序（全局无序，需流处理保障），分区数量决定并发能力（越多吞吐越高）。
◦ Replica：分区副本，1个分区含1个Leader+N个Follower，Leader处理读写，Follower同步Leader数据，Leader故障时Follower选举上位，保障高可用（副本数≥2，通常3个）。
- 架构逻辑
• 读写路由：所有读写请求仅对接Partition Leader，Follower仅同步数据，避免并发冲突。
• 容错机制：Broker故障时，ZooKeeper感知后触发Leader重选举，副本同步确保数据不丢失。
• 扩展逻辑：新增Broker后，可迁移分区均衡负载；新增分区提升Topic并发吞吐。
二、集群部署（3节点基础版，Linux环境）
- 前置条件
• 3台Linux服务器（CentOS7+/Ubuntu），关闭防火墙/开放端口（9092：Broker通信，2181：ZooKeeper）。
• 安装JDK8+（Kafka依赖Java），配置JAVA_HOME。
• 3节点时钟同步（ntpdate校准），主机名与IP映射（/etc/hosts）。
- 步骤
（1）部署ZooKeeper集群（3节点）
- 下载ZooKeeper压缩包，解压后配置：
◦ 新建data目录，在data下创建myid文件，3节点分别写入1、2、3。
◦ 编辑conf/zoo.cfg：
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/zookeeper/data
clientPort=2181
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
- 3节点同步配置，分别启动ZooKeeper：bin/zkServer.sh start，查看状态：bin/zkServer.sh status（1个Leader，2个Follower）。
（2）部署Kafka集群（3节点）
- 下载Kafka压缩包，解压后编辑config/server.properties：
◦ 3节点分别配置broker.id=0、1、2。
◦ 核心配置：
listeners=PLAINTEXT://node1:9092 # 本机IP/主机名，3节点对应修改
log.dirs=/usr/local/kafka/logs # 消息存储目录
zookeeper.connect=node1:2181,node2:2181,node3:2181 # ZK集群地址
num.partitions=3 # 默认分区数
default.replication.factor=3 # 默认副本数
auto.create.topics.enable=false # 禁用自动创建Topic
- 3节点同步配置，分别启动Kafka：bin/kafka-server-start.sh -daemon config/server.properties，查看进程：jps（有Kafka进程则成功）。
（3）集群验证
• 创建Topic：bin/kafka-topics.sh --create --topic test --partitions 3 --replication-factor 3 --bootstrap-server node1:9092,node2:9092,node3:9092。
• 查看Topic详情：bin/kafka-topics.sh --describe --topic test --bootstrap-server node1:9092，可见每个分区的Leader/Follower分布。
• 生产消息：bin/kafka-console-producer.sh --topic test --bootstrap-server node1:9092。
• 消费消息：bin/kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server node1:9092。
三、关键优化配置（高吞吐/高可用）
- Broker优化
• num.network.threads=8：网络IO线程数（CPU核数1-2倍）。
• num.io.threads=16：磁盘IO线程数（CPU核数2-4倍）。
• log.retention.hours=72：消息保留时间（默认7天，按需调整，减少磁盘占用）。
• log.segment.bytes=1GB：单个日志文件大小，满了滚动生成新文件。
• replica.lag.time.max.ms=30000：Follower滞后Leader超过30s，视为失效，踢出副本集。
• auto.leader.rebalance.enable=true：自动平衡Leader分布（避免单Broker负载过高）。
- Producer优化
• acks=1：默认值（Leader写入成功即返回），兼顾性能与可靠性；acks=all（所有副本写入成功），可靠性最高，性能略降。
• batch.size=16384：批量发送阈值（16KB），达到阈值批量发送，提升吞吐。
• linger.ms=5：等待5ms凑批量，平衡延迟与吞吐。
- 同时设置
batch.size和linger.ms，就是哪个条件先满足就都会将消息发送出去。 Kafka需考虑高吞吐量与延时的平衡。
• compression.type=gzip：消息压缩（gzip/snappy），减少网络传输量。
- Consumer优化
• fetch.min.bytes=1024：最小拉取字节数，凑够再返回，减少请求次数。
• fetch.max.wait.ms=500：最长等待时间，超时即使没凑够也返回。
• max.poll.records=500：单次拉取消息数，避免消费过慢导致重平衡。
• session.timeout.ms=10000：消费者心跳超时，超过则视为下线，触发重平衡。
四、运维核心操作
- 节点扩容/缩容
• 扩容：新增Broker，修改配置（broker.id唯一），启动后，通过kafka-reassign-partitions.sh迁移现有分区到新节点，均衡负载。
• 缩容：先迁移待下线Broker上的所有分区，再停止Broker，删除ZooKeeper中该节点元数据。
- 分区迁移
• 编写迁移计划JSON文件，指定Topic分区迁移目标Broker，执行kafka-reassign-partitions.sh --execute执行迁移，--verify验证迁移结果。
- 故障处理
• Broker故障：Leader自动重选举，故障恢复后，该节点上的Follower自动同步Leader数据，恢复后可手动平衡Leader。
• ZK故障：单ZK节点故障，集群仍可用（剩余节点选举新Leader），修复故障节点后重启同步数据。
• 消息丢失：确保acks=all、副本数≥2，Producer开启重试（retries=3），避免消息丢失。
- 监控
• 内置工具：kafka-topics.sh（Topic管理）、kafka-consumer-groups.sh（消费组监控，查看消费滞后量）。
• 第三方工具：Prometheus+Grafana（监控Broker负载、分区状态、消费滞后）、ELK（日志分析）。
五、核心特性总结
• 高吞吐：分区并行、批量发送、压缩，单机吞吐可达10万+QPS。
• 高可用：副本机制、Leader选举，节点故障不影响集群运行。
• 可扩展：Broker、分区横向扩展，无缝扩容。
• 低延迟：毫秒级消息传输，适用于实时场景。