Kafka 基础：从消息队列到事件流平台

学习目标

1. 能说清 Kafka 是什么、适合什么、不适合什么。
2. 能解释 broker、topic、partition、offset、consumer group 的关系。
3. 能用命令创建 topic、发送消息、消费消息、查看消费组状态。

Kafka 是什么

Kafka 是一个分布式事件流平台。它表面上像消息队列，但核心模型不是“把消息投递给某个消费者后立刻删除”，而是“把事件追加写入一个可持久化、可分区、可复制的日志中，消费者按 offset 自己读取”。

这带来几个关键差异：

Kafka 适合什么

Kafka 适合高吞吐、可回放、多订阅方、事件流式处理的场景：

• 订单事件：订单创建后，库存、积分、优惠券、风控系统分别订阅。
• 用户行为日志：Web/App 埋点进入 Kafka，再进入实时计算、数据湖、画像系统。
• 数据同步：业务数据库变更通过 CDC 写入 Kafka，再分发到搜索、缓存、数仓。
• IoT 上报：设备持续上报状态，Kafka 接住洪峰，后端服务按能力处理。
• 实时指标：实时计算 UV、PV、支付成功率、异常告警。

Kafka 不适合什么

Kafka 不是所有队列场景的默认答案：

核心组件

Broker

Broker 是 Kafka 服务节点。一个 Kafka 集群由多个 broker 组成。每个 broker 存储若干 partition 的日志数据，处理客户端读写请求，并参与副本复制。

Topic

Topic 是消息分类。比如：

• order-events：订单事件。
• payment-events：支付事件。
• user-behavior：用户行为日志。

Topic 不是一个单文件队列，而是由多个 partition 组成。

Partition

Partition 是 Kafka 扩展吞吐和并行消费的基本单位。每个 partition 内部是有序追加日志；不同 partition 之间不保证全局顺序。

如果 topic 有 6 个 partition，一个消费组最多可以让 6 个消费者实例并行消费。第 7 个消费者会空闲，因为同一个消费组内，一个 partition 同一时刻只能分配给一个消费者。

Offset

Offset 是消息在 partition 内的位置编号。消费者提交 offset 表示“我已经处理到哪里”。Kafka 保存的是日志，消费者保存的是进度。

Consumer Group

Consumer Group 是一组共同消费某个 topic 的消费者。不同消费组之间互不影响，都会读到同一份消息。

例子：

• inventory-service消费组处理库存。
• coupon-service消费组处理优惠券。
• risk-service消费组处理风控。

三者都订阅order-events，但各自维护自己的 offset。

Kafka 架构关系

第一组实操：启动 Kafka 并收发消息

进入 CLI demo：

cdkafka-knowledge-system/demos/cli-kafka-labdockercompose up-ddockercomposeps

创建 topic：

dockercomposeexeckafka kafka-topics\--bootstrap-server localhost:9092\--create\--topicorder-events\--partitions3\--replication-factor1

查看 topic：

dockercomposeexeckafka kafka-topics\--bootstrap-server localhost:9092\--describe\--topicorder-events

发送消息：

dockercomposeexec-Tkafka kafka-console-producer\--bootstrap-server localhost:9092\--topicorder-events<<'EOF' {"orderId":"O1001","status":"CREATED","amount":99.8} {"orderId":"O1002","status":"PAID","amount":199.0} EOF

消费消息：

dockercomposeexeckafka kafka-console-consumer\--bootstrap-server localhost:9092\--topicorder-events\--from-beginning\--grouporder-demo-group\--timeout-ms5000

查看消费组：

dockercomposeexeckafka kafka-consumer-groups\--bootstrap-server localhost:9092\--describe\--grouporder-demo-group

验证标准

常见误区

1. 认为 topic 有序。准确说法是：partition 内有序，topic 级别默认不保证全局有序。
2. 认为消息消费后删除。准确说法是：Kafka 按保留时间或大小删除，与是否消费无直接关系。
3. 认为消费者越多越快。准确说法是：同一消费组内并行度上限受 partition 数量限制。
4. 认为 Kafka 一定不丢消息。准确说法是：可靠性取决于 producer ack、broker 副本、consumer offset 提交策略。

02 Topic、分区、生产者和消费者

本章目标

本章解决 Kafka 日常开发最常见的问题：

• Topic 应该怎么设计。
• Partition 数量怎么估算。
• Producer 如何保证顺序、吞吐和不丢。
• Consumer 如何控制并发、提交 offset、处理失败。

Topic 设计

Topic 是事件类型边界，不是业务表的简单复制。一个好 topic 应该表达事件语义，而不是表达某个方法调用。

推荐命名：

不推荐命名：

事件建模示例

订单创建事件建议带上事件 ID、业务 ID、事件类型、版本和发生时间：

{"eventId":"EVT-20260502-0001","eventType":"ORDER_CREATED","eventVersion":1,"occurredAt":"2026-05-02T20:30:00+08:00","orderId":"O1001","userId":"U1","amount":99.8,"status":"CREATED"}

字段设计要点：

• eventId：用于幂等处理和排查。
• eventType：一个 topic 可以承载同一领域内多个事件类型。
• eventVersion：用于兼容升级。
• occurredAt：事件真实发生时间，不等于 Kafka 写入时间。
• orderId：适合作为消息 key，保证同一订单进入同一 partition。

Partition 设计

Partition 决定并行度、吞吐、顺序边界和未来扩展成本。

Partition 数量估算

简单公式：

partition_count = max(目标写入吞吐 / 单分区写入吞吐, 目标消费吞吐 / 单消费者吞吐)

例子：

• 峰值写入：60 MB/s。
• 单 partition 稳定写入：10 MB/s。
• 单消费者处理：5 MB/s。
• 目标消费者并行度：12。

则 topic 至少需要：

max(60 / 10, 60 / 5) = max(6, 12) = 12 个 partition

实际生产中还要给未来增长留空间，例如设置为 18 或 24。

Partition 过多的问题

Partition 不是越多越好：

• 文件句柄和日志段数量增加。
• leader election 更慢。
• Controller 元数据压力更大。
• Consumer rebalance 时间变长。
• 小流量 topic partition 过多会浪费资源。

消息 Key 与顺序

Kafka 只保证同一个 partition 内有序。生产者发送消息时，如果指定 key，默认分区器会根据 key 哈希选择 partition。

如果要保证同一订单的状态事件顺序：

key = orderId topic = order-events

这样O1001的CREATED -> PAID -> SHIPPED会进入同一个 partition。

注意：如果后期增加 partition，同一个 key 的哈希结果可能变化，只能保证变更后新消息进入新规则下的 partition，不能保证跨变更的全局顺序连续。

Producer 核心配置

可靠生产者配置示例：

spring.kafka.producer.acks=all spring.kafka.producer.retries=10 spring.kafka.producer.properties.enable.idempotence=true spring.kafka.producer.properties.delivery.timeout.ms=120000 spring.kafka.producer.properties.linger.ms=10 spring.kafka.producer.properties.batch.size=65536 spring.kafka.producer.properties.compression.type=lz4

Consumer 核心配置

手动提交的基本原则：

拉取消息 -> 执行业务处理 -> 业务处理成功 -> 提交 offset

如果顺序反了：

拉取消息 -> 提交 offset -> 执行业务处理

业务处理失败时，Kafka 会认为消息已经处理完，造成业务丢失。

消费失败处理策略

Spring Kafka 中常用DefaultErrorHandler配合DeadLetterPublishingRecoverer。本包项目 demo 已实现失败重试和 DLT。

再均衡 Rebalance

Rebalance 是消费组内 partition 分配关系发生变化的过程。触发场景：

• 消费者实例新增或退出。
• 消费者心跳超时。
• topic partition 数量变化。
• 订阅 topic 变化。

Rebalance 期间，部分 partition 会暂停消费。生产环境要降低频繁 rebalance：

• 处理逻辑不要阻塞太久。
• 合理设置max.poll.interval.ms。
• 使用静态成员 ID：group.instance.id。
• 使用 cooperative sticky 分配策略。
• 优雅停机，让消费者主动退出。

实操：观察消费组和分区分配

创建 3 分区 topic：

dockercomposeexeckafka kafka-topics\--bootstrap-server localhost:9092\--create\--if-not-exists\--topicpartition-lab\--partitions3\--replication-factor1

启动第一个消费者：

dockercomposeexeckafka kafka-console-consumer\--bootstrap-server localhost:9092\--topicpartition-lab\--grouppartition-group\--propertyprint.partition=true\--propertyprint.offset=true

再打开第二个终端启动第二个消费者，观察两个消费者分配 partition 的变化：

dockercomposeexeckafka kafka-console-consumer\--bootstrap-server localhost:9092\--topicpartition-lab\--grouppartition-group\--propertyprint.partition=true\--propertyprint.offset=true

发送带 key 的消息：

dockercomposeexeckafka kafka-console-producer\--bootstrap-server localhost:9092\--topicpartition-lab\--propertyparse.key=true\--propertykey.separator=:

输入：

O1001:created O1001:paid O2001:created O2001:paid

验证点：相同 key 通常进入同一个 partition，同一个 partition 内 offset 递增。