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

学习目标能说清 Kafka 是什么、适合什么、不适合什么。能解释 broker、topic、partition、offset、consumer group 的关系。能用命令创建 topic、发送消息、消费消息、查看消费组状态。Kafka 是什么Kafka 是一个分布式事件流平台。它表面上像消息队列但核心模型不是“把消息投递给某个消费者后立刻删除”而是“把事件追加写入一个可持久化、可分区、可复制的日志中消费者按 offset 自己读取”。这带来几个关键差异对比项普通队列视角Kafka 事件流视角数据生命周期消费后通常删除按保留策略保存可回放消费进度队列维护投递状态消费者组维护 offset扩展方式增加队列或消费者增加 partition、broker、consumer典型能力异步解耦异步解耦 数据总线 回放 流计算Kafka 适合什么Kafka 适合高吞吐、可回放、多订阅方、事件流式处理的场景订单事件订单创建后库存、积分、优惠券、风控系统分别订阅。用户行为日志Web/App 埋点进入 Kafka再进入实时计算、数据湖、画像系统。数据同步业务数据库变更通过 CDC 写入 Kafka再分发到搜索、缓存、数仓。IoT 上报设备持续上报状态Kafka 接住洪峰后端服务按能力处理。实时指标实时计算 UV、PV、支付成功率、异常告警。Kafka 不适合什么Kafka 不是所有队列场景的默认答案不适合场景原因替代思路极低延迟 RPCKafka 是日志系统不是请求响应框架HTTP/gRPC复杂任务调度Kafka 不负责延迟队列、任务状态机、重试编排Quartz、XXL-JOB、Temporal小团队简单异步运维成本可能高于收益Redis Stream、RabbitMQ、云队列强事务跨系统一致性Kafka 事务只覆盖 Kafka 内部和部分生产者语义本地事务表、Saga、Outbox核心组件BrokerBroker 是 Kafka 服务节点。一个 Kafka 集群由多个 broker 组成。每个 broker 存储若干 partition 的日志数据处理客户端读写请求并参与副本复制。TopicTopic 是消息分类。比如order-events订单事件。payment-events支付事件。user-behavior用户行为日志。Topic 不是一个单文件队列而是由多个 partition 组成。PartitionPartition 是 Kafka 扩展吞吐和并行消费的基本单位。每个 partition 内部是有序追加日志不同 partition 之间不保证全局顺序。如果 topic 有 6 个 partition一个消费组最多可以让 6 个消费者实例并行消费。第 7 个消费者会空闲因为同一个消费组内一个 partition 同一时刻只能分配给一个消费者。OffsetOffset 是消息在 partition 内的位置编号。消费者提交 offset 表示“我已经处理到哪里”。Kafka 保存的是日志消费者保存的是进度。Consumer GroupConsumer Group 是一组共同消费某个 topic 的消费者。不同消费组之间互不影响都会读到同一份消息。例子inventory-service消费组处理库存。coupon-service消费组处理优惠券。risk-service消费组处理风控。三者都订阅order-events但各自维护自己的 offset。Kafka 架构关系ProducerTopic: order-eventsPartition 0Partition 1Partition 2Broker 1Broker 2Broker 3Consumer A / group inventoryConsumer B / group inventoryConsumer C / group risk第一组实操启动 Kafka 并收发消息进入 CLI democdkafka-knowledge-system/demos/cli-kafka-labdockercompose up-ddockercomposeps创建 topicdockercomposeexeckafka kafka-topics\--bootstrap-server localhost:9092\--create\--topicorder-events\--partitions3\--replication-factor1查看 topicdockercomposeexeckafka kafka-topics\--bootstrap-server localhost:9092\--describe\--topicorder-events发送消息dockercomposeexec-Tkafka kafka-console-producer\--bootstrap-server localhost:9092\--topicorder-eventsEOF {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验证标准验证项命令预期结果Kafka 正常启动docker compose pskafka状态为 runningTopic 创建成功kafka-topics --describe能看到 3 个 partition消息写入成功console producer无报错消息消费成功console consumer能打印 JSON 消息Offset 已提交kafka-consumer-groups --describeCURRENT-OFFSET大于 0常见误区认为 topic 有序。准确说法是partition 内有序topic 级别默认不保证全局有序。认为消息消费后删除。准确说法是Kafka 按保留时间或大小删除与是否消费无直接关系。认为消费者越多越快。准确说法是同一消费组内并行度上限受 partition 数量限制。认为 Kafka 一定不丢消息。准确说法是可靠性取决于 producer ack、broker 副本、consumer offset 提交策略。02 Topic、分区、生产者和消费者本章目标本章解决 Kafka 日常开发最常见的问题Topic 应该怎么设计。Partition 数量怎么估算。Producer 如何保证顺序、吞吐和不丢。Consumer 如何控制并发、提交 offset、处理失败。Topic 设计Topic 是事件类型边界不是业务表的简单复制。一个好 topic 应该表达事件语义而不是表达某个方法调用。推荐命名命名含义说明order-events订单领域事件包含 CREATED、PAID、CANCELLEDpayment-events支付领域事件支付成功、失败、退款user-behavior-events用户行为事件点击、曝光、搜索inventory-commands库存命令如果明确是命令而不是事实事件不推荐命名命名问题test无业务语义难治理service-a-to-service-b强耦合两个服务order-table容易把 Kafka 当数据库同步表all-eventsSchema 混乱权限和保留策略难控制事件建模示例订单创建事件建议带上事件 ID、业务 ID、事件类型、版本和发生时间{eventId:EVT-20260502-0001,eventType:ORDER_CREATED,eventVersion:1,occurredAt:2026-05-02T20:30:0008: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 核心配置配置推荐值作用acksall等待 leader 和 ISR 副本确认提高可靠性enable.idempotencetrue开启幂等生产避免重试导致重复写入retries较大值可恢复错误自动重试delivery.timeout.ms业务可接受范围发送总超时时间linger.ms5-50等待更多消息组成批次提高吞吐batch.size32KB-128KB 起调批次大小compression.typelz4或zstd降低网络和磁盘压力可靠生产者配置示例spring.kafka.producer.acksall spring.kafka.producer.retries10 spring.kafka.producer.properties.enable.idempotencetrue spring.kafka.producer.properties.delivery.timeout.ms120000 spring.kafka.producer.properties.linger.ms10 spring.kafka.producer.properties.batch.size65536 spring.kafka.producer.properties.compression.typelz4Consumer 核心配置配置推荐值作用enable.auto.commitfalse手动提交避免处理失败但 offset 已提交auto.offset.resetearliest或latest无 offset 时从哪里开始读max.poll.records业务处理能力内单次拉取数量max.poll.interval.ms大于单批最大处理时间防止处理慢被踢出消费组session.timeout.ms10-30s心跳会话超时partition.assignment.strategycooperative sticky降低再均衡影响手动提交的基本原则拉取消息 - 执行业务处理 - 业务处理成功 - 提交 offset如果顺序反了拉取消息 - 提交 offset - 执行业务处理业务处理失败时Kafka 会认为消息已经处理完造成业务丢失。消费失败处理策略策略适用场景风险立即重试网络抖动、临时数据库失败可能阻塞 partition有限次重试大多数业务异常需要记录失败原因死信队列 DLT无法处理的脏数据需要补偿流程跳过并告警非核心日志类消息可能丢业务语义暂停消费下游故障、避免雪崩堆积增长需要容量预案Spring Kafka 中常用DefaultErrorHandler配合DeadLetterPublishingRecoverer。本包项目 demo 已实现失败重试和 DLT。再均衡 RebalanceRebalance 是消费组内 partition 分配关系发生变化的过程。触发场景消费者实例新增或退出。消费者心跳超时。topic partition 数量变化。订阅 topic 变化。Rebalance 期间部分 partition 会暂停消费。生产环境要降低频繁 rebalance处理逻辑不要阻塞太久。合理设置max.poll.interval.ms。使用静态成员 IDgroup.instance.id。使用 cooperative sticky 分配策略。优雅停机让消费者主动退出。实操观察消费组和分区分配创建 3 分区 topicdockercomposeexeckafka 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.partitiontrue\--propertyprint.offsettrue再打开第二个终端启动第二个消费者观察两个消费者分配 partition 的变化dockercomposeexeckafka kafka-console-consumer\--bootstrap-server localhost:9092\--topicpartition-lab\--grouppartition-group\--propertyprint.partitiontrue\--propertyprint.offsettrue发送带 key 的消息dockercomposeexeckafka kafka-console-producer\--bootstrap-server localhost:9092\--topicpartition-lab\--propertyparse.keytrue\--propertykey.separator:输入O1001:created O1001:paid O2001:created O2001:paid验证点相同 key 通常进入同一个 partition同一个 partition 内 offset 递增。