1. Kafka入门：消息队列概念、Kafka核心特性、Kafka在实时数仓中的定位

1.1 消息队列：从“点对点”到“发布订阅”

聊Kafka之前，咱们得先搞清楚消息队列到底是个啥。说白了，消息队列就是一块“缓冲区”，专门用来暂存数据。生产者把数据扔进去，消费者再从里面取出来。这样生产者和消费者就不用直接打交道了。

我刚开始接触消息队列时，总觉得这东西可有可无。直到有一次，我们有个业务系统高峰期每秒要处理上万条日志，数据库直接被写挂了。嗯，从那以后我才真正理解——消息队列的核心价值就是解耦和削峰填谷。

消息队列有两种主流模型：

• 点对点模型（P2P）：一条消息只能被一个消费者消费。就像你去柜台办事，排到你，窗口服务员就只服务你一个人。
• 发布订阅模型（Pub/Sub）：一条消息可以被多个消费者订阅。好比公众号发文章，所有关注的人都能看到。

Kafka用的就是发布订阅模型。而且它做得更极致——同一个主题下的消息，还能按分区被不同消费者并行消费。这个咱们后面细说。

1.2 Kafka核心特性：为什么它成了实时数仓的标配？

市面上消息队列不少，RabbitMQ、RocketMQ、ActiveMQ……为什么Kafka能脱颖而出？我个人觉得，关键在于它把“吞吐量”和“持久化”这两个看似矛盾的点，做到了极致。

1.2.1 高吞吐、低延迟

Kafka的写入速度有多快？我做过压测，单机每秒能写几十万条消息。秘诀在于：

• 顺序写磁盘：Kafka不搞随机写，而是像写日志一样，一条接一条往磁盘末尾追加。顺序写的速度，比随机写快好几个数量级。
• 零拷贝技术：消费数据时，数据直接从磁盘到网卡，绕过了用户态内存拷贝。你想想看，少了一次内存搬运，速度能不快吗？
• 批量处理：消息攒一批再发，网络开销被均摊了。

1.2.2 持久化与可靠性

我曾经踩过一个坑：有次线上Kafka集群突然断电，重启后数据全丢了。后来才发现，是因为没配好副本机制。Kafka的可靠性靠的是：

• 分区副本（Replica）：每个分区可以有多个副本，分布在不同的Broker上。Leader挂了，Follower顶上。
• ISR机制：只有跟Leader保持同步的副本，才有资格成为新Leader。这避免了数据不一致。
• ACK确认级别：生产者可以设置acks=all，确保消息写入所有副本后才算成功。

1.2.3 水平扩展性

Kafka的扩展性，说白了就是“加机器就行”。增加Broker节点，把分区迁移过去，吞吐量就上去了。整个过程对业务代码透明。我见过最大的集群，上千个Broker，每天处理PB级数据。

1.2.4 消息回溯与多消费者

Kafka的消息不会消费完就删。它会根据配置的保留时间（比如7天）或保留大小来清理。这意味着：

• 你可以从头重新消费历史数据。
• 同一个主题，可以被多个消费者组独立消费，互不干扰。

这个特性在实时数仓里太重要了。比如你发现ETL逻辑有bug，修复后直接从Kafka里重跑一遍就行，不用去翻原始日志。

1.3 Kafka在实时数仓中的定位

实时数仓的架构，我习惯把它分成三层：

1. 数据采集层：把业务数据、日志、埋点等实时接入。
2. 消息管道层：负责数据的缓冲、分发、削峰。
3. 计算与存储层：Flink做实时计算，结果写入ClickHouse、Doris等OLAP引擎。

Kafka就稳稳地坐在消息管道层。它不负责计算，也不负责存储最终结果，但它连接了所有上下游。

具体来说，Kafka在实时数仓里承担这几个角色：

角色	说明	我见过的典型场景
数据采集入口	接收业务库的CDC变更、应用日志、用户行为	Canal监听MySQL binlog，写入Kafka
流式ETL的中间缓冲	Flink从Kafka消费，做清洗、关联、聚合	订单流与支付流做双流Join
多下游分发	一份数据同时供给实时大屏、推荐系统、离线数仓	同一个Topic，多个消费者组各取所需
数据回溯与重放	修复逻辑后，重新消费历史数据	ETL脚本升级，重置offset重跑

下面这张图，是我画的一个典型实时数仓架构。你可以看到Kafka处在正中间，上下游都围着它转。

1.4 小结：Kafka凭什么？

回到最开始的问题：Kafka凭什么成为实时数仓的标配？

• 因为它快——顺序写 + 零拷贝，吞吐量碾压同类。
• 因为它稳——副本 + ISR，数据不容易丢。
• 因为它灵活——消息可回溯，多消费者组各取所需。
• 因为它能撑——水平扩展，从小规模到PB级都扛得住。