1、Kafka入门：Kafka是什么、Kafka核心概念、Kafka的应用场景

1.1 Kafka到底是什么？

先别急着看定义。我换个角度说——你想想看，一个系统每天产生几亿条日志，或者电商平台每秒几万笔订单，这些数据怎么从源头流到下游？传统做法是A系统直接调B系统的API。但一旦流量暴涨，B系统扛不住，A系统也跟着卡死。更麻烦的是，如果B系统挂了，数据就丢了。

Kafka就是来解决这个问题的。它本质上是一个分布式消息队列，但比传统MQ（比如RabbitMQ）能扛的吞吐量高得多。我记得第一次在生产环境压测Kafka，单机轻松跑到每秒几十万条消息，当时确实被震住了。

官方定义说：Kafka是一个分布式、分区、多副本的流处理平台。说白了，它就是一个数据高速公路——生产者把数据扔上去，消费者从上面取数据，中间的数据由Kafka帮你存着、管着、保证不丢。

一句话总结：Kafka = 高性能消息队列 + 持久化存储 + 流处理能力。它不是简单的“发消息”，而是能让你把数据存下来反复消费，甚至做实时计算。

1.2 Kafka核心概念——一张图看懂

下面这张图是我自己画的，把Kafka最核心的五个概念串在一起。你盯着看两分钟，后面讲细节就轻松了。

Kafka核心概念架构图 Kafka 核心概念架构图 Producer 生产者 发布消息 写入 Broker 集群 Topic（主题） Partition 0 Partition 1 Partition 2 每个 Partition 有序，Topic 内无序 拉取 Consumer 消费者 订阅消息 💡 数据流向： Producer → Topic（多个Partition）→ Consumer Group 每个 Partition 只能被同一个 Consumer Group 内的一个消费者消费

1.3 五个核心概念，一个一个说清楚

1.3.1 Broker——Kafka服务器节点

Broker就是Kafka集群中的一台服务器。你可以把它理解成一个数据仓库的保管员。一个集群通常有3台或更多Broker，这样一台挂了，数据还在别的机器上。

我个人习惯在生产环境至少部署3个Broker。为什么？因为Kafka的副本机制需要至少3个节点才能保证高可用。我曾经见过有人图省事只搭了1个Broker，结果磁盘坏了，所有数据全丢——嗯，那场面确实不太好看。

1.3.2 Topic——数据分类的标签

Topic是Kafka里最基础的概念。你可以把它想象成一个文件夹，或者一个消息的类别。比如订单数据发到"order_topic"，日志数据发到"log_topic"，互不干扰。

Topic本身不存数据，它只是一个逻辑分类。真正存数据的是下面要说的Partition。

命名建议：我习惯用"项目名_数据类型"的格式，比如"shop_order_paid"、"shop_user_login"。别用中文，也别用特殊字符，Kafka对Topic名称有限制，踩过坑你就知道了。

1.3.3 Partition——真正存数据的地方

一个Topic可以分成多个Partition。每个Partition是一个有序的、不可变的日志文件。新消息永远追加到末尾，不能修改。

为什么要分区？两个原因：

  • 水平扩展：一个Topic的数据量太大，单台机器存不下。分成多个Partition，可以分布到不同Broker上。
  • 并行消费：一个Partition只能被一个消费者消费，但多个Partition可以被多个消费者同时消费，吞吐量就上去了。

举个例子：假设"order_topic"有3个Partition，分布在3台Broker上。你起了3个消费者，每人负责一个Partition，消费速度就是单机的3倍。

注意：Partition内的消息是有序的，但Topic整体是无序的。如果你的业务要求全局有序（比如金融交易流水），那就只能设1个Partition。但代价是吞吐量受限——这是典型的"一致性 vs 性能"取舍。

1.3.4 Producer——消息的生产者

Producer负责把消息发到Kafka。它不直接发到Broker，而是发到某个Topic的某个Partition。

Producer可以指定把消息发到哪个Partition，也可以让Kafka自己决定（默认轮询或根据key哈希）。我一般在需要保证同一用户的消息有序时，用用户ID作为key，这样同一个用户的消息永远进同一个Partition。

// 伪代码示例：Producer发送消息
producer.send(new ProducerRecord<>(
    "order_topic",          // Topic名称
    "user_12345",           // Key（用于分区路由）
    orderJson               // 消息内容
));

1.3.5 Consumer——消息的消费者

Consumer从Kafka拉取消息。注意是"拉取"（pull），不是"推送"（push）。Consumer主动去Broker拿数据，而不是Broker塞给Consumer。这样做的好处是Consumer可以根据自己的处理能力控制消费速度，不会被打爆。

Consumer通常以Consumer Group的形式工作。同一个Group内的消费者共同消费一个Topic，每条消息只会被Group内的一个消费者处理。不同Group之间互不影响——这就实现了"发布-订阅"模式。

概念 一句话解释 我踩过的坑
Broker Kafka服务器，存数据、管数据 磁盘空间要监控，日志默认保留7天，不注意会写满
Topic 消息的分类标签 Topic数量别太多，上千个Topic会拖慢ZooKeeper
Partition 真正存数据的单元，有序日志 Partition数设好后别轻易改，会影响数据分布
Producer 发消息的一方 记得设置acks=all，否则可能丢消息
Consumer 收消息的一方 消费完要提交offset，不然重启后会重复消费

1.4 Kafka能干什么？三个典型场景

1.4.1 日志收集——最经典的应用

这是Kafka最开始的用途。公司里几十台服务器，每台都在产生日志。传统做法是每台机器写本地文件，出问题时一台一台去翻，效率极低。

用Kafka之后，所有机器的日志统一发到Kafka，下游用Logstash或Flink消费，写入Elasticsearch。这样就能在Kibana里实时搜索日志了。我曾经帮一个客户做过这套方案，之前排查一个问题要半小时，后来缩短到两分钟。

1.4.2 流处理——实时计算的核心

Kafka配合Kafka Streams或Flink，可以做实时流处理。比如：

  • 实时统计电商网站每秒钟的订单金额
  • 检测异常登录行为，触发告警
  • 实时更新推荐系统的用户画像

说白了，就是数据一边进来一边算，不用等存到数据库再跑批处理。我做过一个实时风控系统，从用户下单到风控结果返回，延迟控制在200毫秒以内。

1.4.3 事件溯源——记录所有变更

事件溯源（Event Sourcing）是一种架构模式：不保存系统的当前状态，而是保存所有发生过的事件。Kafka的日志结构天然适合做这件事——每条消息就是一个事件，不可修改，按时间顺序排列。

比如一个订单系统，每次状态变更（创建、支付、发货、完成）都作为一条事件写入Kafka。如果需要知道订单当前状态，就把所有事件重放一遍。这样做的好处是：可以回溯任意时间点的状态，方便审计和排查问题。

我的建议：如果你是第一次接触Kafka，先别急着搞流处理和事件溯源。从日志收集开始，把Producer、Consumer、Topic、Partition这几个概念玩熟。等你能熟练地收发消息了，再往深了走。一步一步来，稳一点。

1.5 本章小结

这一章我们把Kafka的定位和核心概念过了一遍。你不需要记住所有细节，但下面这几点最好留在脑子里：

  • Kafka是一个高性能的分布式消息队列，能存数据、能算数据
  • Topic是分类，Partition是真正的存储单元
  • Producer发消息，Consumer收消息，Broker管消息
  • 日志收集、流处理、事件溯源是三个最常用的场景
← 上一章 📖 返回目录 下一章 →