📚 课程目录第1章 Kafka入门

1. Kafka 入门：从消息队列到流处理平台

大家好，我是这次课程的主讲。做了十几年后端和数据处理，Kafka 几乎成了我工具箱里最趁手的家伙。今天咱们就从零开始，聊聊 Kafka 到底是什么，以及它凭什么能成为流处理领域的事实标准。

Kafka 是一个分布式流处理平台。说白了，它就是一个能扛住海量数据、高吞吐、低延迟的消息系统。

我记得 2015 年第一次在生产环境用 Kafka，当时团队还在用 ActiveMQ 做业务消息。双十一流量一上来，ActiveMQ 直接挂了，消息堆积了几百万条。换了 Kafka 之后，同样的机器配置，吞吐量翻了 10 倍不止。嗯，从那以后我就再也没换过别的消息中间件。

Kafka 的核心定位：

在讲 Kafka 之前，咱们先看看消息队列的两种经典模型。你想想看，平时系统之间发消息，无非就两种场景：

一条消息只能被一个消费者消费。就像你去柜台办事，叫到你的号，你就去办，别人不能替你。

一条消息可以被多个消费者消费。就像公众号发文章，所有关注的人都能看到。

Kafka 用的是发布-订阅模型的增强版。它引入了一个叫「消费者组」的概念，让同一个组内的消费者竞争消费，不同组之间独立消费。这个设计非常巧妙，我在项目中经常用它来实现「一份数据，多个业务复用」的场景。

我的经验： 如果你需要「一条消息只处理一次」，用同一个消费者组；如果你需要「一条消息被多个系统处理」，用不同的消费者组。

这部分是重点。我建议你先把这几个概念刻在脑子里，后面所有的内容都围绕它们展开。

Topic 是消息的逻辑分类。你可以把它理解成数据库里的「表」。所有消息都按照 Topic 来组织。

每个 Topic 可以分成多个 Partition。Partition 是 Kafka 并行处理的基本单位。

为什么要分区？因为单机处理能力有限。分区之后，消息可以分散到多台机器上，吞吐量就上去了。

注意： 分区数不是越多越好。我见过有人把分区设成 1000 个，结果集群性能反而下降了。分区数建议根据业务流量和消费者数量来定，一般 3-10 个比较合理。

Broker 就是 Kafka 集群中的一台服务器。每个 Broker 上可以存放多个 Partition 的副本。

负责往 Topic 里发消息。你可以指定消息发到哪个 Partition，也可以让 Kafka 自动负载均衡。

负责从 Topic 里读消息。Consumer 可以属于某个消费者组，组内成员共同消费 Topic 的所有分区。

Kafka 能做的事情太多了。我挑几个最典型的场景说说。

这是 Kafka 最经典的应用。把各个服务的日志统一发送到 Kafka，然后由下游系统做分析、告警、存储。我曾经帮一家电商公司搭建过日志平台，每天处理 200 亿条日志，Kafka 稳如老狗。

订单系统下单后，需要通知库存、积分、物流等多个系统。用 Kafka 做中间层，订单系统只管发消息，其他系统各自消费，互不影响。

Kafka 自带的 Streams API 可以让你直接在消息流上做实时计算。比如实时统计每秒钟的订单金额、实时检测异常交易等。

把 Kafka 作为数据，连接不同的数据源和数据目标。比如从 MySQL 同步数据到 Elasticsearch，或者从日志文件导入到 Hadoop。

一句话总结： 只要你的系统需要「高吞吐、低延迟、可靠」的消息传递，Kafka 就是首选。

下面这张图展示了 Kafka 的核心架构。我建议你多看几遍，把 Producer、Broker、Consumer 之间的关系理清楚。

这一章我们走马观花地看了 Kafka 的全貌。你不需要一下子记住所有细节，但至少要明白：

给新手的建议： 如果你刚接触 Kafka，建议先搭一个单机环境，亲手写一个 Producer 和 Consumer 跑通流程。纸上得来终觉浅，绝知此事要躬行。