Kafka 概述
定义与作用
Apache Kafka 是一个分布式流处理平台，最初由 LinkedIn 开发并于 2011 年开源，现为 Apache 顶级项目。Kafka 远不止一个消息队列——它被设计为企业级实时数据管道的统一基础设施，提供消息的发布、订阅、存储和流式处理能力。
Kafka 是分布式系统的基础设施之一。本教程默认读者已具备网络与基础存储知识（TCP 协议、文件系统、Page Cache 等），并了解基本的 Linux 操作。
Kafka 解决的核心分布式问题：如何在海量数据场景下，以低延迟、高吞吐的方式可靠地传递与存储消息，同时支持多消费者独立消费和历史数据回放。
核心特性
| 特性 | 说明 | 对比传统 MQ |
|---|---|---|
| 高吞吐 | 单机可达百万 QPS（顺序 I/O + Page Cache + Zero Copy） | RabbitMQ 万级 |
| 持久化 | 消息写入磁盘日志，支持历史回放 | RabbitMQ 消费后即删 |
| 水平扩展 | Partition 机制天然支持分布式，增加 Broker 即可扩容 | 传统 MQ 扩展困难 |
| 多消费者模型 | 消费组内负载均衡 + 组间广播，灵活组合 | 模型较单一 |
| 流处理 | Kafka Streams / ksqlDB 可直接在消息管道上做实时计算 | 需要额外的流计算框架 |
四大核心 API
- Producer API：应用程序向 Kafka Topic 发送数据
- Consumer API：应用程序从 Kafka Topic 读取数据
- Streams API：将输入 Topic 的数据实时转换后写入输出 Topic（流处理）
- Connect API：连接外部系统（数据库、搜索引擎、文件系统）与 Kafka，实现导入/导出
发展简史
| 时间 | 里程碑 | 意义 |
|---|---|---|
| 2010 | LinkedIn 内部开发 | 解决活动流数据管道问题 |
| 2011 | Apache 孵化器开源 | 加入 Apache 基金会 |
| 2012 | Apache 顶级项目 | 社区驱动快速发展 |
| 2014 | Kafka 0.8.0 | 引入副本机制（Replication），大幅提升可靠性 |
| 2017 | Kafka 0.11.0 | 精确一次语义（Exactly-once）+ 事务消息 |
| 2019 | Kafka 2.4.0 | 引入 KRaft 元数据模式（去除 ZooKeeper 依赖） |
| 2022 | Kafka 3.3.0 | KRaft 生产就绪（Production Ready） |
| 2023 | Kafka 3.6+ | 支持 Share Groups、分层存储（Tiered Storage） |
与 RabbitMQ 的关键差异
| 维度 | Kafka | RabbitMQ |
|---|---|---|
| 核心模型 | 分布式日志（Log） | 消息队列（Queue） |
| 消息持久化 | 默认持久化，可重放 | 消费后删除（可配置持久化） |
| 吞吐量 | 百万级 QPS | 万级 QPS |
| 消息顺序 | Partition 内严格有序 | 队列有序，但多消费者乱序 |
| 路由灵活性 | 简单（Key → Partition） | 灵活（Exchange + Binding） |
| 协议 | 自定义二进制协议 | AMQP 标准 |
选型建议：大规模日志/事件流、需要历史回溯 → Kafka；复杂路由、低延迟单条确认、与 AMQP 生态集成 → RabbitMQ。
集群架构概览
- Broker：Kafka 服务节点，负责消息存储和转发
- Producer：消息生产者，向指定 Topic 的 Partition Leader 发送数据
- Consumer：消息消费者，从 Partition Leader 拉取数据
- ZooKeeper / KRaft：集群元数据管理（KRaft 模式在 3.x 中已替代 ZooKeeper）
易错场景
场景：初次接触 Kafka 的开发者常误以为 Kafka 是一个"大号的 RabbitMQ"，直接用它来做业务 RPC 级别的低延迟消息投递（如订单状态变更通知每条约 100 字节，延迟要求 < 5ms P99）。
问题：Kafka 的批处理设计天然引入毫秒级延迟（linger.ms 默认值为 0 但不保证零延迟），其性能优势体现在吞吐而非单条延迟。如果场景是低延迟小消息 + 复杂路由，RabbitMQ 更合适。
面试高频考点
Q：Kafka 为什么被描述为"分布式日志"而不是"消息队列"？
A：因为 Kafka 的核心抽象是一个只追加（append-only）的持久化日志，而非传统消息队列的消费即删除模型。消费者通过 Offset 自行管理消费位置，可以重复消费历史数据。这种设计使得 Kafka 不仅仅是一个消息通道，而是一个可重放的事件流存储系统，天然支持多消费者独立消费、数据回溯和故障恢复。