1. Kafka 入门：发展史、核心概念与应用选型
各位好，我是你们的 Kafka 运维讲师。今天咱们聊聊 Kafka 的入门知识。说实话，Kafka 现在几乎成了数据平台的标配。我最早接触它是在 2016 年，那时候公司要搭建实时日志管道，选型时在 RabbitMQ 和 Kafka 之间纠结了很久。后来事实证明，选 Kafka 是对的。
1.1 Kafka 发展史：从 LinkedIn 内部工具到行业标准
Kafka 的故事要从 2010 年讲起。当时 LinkedIn 团队发现，传统的消息队列（比如 ActiveMQ）扛不住他们海量的活动流数据。于是 Jay Kreps、Neha Narkhede 等人决定自己写一个。
2011 年，Kafka 开源了。我记得那时候版本号还是 0.7，功能很简陋，连副本机制都没有。但它的设计理念——顺序读写、零拷贝、水平扩展——已经奠定了基调。
2012 年，Kafka 进入 Apache 孵化器。2014 年，它毕业了，成为顶级项目。之后的发展速度惊人：0.8 版本引入副本机制，0.9 版本加入安全认证，0.10 版本支持 Kafka Streams，1.0 版本在 2017 年发布……
到现在，Kafka 已经不仅仅是消息队列了。它演变成了一个事件流平台。你想想看，从日志采集、指标监控，到 CDC（变更数据捕获）、事件溯源，到处都有它的身影。
核心转折点：Kafka 从“消息系统”升级为“事件流平台”，这个定位变化很关键。它意味着 Kafka 不再只是，而是数据的核心存储层。
1.2 核心概念：一张图讲清楚
在深入每个概念之前，我们先看一张整体架构图。这张图我画了很多遍，每次给新人培训都先用它。
好，图看完了。下面我们逐个拆解这些概念。
1.2.1 Topic 和 Partition
Topic 是 Kafka 中数据分类的逻辑单位。你可以把它理解成数据库里的表。比如你有一个订单系统，可以建一个 order_topic；有一个用户行为日志，可以建一个 user_behavior。
Partition 是 Topic 的物理分片。每个 Partition 就是一个有序的、不可变的日志文件。为什么要分片？说白了就是为了并行。我见过很多新手问：“为什么我的 Kafka 那么慢？” 一看，Topic 只有一个 Partition，那当然快不起来。
个人经验：Partition 数量不是越多越好。我踩过坑，曾经给一个 Topic 设了 100 个 Partition，结果 Broker 上文件句柄数暴涨，GC 压力也大。一般建议 Partition 数不超过 Broker 总核心数的 2-3 倍。
1.2.2 Broker
Broker 就是 Kafka 服务器节点。一个集群由多个 Broker 组成。每个 Broker 有一个唯一的 ID（整数）。
Broker 的核心职责很简单：接收 Producer 的数据、存储到磁盘、响应 Consumer 的拉取请求。但背后的事情不少——副本同步、Leader 选举、磁盘管理……
嗯，这里要注意：Broker 是无状态的。数据都在磁盘上，Broker 挂了换一台就行。但元数据（比如谁是谁的 Leader）存在 ZooKeeper 里。
1.2.3 Producer 和 Consumer
Producer 是数据生产者。它把消息发到指定的 Topic。Producer 可以指定消息发到哪个 Partition，也可以让 Kafka 自己决定（基于 key 的哈希）。
Consumer 是数据消费者。它从 Topic 拉取数据。Consumer 可以属于一个 Consumer Group。同一个 Group 内的 Consumer 共同消费一个 Topic，每个 Partition 只能被 Group 内的一个 Consumer 消费。
为什么要有 Consumer Group？为了实现负载均衡和容错。比如你有 6 个 Partition，3 个 Consumer 在同一个 Group，那每个 Consumer 消费 2 个 Partition。如果其中一个 Consumer 挂了，剩下的两个会自动接管它的 Partition。
避坑指南：我曾经遇到过一个生产事故——Consumer 的 Group ID 写错了，导致两个不同的服务用了同一个 Group ID。结果数据被随机分配到两个服务，业务逻辑全乱了。所以 Group ID 的命名一定要规范，最好带上业务含义。
1.3 核心概念对比表
为了方便记忆，我整理了一张对比表：
| 概念 | 类比 | 关键特性 | 运维关注点 |
|---|---|---|---|
| Topic | 数据库中的表 | 逻辑分类，可配置保留策略 | 命名规范、分区数、保留时间 |
| Partition | 表的分区文件 | 有序、不可变、可并行 | 分区数、副本因子、Leader 分布 |
| Broker | 数据库节点 | 无状态、水平扩展 | 磁盘容量、网络带宽、JVM 参数 |
| Producer | 写入客户端 | 异步/同步、acks 级别 | 重试策略、幂等性、压缩 |
| Consumer | 读取客户端 | 拉模式、offset 管理 | 消费滞后、Rebalance 频率 |
1.4 应用场景：Kafka 适合做什么？
Kafka 的应用场景很广。我挑几个最常见的说说：
- 日志采集：这是 Kafka 最经典的用法。各服务把日志发到 Kafka，下游的 Flink、Elasticsearch 再消费。我见过单集群每天处理 10TB 日志的场景，Kafka 扛得住。
- 指标监控：配合 Prometheus 或 Grafana，Kafka 可以作为指标数据的。延迟低、吞吐高。
- CDC（变更数据捕获）：通过 Debezium 等工具，把数据库的变更事件实时同步到 Kafka。很多公司用这个做数据同步或缓存更新。
- 事件溯源：把业务事件作为不可变日志存储。Kafka 的持久化特性天然适合这种模式。
- 流处理：Kafka Streams 或 ksqlDB 可以直接在 Kafka 上做实时计算，省去额外的流处理集群。
一句话总结：Kafka 适合高吞吐、低延迟、需要持久化的流式数据场景。不适合小消息、低频通信的场景——杀鸡用牛刀了。
1.5 选型分析：Kafka vs 其他消息队列
很多同学会问：“Kafka 和 RabbitMQ、RocketMQ 比，到底选哪个？” 我个人的看法是这样的：
| 对比维度 | Kafka | RabbitMQ | RocketMQ |
|---|---|---|---|
| 设计定位 | 事件流平台 | 消息队列 | 消息队列 |
| 吞吐量 | 极高（百万级/秒） | 中等（万级/秒） | 高（十万级/秒） |
| 消息顺序 | Partition 内有序 | 队列内有序 | 队列内有序 |
| 消息持久化 | 磁盘顺序写 | 内存+磁盘 | 磁盘顺序写 |
| 运维复杂度 | 中等（依赖 ZooKeeper） | 低 | 中等 |
| 典型场景 | 日志、流处理、CDC | 任务队列、RPC | 交易消息、削峰填谷 |
怎么选？我建议：
- 如果你需要高吞吐、持久化、流处理，选 Kafka。
- 如果你需要灵活的路由、低延迟、小消息，选 RabbitMQ。
- 如果你在阿里云生态，或者需要事务消息、定时消息，选 RocketMQ。
我的习惯：做选型时，我会先问三个问题——数据量多大？是否需要重放历史数据？下游是实时还是批量？答案清楚了，选型就简单了。
1.6 本章小结
这一章我们聊了 Kafka 的发展史、核心概念、应用场景和选型。说白了，Kafka 的核心就一句话：一个分布式的、持久化的、高吞吐的日志系统。理解了这个本质，后面的运维操作就顺理成章了。