1、Kafka简介：什么是Kafka、Kafka发展历史、Kafka核心特性、Kafka应用场景
大家好，欢迎来到这门课。我是你们的老朋友，一个在数据管道里摸爬滚打了好几年的工程师。
咱们第一节课，先聊聊Kafka到底是什么。说白了，Kafka就是一个分布式消息流平台。你想想看，在微服务架构里，服务A要给服务B发个消息，最笨的办法是直接HTTP调用。但要是服务B挂了怎么办？要是流量突然暴增怎么办？这时候，中间加一个Kafka，所有消息先往Kafka里塞，谁需要谁自己去取。这就好比一个快递，而不是点对点送货。
核心定义：Kafka是一个分布式、分区、多副本的基于ZooKeeper协调的分布式消息系统。它的定位是「高吞吐量的分布式发布订阅消息系统」。
1.1 发展历史：从LinkedIn内部工具到Apache顶级项目
Kafka的故事，得从2010年说起。我记得当时LinkedIn（领英）面临一个头疼的问题：他们需要收集大量用户行为数据（点击、浏览、搜索），然后实时分析。但现有的消息队列，比如ActiveMQ、RabbitMQ，吞吐量根本扛不住。
于是，LinkedIn的工程师Jay Kreps、Neha Narkhede和饶军（Jun Rao）决定自己写一个。他们最初的目标很简单：每天能处理数千亿条消息。2011年，Kafka正式开源，2012年成为Apache顶级项目。
我刚开始接触Kafka是2015年，那时候版本还是0.8.x。说实话，配置起来挺麻烦的，ZooKeeper还得单独部署。但它的性能确实惊艳——单机就能扛住每秒几十万条消息。后来Confluent公司成立，Kafka生态越来越完善，现在已经是数据架构的标配了。
| 时间 | 里程碑 | 我的感受 |
|---|---|---|
| 2010年 | LinkedIn内部开发 | 解决海量日志收集问题 |
| 2011年 | 正式开源 | 消息系统领域的新星 |
| 2012年 | 成为Apache顶级项目 | 社区开始活跃 |
| 2014年 | Kafka 0.8.0 发布 | 我入坑的版本，复制功能上线 |
| 2016年 | Kafka Streams 发布 | 流处理能力，不再只是消息队列 |
| 2020年+ | Kafka 3.x 移除ZooKeeper依赖 | KRaft模式，部署更简单 |
1.2 核心特性：为什么大家都选Kafka？
Kafka能火，不是没有原因的。我总结了几点最核心的特性，也是我在项目中反复验证过的。
1.2.1 高吞吐量
这是Kafka的看家本领。它采用顺序读写磁盘和零拷贝技术，单机吞吐量可以达到每秒几十万甚至上百万条消息。相比之下，传统的消息队列（比如RabbitMQ）单机也就几万条。为什么会这样？因为Kafka把消息写到磁盘时，是追加到文件末尾，而不是随机写入。机械硬盘的顺序读写速度，其实不比内存差多少。
避坑指南：我曾经遇到一个项目，业务方说「Kafka怎么这么慢？」。后来一查，他们把消息体搞到了10MB一条。Kafka虽然吞吐高，但消息体太大一样会拖垮性能。我建议单条消息控制在1MB以内，最好100KB左右。
1.2.2 持久化与可靠性
Kafka的消息默认是持久化到磁盘的，而且支持多副本机制。你可以配置副本数（比如3个），即使某台机器宕机，其他副本还能提供服务。数据不会丢，这是生产环境的基本要求。
1.2.3 分布式与可扩展
Kafka是天生分布式的。你可以通过增加Broker节点来水平扩展集群。我见过最大的集群有几百台机器，每天处理万亿条消息。扩展的时候，只需要把新机器加进去，然后重新分配分区就行，业务代码不用改。
1.2.4 消息回溯与重放
这是Kafka和很多消息队列不一样的地方。Kafka的消息消费后不会立即删除，而是根据配置的保留策略（比如保留7天）来清理。这意味着你可以从头开始重新消费历史数据。我在做数据修复时，这个功能救过我好几次。
1.2.5 流处理能力
Kafka Streams和KSQL让Kafka不再只是一个消息管道，而是一个流处理平台。你可以直接在Kafka上做实时计算，比如窗口聚合、状态管理，不需要额外部署Storm或Flink。
| 特性 | Kafka | 传统消息队列（如RabbitMQ） |
|---|---|---|
| 吞吐量 | 百万级/秒 | 万级/秒 |
| 消息存储 | 磁盘持久化，可回溯 | 内存为主，消费即删除 |
| 消费模式 | 拉模式（Pull） | 推模式（Push） |
| 顺序保证 | 分区内严格有序 | 全局有序（性能差） |
| 扩展性 | 水平扩展，无状态 | 集群扩展复杂 |
1.3 应用场景：Kafka能做什么？
Kafka的应用场景非常广。我挑几个最常见的，结合我自己的经历聊聊。
1.3.1 日志收集与分析
这是Kafka最经典的应用。我记得在2016年，我给一家电商公司搭日志系统。所有服务器的访问日志、业务日志，通过Filebeat采集到Kafka，然后Logstash消费写入Elasticsearch。Kafka在这里起到了削峰填谷的作用——白天流量高峰时，日志量暴增，Kafka先扛住，晚上再慢慢消费写入ES。如果没有Kafka，ES早就被写爆了。
1.3.2 消息系统
解耦微服务。比如订单服务下单后，发一条消息到Kafka，库存服务、积分服务、通知服务各自去消费。这样即使库存服务挂了，订单服务也不受影响。消息在Kafka里等着，库存服务恢复后继续消费。
1.3.3 用户活动跟踪
网站或App的用户行为数据（点击、浏览、搜索、购买），都可以通过Kafka实时收集。然后用于实时推荐、用户画像、AB测试等。我做过一个项目，每天处理10亿条用户点击流，Kafka稳如老狗。
1.3.4 流处理
用Kafka Streams做实时ETL、实时监控告警。比如检测到某个接口的失败率超过阈值，立刻触发告警。或者实时计算网站的UV（独立访客数），每5分钟更新一次。
1.3.5 事件溯源
把Kafka当作事件存储。每个状态变更都作为一个事件追加到Kafka。这样你可以回溯任意时间点的系统状态。这在金融、审计场景中非常有用。
注意：Kafka不是万能的。它不适合做「小消息、低延迟」的场景。比如你只是偶尔发几条消息，延迟要求毫秒级，那RabbitMQ可能更合适。Kafka的设计目标是高吞吐，启动和连接开销相对较大。
1.4 Kafka核心架构图
下面这张图，是我自己画的Kafka核心架构。你看一遍，基本就能理解Kafka是怎么工作的了。
嗯，这张图基本把Kafka的核心组件都串起来了。Producer只管往Topic里写，Consumer只管从Topic里读，Broker负责存。ZooKeeper（或者新版的KRaft）负责协调。就是这么简单。
1.5 小结
这一章我们聊了Kafka是什么、怎么来的、有什么本事、能干什么。我个人觉得，Kafka最厉害的地方不是某一个特性，而是它把高吞吐、持久化、分布式、流处理这些能力整合在了一起。你不需要再拼凑多个系统，一个Kafka就能搞定大部分数据管道需求。