1. Kafka 入门：发展史、核心概念与应用生态
各位同学好。我是老赵，在大数据这行摸爬滚打了快十年。今天咱们开始聊 Kafka，这个在流式数据清洗里几乎绕不开的「中枢神经」。
说实话，我第一次接触 Kafka 是在 2015 年。那时候公司日志系统天天挂，MySQL 直接扛不住写入压力。后来用了 Kafka，整个世界清净了。嗯，咱们就从这段历史开始讲起。
1.1 Kafka 发展史：从 LinkedIn 内部工具到行业标准
Kafka 的诞生，说白了是被逼出来的。
2010 年，LinkedIn 的数据团队发现一个问题：他们需要收集海量的用户行为日志、系统指标、监控数据，然后喂给 Hadoop 做离线分析。但当时的消息队列——ActiveMQ、RabbitMQ——吞吐量根本跟不上。我印象很深，那时候单机每秒能处理几千条消息就算不错了，而 LinkedIn 的需求是每秒几十万甚至上百万。
于是，LinkedIn 的几位工程师——Jay Kreps、Neha Narkhede 和饶军——决定自己写一个。他们参考了日志文件的设计思路：顺序写入、批量读取、零拷贝。2011 年，Kafka 正式开源。
我当年读第一版源码时，最大的感受就是「简洁」。没有复杂的路由规则，没有事务，就是一个分布式提交日志。但正是这种极简设计，让它跑出了惊人的性能。
| 时间 | 里程碑 | 我的感受 |
|---|---|---|
| 2010 | LinkedIn 内部立项 | 解决日志收集的吞吐瓶颈 |
| 2011 | 开源到 GitHub | 我还在用 Flume，觉得 Kafka 太「简陋」 |
| 2012 | 成为 Apache 顶级项目 | 社区开始活跃，我决定试试 |
| 2014 | Kafka 0.8 引入副本机制 | 终于不怕节点挂了，生产环境敢用了 |
| 2016 | Kafka 0.10 引入 Kafka Streams | 流处理不再依赖 Storm，生态开始成型 |
| 2020+ | Kafka 3.x 去 ZooKeeper 依赖 | 运维终于能少操一份心了 |
1.2 核心概念：Topic、Partition、Broker
这三个概念，你搞懂了，Kafka 就入门了一半。咱们一个一个说。
1.2.1 Broker：Kafka 集群里的「工人」
Broker 就是 Kafka 服务器节点。一个集群由多个 Broker 组成。每个 Broker 有自己的 ID，负责存储数据、处理请求。
我在项目中遇到过一个问题：新同事把 Broker 数量设成了 1，然后问为什么数据丢了。嗯，单节点没有副本，磁盘坏了就全没了。所以生产环境至少 3 个 Broker，这是底线。
1.2.2 Topic：数据的「分类标签」
Topic 是逻辑上的消息分类。比如订单数据发到 order_topic，用户行为发到 user_behavior_topic。生产者往 Topic 写，消费者从 Topic 读。
你想想看，如果没有 Topic，所有消息混在一起，消费者怎么知道哪些是自己要的？
1.2.3 Partition：Topic 的「分片」
这是 Kafka 高性能的关键。一个 Topic 可以分成多个 Partition，每个 Partition 是一个有序的、不可变的日志文件。
为什么要分片？
- 并行读写：多个消费者可以同时读不同 Partition
- 水平扩展：Partition 可以分布在不同的 Broker 上
- 顺序保证：同一个 Partition 内的消息是有序的
下面这张图展示了 Topic、Partition 和 Broker 的关系：
1.3 应用场景：Kafka 到底能干什么？
很多人以为 Kafka 只是个消息队列。其实它的能力远不止于此。我按使用频率排个序：
- 日志收集：这是 Kafka 的「老本行」。把分散在各服务器上的日志统一收集到 Kafka，再转存到 HDFS 或 ES。我做过一个项目，每天处理 500 亿条日志，Kafka 稳如老狗。
- 流式处理：配合 Kafka Streams 或 Flink，实现实时 ETL、实时统计。比如用户下单后 5 秒内更新排行榜。
- 消息解耦：微服务之间通过 Kafka 通信，生产者不用关心消费者是谁。我见过一个电商系统，订单服务发一个消息，库存、物流、积分三个服务各自消费，互不干扰。
- 事件溯源：把业务状态变化记录为事件流。比如银行交易流水，Kafka 保证不丢不重。
- 指标监控：收集服务器 CPU、内存、网络等指标，实时告警。
一句话总结：只要你的数据是「流式」的、需要「高吞吐」、需要「解耦」，Kafka 就是首选。
1.4 Kafka 生态：不只是个消息队列
Kafka 发展到现在，已经形成了一个完整的生态圈。我画了一张图帮你理清关系：
生态里的几个关键组件，我简单说一下：
- Kafka Connect：用来跟外部系统对接。比如从 MySQL 同步数据到 Kafka，或者从 Kafka 写入 Elasticsearch。配置好 connector 就行，不用写代码。
- Kafka Streams：轻量级流处理库。不需要 Flink 或 Spark 那样的重型框架，直接在应用里调用 API 就能做实时计算。
- Schema Registry：管理消息的序列化格式。我建议所有生产环境都用 Avro 或 Protobuf，别用 JSON——JSON 没有 schema 约束，字段改了都不知道。