Apache Kafka是由LinkedIn开发的开源分布式流处理平台,核心定位为高吞吐、低延迟的分布式消息系统。其设计目标包括:
每秒处理百万级消息
消息持久化存储(默认保留7天)
水平扩展能力
强消息顺序保证
术语 | 说明 |
---|---|
Broker | Kafka服务节点,组成集群处理消息 |
Topic | 消息分类的逻辑单位(如:user_behavior_logs ) |
Partition | Topic的物理分片,实现并行处理与负载均衡 |
Producer | 消息生产者,向指定Topic推送数据 |
Consumer | 消息消费者,通过订阅机制获取数据 |
Offset | 消息在分区中的唯一位置标识 |
Replica | 分区的副本,保障数据高可用(Leader处理请求,Follower同步数据) |
生产者是向 Kafka 发送消息的客户端,负责将数据发布到指定的 Topic。生产者无需等待消费者响应,支持异步或同步发送模式,保证高吞吐量。
消费者是订阅 Topic 并处理消息的客户端。通过消费者组(Consumer Group)实现负载均衡:同一消费者组内的多个消费者并行消费 Topic 的不同分区(Partition),而不同消费者组可独立消费同一 Topic。
Topic:逻辑上的数据分类,类似于消息队列的“频道”。一个 Topic 可被分为多个 Partition。
Partition:Topic 的物理分片,每个 Partition 是一个有序、不可变的消息序列。消息在 Partition 内按顺序追加(Append-Only),每条消息通过 Offset(偏移量)唯一标识。
Partition 的引入支持水平扩展:数据可分布在多个 Broker 上,提升吞吐量和并行处理能力。
每个 Partition 有多个副本(Replica),包含一个 Leader(读写节点)和多个 Follower(备份节点),确保数据高可用。
Broker:Kafka 集群中的单个服务器节点,负责存储 Partition 数据、处理生产者/消费者的请求。
Cluster:多个 Broker 组成的分布式集群,通过 ZooKeeper(或 Kafka 自带的 KRaft 模式)协调服务发现、Leader 选举、元数据管理。
在传统 Kafka 架构中,ZooKeeper 负责维护集群元数据(如 Broker 列表、Topic 配置、Partition 分配)、监控 Broker 存活状态,并触发 Leader 选举。
从 Kafka 2.8 版本开始,官方支持 KRaft 模式(无需 ZooKeeper),通过内置共识协议简化部署。
Kafka 的分布式架构围绕以下核心特性构建:
持久化存储:消息持久化到磁盘(非内存缓存),支持配置保留策略(如时间或大小限制)。
顺序写入与零拷贝:通过顺序 I/O 和零拷贝(Zero-Copy)技术优化读写性能。
分布式一致性:通过 ISR(In-Sync Replicas)机制保证副本间数据一致性。只有 ISR 中的副本可参与 Leader 选举。
发布-订阅模式:生产者发布消息到 Topic,多个消费者组独立消费。
队列模式:通过单一消费者组实现消息的负载均衡(类似传统消息队列)。
流处理模式:结合 Kafka Streams 或 Flink 实现实时数据转换与聚合。
高吞吐:单机可处理每秒数十万条消息。
水平扩展:通过增加 Broker 和 Partition 轻松扩展集群。
容错性:副本机制防止数据丢失,支持自动故障转移。
多语言支持:提供 Java、Python、Go 等多种客户端 SDK。
日志聚合:收集分布式系统的日志数据(如 ELK 栈)。
实时数据处理:结合 Flink、Spark Streaming 进行实时分析。
事件溯源:记录系统状态变化事件(如微服务架构)。
消息总线:解耦微服务间的异步通信。
本部分提供 Kafka 的实操指令,涵盖单机/集群部署、Topic 管理、消息生产和消费等核心场景,并附常用命令参考。
安装 Java:Kafka 依赖 Java 8+ 环境。
sudo apt install openjdk-11-jdk # Ubuntu/Debian
下载 Kafka:从官网获取最新版本(以 3.6.1 为例):
wget https://downloads.apache.org/kafka/3.6.1/kafka_2.13-3.6.1.tgz
tar -xzf kafka_2.13-3.6.1.tgz
cd kafka_2.13-3.6.1
启动 ZooKeeper:
bin/zookeeper-server-start.sh config/zookeeper.properties
启动 Kafka Broker(新终端):
bin/kafka-server-start.sh config/server.properties
修改 config/kraft/server.properties
并启动:
# 生成集群 UUID
bin/kafka-storage.sh random-uuid
# 格式化存储目录
bin/kafka-storage.sh format -t -c config/kraft/server.properties
# 启动 KRaft Broker
bin/kafka-server-start.sh config/kraft/server.properties
复制 server.properties
为 server-1.properties
、server-2.properties
、server-3.properties
,修改以下参数:
# server-1.properties
broker.id=1
listeners=PLAINTEXT://:9092
log.dirs=/tmp/kafka-logs-1
# server-2.properties
broker.id=2
listeners=PLAINTEXT://:9093
log.dirs=/tmp/kafka-logs-2
# server-3.properties
broker.id=3
listeners=PLAINTEXT://:9094
log.dirs=/tmp/kafka-logs-3
确保 ZooKeeper 已运行。
启动所有 Broker:
bin/kafka-server-start.sh config/server-1.properties
bin/kafka-server-start.sh config/server-2.properties
bin/kafka-server-start.sh config/server-3.properties
创建名为 test-topic
的 Topic,3 个分区、2 个副本:
bin/kafka-topics.sh --create \
--bootstrap-server localhost:9092 \
--topic test-topic \
--partitions 3 \
--replication-factor 2
bin/kafka-topics.sh --list --bootstrap-server localhost:9092
bin/kafka-topics.sh --describe --topic test-topic --bootstrap-server localhost:9092
bin/kafka-topics.sh --delete --topic test-topic --bootstrap-server localhost:9092
发送消息到 test-topic
:
bin/kafka-console-producer.sh \
--bootstrap-server localhost:9092 \
--topic test-topic
# 输入消息后按回车发送
从 test-topic
订阅消息:
bin/kafka-console-consumer.sh \
--bootstrap-server localhost:9092 \
--topic test-topic \
--from-beginning # 从最早消息开始消费
指定消费者组:
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic test-topic --group my-group
查看消费者组状态:
bin/kafka-consumer-groups.sh --list --bootstrap-server localhost:9092
bin/kafka-consumer-groups.sh --describe --group my-group --bootstrap-server localhost:9092
场景 | 指令示例 |
---|---|
查看 Broker 状态 | bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 |
动态增加分区 | bin/kafka-topics.sh --alter --topic test-topic --partitions 5 |
导出 Topic 数据 | bin/kafka-console-consumer.sh --topic test-topic --from-beginning > output.txt |
重置消费者位移 | bin/kafka-consumer-groups.sh --reset-offsets --to-earliest --execute |
压测生产者性能 | bin/kafka-producer-perf-test.sh --topic test-topic --num-records 1000000 |
docker run -d --name kafka \
-p 9092:9092 \
-e KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 \
-e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 \
bitnami/kafka:3.6
6.2 Docker Compose 集群
version: '3'
services:
zookeeper:
image: bitnami/zookeeper:3.9
ports:
- "2181:2181"
kafka1:
image: bitnami/kafka:3.6
ports:
- "9092:9092"
environment:
- KAFKA_CFG_BROKER_ID=1
- KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka1:9092
- KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
kafka2:
image: bitnami/kafka:3.6
environment:
- KAFKA_CFG_BROKER_ID=2
- KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka2:9093
- KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
生产者无法连接 Broker
检查 advertised.listeners
是否配置为客户端可访问的 IP/域名。
确保防火墙开放端口(如 9092)。
消费者无消息输出
确认 Topic 已成功创建且生产者发送了消息。
使用 --from-beginning
参数或检查消费者组位移。
副本不同步(Under-Replicated)
检查 Broker 网络连通性或磁盘空间。
调整 replica.lag.time.max.ms
参数。
Kafka 的性能调优涉及生产者、Broker、消费者三个核心环节,需结合业务场景进行针对性优化。
批量发送(Batching)
通过 linger.ms
(等待时间)和 batch.size
(批次大小)参数控制消息批量发送,减少网络请求次数,提升吞吐量。
压缩(Compression)
启用消息压缩(如 gzip
、snappy
或 lz4
),降低网络传输和存储开销。
异步发送与回调机制
使用异步发送模式(send()
方法结合 Callback
)避免阻塞生产者线程,同时通过回调处理发送失败或超时。
分区策略
自定义 Partitioner
实现负载均衡,避免数据倾斜(如按 Key 哈希或轮询分配)。
磁盘 I/O 优化
使用高性能存储(如 SSD)并配置多磁盘目录(log.dirs
)。
启用 log.flush.interval.messages
和 log.flush.interval.ms
控制刷盘频率,平衡持久化与性能。
JVM 调优
调整堆内存(建议 6-8GB,避免 Full GC),启用 G1 垃圾回收器。
配置 -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
。
网络与线程池
增加 num.network.threads
和 num.io.threads
应对高并发请求。
多线程消费
每个消费者线程绑定独立 Partition,避免线程竞争(需确保 Partition 数量 ≥ 消费者线程数)。
位移提交策略
自动提交:enable.auto.commit=true
(简单但可能重复消费)。
手动提交:commitSync()
或 commitAsync()
(精准控制,需处理提交失败逻辑)。
拉取参数调整
增大 fetch.min.bytes
和 fetch.max.wait.ms
提升单次拉取数据量,减少网络交互。
Leader-Follower 模型
每个 Partition 的 Leader 处理读写请求,Follower 异步/同步复制数据。
ISR(In-Sync Replicas)
仅 ISR 中的副本有资格参与 Leader 选举,通过 replica.lag.time.max.ms
控制副本同步超时。
Unclean Leader 选举
若所有 ISR 副本失效,是否允许非 ISR 副本成为 Leader(unclean.leader.election.enable
,默认 false
防止数据丢失)。
Broker 宕机
ZooKeeper/KRaft 检测 Broker 下线,触发 Partition Leader 重新选举。
数据一致性保障
生产者可通过 acks
参数控制写入确认级别:
acks=0
:不等待确认(高风险,高吞吐)。
acks=1
:Leader 确认(默认)。
acks=all
:所有 ISR 副本确认(强一致,低吞吐)。
异地多活与灾备
使用 MirrorMaker 2.0 实现跨集群 Topic 数据同步,支持动态配置和偏移量保留。
SASL 协议
支持 PLAIN、SCRAM、Kerberos 等机制,配置客户端与 Broker 双向认证。
SSL/TLS 加密
加密数据传输通道,防止中间人攻击。
ACL(访问控制列表)
基于角色(Role)或用户(User)限制 Topic 的读写权限,例如:
kafka-acls --add --allow-principal User:Alice --operation Read --topic test-topic
限制客户端(Producer/Consumer)的带宽或请求速率,防止资源滥用。
连接器(Connector)
内置多种 Source(如 MySQL、文件系统)和 Sink(如 HDFS、Elasticsearch)连接器,实现数据管道化传输。
分布式模式
支持横向扩展 Connect Worker,保障高可用。
Kafka Streams
轻量级库,支持实时数据转换、窗口聚合和状态管理。
Flink/Spark Streaming
集成 Kafka 作为 Source 或 Sink,构建复杂流处理任务。
Broker:请求队列长度、网络吞吐、磁盘使用率。
Topic:消息堆积量(Lag)、Partition 分布均衡性。
生产者/消费者:发送/消费速率、错误率。
Kafka Manager:可视化集群管理工具。
Prometheus + Grafana:指标采集与监控看板。
Burrow:消费者 Lag 监控与告警。
Broker 日志:server.log
记录关键事件(如 Leader 切换、副本同步失败)。
消费者位移监控:使用 kafka-consumer-groups
命令检查消费进度。
Exactly-Once 语义(EOS)
通过事务机制(enable.idempotence=true
)和幂等生产者,确保消息仅处理一次。
分层存储(Tiered Storage)
冷热数据分离,降低长期存储成本(需搭配兼容的存储系统)。
KRaft 模式
逐步替代 ZooKeeper,简化架构并提升集群稳定性。
Prometheus + Grafana:指标采集与监控看板。
Burrow:消费者 Lag 监控与告警。