跳转到内容

Kafka for FDE(FDE 的 Kafka 事件流入门)

知识库位置:FDE Knowledge Base/03 Engineering/Data Engineering/Kafka/Kafka-for-FDE.md 定位:Enterprise Field Primer(企业环境入门页);Canonical(权威)事件概念见 Event-Driven Integration(事件驱动集成) 术语不确定时,请查阅 Glossary(中英文术语表)。

Kafka 是一种分布式事件流平台。

对于 FDE,可以先把它理解为:

Producer(生产者)
↓
Topic(主题)
↓
Kafka
↓
Consumer(消费者)

它常用于:

  • event streaming(事件流)
  • system integration(系统集成)
  • data pipelines(数据管道)
  • event-driven architecture(事件驱动架构)

客户可能说:

数据在 Kafka。

或者:

我们所有系统事件都发 Kafka。

FDE 需要知道:

  • 如何消费
  • 数据是否重复
  • 顺序是否保证
  • Schema(结构)如何管理
  • Consumer lag(消费滞后)是什么

不必默认成为 Kafka Cluster Operator(集群运维者)。


Topic 可以理解为:

一类事件流。

例如:

customer-events(客户事件)
order-events(订单事件)
payment-events(支付事件)

负责发送事件。

例如:

Order Service(订单服务)
↓
OrderCreated(订单已创建)
↓
Kafka

负责读取并处理事件。

例如:

Kafka
↓
Analytics Consumer(分析消费者)

Topic 被拆为多个 Partition(分区)。

作用:

  • parallelism(并行)
  • scale(扩展)

但重要:

顺序通常只在 Partition 内保证。

不是整个 Topic 全局保证。


多个 Consumer 可以组成 Group(组)。

同一个 Partition 在一个 Consumer Group 内通常由一个 Consumer 处理。

用于:

Parallel Processing(并行处理)

Offset 表示 Consumer 读到了哪里。

它决定:

  • resume(续读)
  • replay(重放)
  • consumer progress(消费进度)

Kafka 不是传统 Queue(队列)的简单等价物。

事件通常可以保留一段时间。

因此 Consumer 可以:

replay historical events(重放历史事件)。


10. At-least-once Delivery(至少一次投递)

Section titled “10. At-least-once Delivery(至少一次投递)”

企业 Kafka 集成中非常重要的现实:

Duplicate event should be expected.(重复事件应被视为常态。)

因此 Consumer 要考虑:

Idempotency(幂等性)

11. Idempotent Consumer(幂等消费者)

Section titled “11. Idempotent Consumer(幂等消费者)”

例如收到:

InvoicePaid(发票已支付)
event_id = 123

两次。

Consumer 不应该因此:

给客户加两次余额。

应有:

  • event ID(事件编号)
  • processed event record(已处理事件记录)
  • idempotency key(幂等键)

Event(事件)应具有稳定 Schema(结构)。

例如:

OrderCreated(订单已创建)
order_id(订单号)
customer_id(客户号)
timestamp(时间戳)
amount(金额)
currency(币种)

Schema 变化必须考虑:

  • backward compatibility(向后兼容)
  • forward compatibility(向前兼容)
  • consumer impact(对消费者的影响)

Lag 表示:

Latest Event Offset(最新事件位移)
-
Consumer Processed Offset(消费者已处理位移)

如果 Lag 不断增加:

Consumer 处理速度跟不上生产速度。

这是常见生产指标。


事件最好表达:

已经发生的事实。

例如:

OrderCreated(订单已创建)
PaymentReceived(已收到付款)
CustomerUpdated(客户已更新)

而不是:

DoOrderProcessing(执行订单处理)

后者更像 Command(命令)。


如果用户需要:

立即得到结果。

通常 REST 更自然。

如果系统需要:

发布“某件事发生了”,让多个下游处理。

Kafka / Event(事件)更适合。

两者经常组合使用。


FDE 不需要过度理论化。

简单理解:

传统 Queue 常关注:

Work distribution(工作分发)

Kafka 更强调:

Durable event stream(持久事件流)
+
Replay(重放)
+
Multiple consumer groups(多消费者组)

17. FDE Consumer Example(FDE 消费者示例)

Section titled “17. FDE Consumer Example(FDE 消费者示例)”
OrderCreated(订单已创建)
↓
Kafka
↓
Customer 360 Consumer(客户 360 消费者)
↓
Update customer profile(更新客户档案)

必须考虑:

  • duplicate(重复)
  • out-of-order(乱序)
  • missing event(丢事件)
  • schema change(结构变化)

不要假设所有事件永远按业务时间顺序到达。

例如:

CustomerUpdated(客户已更新)

可能比更早事件先处理。

需要:

  • event timestamp(事件时间戳)
  • version(版本)
  • sequence(序列号)
  • conflict handling(冲突处理)

19. Retry and Dead Letter Handling(重试与死信处理)

Section titled “19. Retry and Dead Letter Handling(重试与死信处理)”

消费失败时,需要决定:

Retry?(重试?)
Backoff?(退避?)
Skip?(跳过?)
Dead-letter?(进死信?)
Stop consumer?(停消费者?)

错误事件不能无限阻塞整条流。


可能涉及:

  • authentication(认证)
  • ACL(Access Control List,访问控制列表)
  • encryption(加密)
  • topic permission(主题权限)

Consumer 不应默认获得:

所有 Topic。


21. Questions FDE Should Ask(FDE 应问的问题)

Section titled “21. Questions FDE Should Ask(FDE 应问的问题)”
Which topic?(哪个主题?)
Who owns it?(谁负责?)
What does each event mean?(每个事件什么含义?)
Schema?(结构?)
Partition key?(分区键?)
Delivery semantics?(投递语义?)
Can events duplicate?(事件会重复吗?)
Retention?(保留期?)
Expected volume?(预期流量?)
Consumer lag SLO?(消费滞后目标?)
Replay allowed?(允许重放吗?)
PII included?(含个人身份信息吗?)

22. Common Failure Modes(常见失败模式)

Section titled “22. Common Failure Modes(常见失败模式)”

Failure 1 — Assume Exactly Once(假设精确一次)

Section titled “Failure 1 — Assume Exactly Once(假设精确一次)”

Consumer 实际没有 Idempotency(幂等)。

Failure 2 — Ignore Partition Key(忽略分区键)

Section titled “Failure 2 — Ignore Partition Key(忽略分区键)”

相关实体事件进入不同 Partition,顺序失控。

Failure 3 — Schema Breaking Change(破坏性结构变更)

Section titled “Failure 3 — Schema Breaking Change(破坏性结构变更)”

Producer(生产者)更新导致 Consumer 全挂。

Failure 4 — Infinite Retry(无限重试)

Section titled “Failure 4 — Infinite Retry(无限重试)”

Poison message(毒消息)持续阻塞。

Failure 5 — No Monitoring(无监控)

Section titled “Failure 5 — No Monitoring(无监控)”

Consumer lag 已经几小时没人发现。


23. Troubleshooting Signals(排障信号)

Section titled “23. Troubleshooting Signals(排障信号)”

Kafka 流程出问题时检查:

Producer actually sent?(生产者真的发了?)
Correct topic?(主题对吗?)
Consumer group?(消费者组对吗?)
Partition?(分区对吗?)
Offset?(位移对吗?)
Lag?(滞后多少?)
Schema?(结构对吗?)
Deserialization?(反序列化成功?)
Permission?(有权限?)
Processing exception?(处理异常?)

24. How Deep Should an FDE Go?(FDE 应掌握到多深?)

Section titled “24. How Deep Should an FDE Go?(FDE 应掌握到多深?)”

目标:

Level B — Operate(B 级:操作)

FDE 应能:

  • 理解 Kafka mental model(心智模型)
  • 消费事件
  • 诊断基本 lag / duplicate / schema 问题
  • 设计 idempotent consumer(幂等消费者)
  • 判断 REST vs Event(接口 vs 事件)

不要求:

深度调优 Broker(代理节点)、Replication(副本)、Controller(控制器)等平台内部机制。