Skip to content

Kafka技术栈总览

一句话定位:Kafka 是分布式流式处理平台——「消息系统 + 存储系统 + 流处理」三合一;以 Topic→Partition 分区 + 多副本为骨架,靠顺序写 + PageCache + 零拷贝 + 批量压缩做到百万级吞吐,用 Consumer Group 同时兼容点对点与发布订阅两种消息模型。

三大功能(不只是消息队列)

功能说明
消息系统解耦、冗余存储、削峰、缓冲、异步通信;还提供多数 MQ 难做到的顺序性保障回溯消费
存储系统消息持久化到磁盘 + 多副本,可当长期存储(保留策略设永久 / 日志压缩)
流式处理平台提供窗口、连接、变换、聚合等流处理能力,是 Flink/Spark 的可靠数据源

历史背景:LinkedIn 最早为处理海量日志开发,早期功能不完备(丢消息、可靠性弱),并不是天生合格的消息队列;靠日志场景打磨出的顺序写与批量设计,才成为高吞吐标杆。

架构分层与核心概念

三层理解模型(注册协调层 / 核心概念层 / 存储层):

┌─ Zookeeper / KRaft:集群元数据 + 协调(2.8.0 起 KRaft 可去 ZK)
├─ 核心层:record / topic / partition / producer / consumer / broker
│          leader / follower / offset / consumer group / coordinator / controller
└─ 存储层:消息以日志(segment 分段)落盘
概念说明
Topic消息分类(类比数据库表),一个 Topic 分多个 Partition
Partition分片单元:负载均衡 + 横向扩展;分区内有序,跨分区不保证
BrokerKafka 服务节点;多个 Broker 组成集群
Replica分区副本:1 Leader + N Follower,Leader 唯一对外读写
Offset分区内消息递增序号,消费位置标记,支持回溯消费
Consumer Group组内一个分区只被一个消费者消费;组间互不影响(逻辑订阅者)
Coordinator协调者:负责消费者组分区分配与 Rebalance
Controller集群控制器(唯一):Leader 选举、主题管理、分区重分配

两种消息模型的统一

  • 点对点:所有消费者同属一个 Group → 每条消息只被组内一个消费者消费。
  • 发布订阅:每个消费者各自独立 Group → 消息广播给所有 Group。
  • 同一分区在同一组内只能由一个消费者消费,因此组内消费者数 > 分区数时会有人闲置

为什么快(六要点)

  1. 顺序读写:日志追加写,避免随机寻址(顺序写性能接近内存)。
  2. Page Cache:写走 OS 页缓存(os cache)异步刷盘,读优先命中缓存——利用 OS 内存而非 JVM 堆。
  3. 零拷贝:读时 sendfile 让数据直接从内核态 cache → 网卡,跳过「内核→用户→内核」两次拷贝与上下文切换。
  4. 批量读写:消息攒批次发送/拉取,避免网络频繁小包。
  5. 批量压缩:Producer/Broker/Consumer 全程压缩(gzip/snappy/lz4),省带宽省磁盘。
  6. 分区分段 + 稀疏索引:partition 按 segment(默认 1G)分段,配合 index 文件定位,提升读取并行度。

Pull 还是 Push

Kafka 选 Pull(拉):消费速率由消费者自己掌控,可自主批量;Push 模式下 broker 推送速率大于消费速率时消费者会被打崩(Scribe/Flume 即 Push 前车之鉴)。Pull 的缺点(空轮询)用阻塞参数缓解——可让消费者阻塞到新消息到达或攒够数量。

与 ZK 的演进

  • 旧版重度依赖 ZK:Broker 注册、Topic 元数据、Controller 选举、位移存储。
  • 移除 ZK 的原因:① 多一套分布式系统,运维复杂度高;② ZK 不适合高频读写(如位移提交);③ 集群规模大时 ZK 元数据膨胀、Watch 延迟/丢失。
  • KRaft(2.8.0 起):Kafka 用自己的 Raft 协议管理元数据,可完全去 ZK。

关键参数速查

参数作用
bootstrap.servers生产者/消费者入口,先连任意 broker 拉元数据再全量建连
acks0 / 1 / all(-1):写成功判定级别
retries发送失败重试次数
replication.factor副本数(≥3 推荐)
min.insync.replicasISR 最少写入数(>1 推荐,且 < factor)
enable.auto.commit消费者是否自动提交 offset
auto.offset.reset无 offset 时 earliest / latest
replica.lag.time.max.msFollower 落后 Leader 最大时间(默认 10s),超时被剔出 ISR
log.dirs数据目录(多目录时选分区数最少的目录建新分区,而非磁盘余量最少)

常见误解

  • 以为 Kafka 全局有序 → 只有分区内有序;要全局有序只能单分区。
  • 以为读写分离能提吞吐 → Kafka 主写主读,读写分离反而引入数据不一致 + 双盘拷贝延迟
  • 以为分区越多吞吐越高 → 超过限度后内存/句柄/复制线程/故障恢复时间反噬性能。

关联

最近更新