Kafka 不难,只是你用得不对

Abhinav 2025-07-11 09:13:20

Kafka 使用模式

本文分享使用 Kafka 的一些经典模式。有时你感觉 Kafka 好难搞,可能是因为不了解这些模式。

让我们从基础开始:

1.每个事件类型一个主题

反模式:

orders-service-topic
shipping-service-topic
analytics-service-topic

每个服务都有自己的主题?不不不,你要这么搞,那就不是事件驱动设计了,这种设计只能看做是多了些步骤的远程过程调用(RPC)。

正模式:

order.created
order.shipped
order.cancelled

主题应该表示一个什么什么事件,多个服务可以对同一事件做出反应,这样你的架构才能保持松耦合。

2.消费者组 = 一个逻辑工作单元

消费者组很简单:一个组 = 一个合理的业务目的。

但很多团队都把这一点搞砸了。他们为每个实例创建一个消费者组,更糟糕的是,还会为不同的任务重复使用同一个组。

正模式:

  • inventory-updater 仓库更新器
  • email-sender 邮件发送器
  • analytics-processor 分析处理器

这些中的每一个都是独立的组。它们都使用 order.created 并独立完成自己的工作。

这将所有内容解耦。它还具有出色的扩展性——Kafka 会在同一组内的消费者之间对分区进行负载均衡。

3.避免无状态的链式事件

假设你收到一个 order.created 的消息,然后你甚至没有检查任何内容就立即发布一个 order.verified 的消息。这很危险。不要把 Kafka 变成一个愚蠢的消息传递者。

正模式:事件 + 状态

不要为了模拟工作流程而将五个事件串联在一起,而是让事件触发一个拥有逻辑和状态的服务,并且仅在必要时发出下一个事件。

这样可以避免意外的无限循环、幽灵事件和令人困惑的重放错误。

4.使用发件箱模式

有没有试过在插入数据库后向 Kafka 发送消息,结果 Kafka 调用失败?现在你的数据库已更新……但 Kafka 从未收到该消息。恭喜你——你刚刚制造了一个不一致性!

发件箱模式来解决这个问题

将事件作为同一事务的一部分存储在你的数据库中,如下所示:

BEGIN;
INSERT INTO orders (...) VALUES (...);
INSERT INTO outbox (event_type, payload) VALUES ('order.created', '{...}');
COMMIT;

然后运行一个后台任务,读取 outbox 表并将事件发送到 Kafka。

原子!可靠!可重放!

5.采用退避重试

人们认为“Kafka 让一切都可重放”,所以他们滥用它。他们只是不假思索地重新消费失败的事件。

但如果错误是由于下游系统宕机导致的呢?(比如A服务消费Kafka消息时要调用B服务做一些逻辑,此时B服务挂了,进而导致最终未能成功消费)

使用带有指数退避的重试队列,或者使用像Kafka Streams / Debezium这样内置错误处理功能的框架。

或者手动创建如下主题存放消费失败的消息,延迟重试:

  • order.created.retry.1m
  • order.created.retry.10m
  • order.created.dlq

巴辉特提醒:这种 retry 队列的模式很有意思,之前我也未曾关注过。通常来讲,建议一个 topic + 一个 consumer group 作为颗粒度创建一套 retry 队列,因为事件可能有多个 consumer group 来消费。这个知识有点绕,大家可以通过 GPT 了解更多细节。

举例,比如 100 条事件里只有 1 条消费失败,如果持续重试这一条,持续失败,就会影响后面的事件消费。

当然,如果你们的业务逻辑就必须得严格要求顺序,那另当别论,case by case 来看哈。

6. Schema 要全局统一

如果您的事件看起来像这样:

{
  "id": 123,
  "user": "john",
  "total": 100
}

这样没问题……直到有人添加了一个新字段:

{
  "id": 123,
  "user": "john",
  "total": 100,
  "vip": true
}

现在,你的使用者程序出现故障。或者更糟的是—— 悄无声息地出现异常行为。

巴辉特提醒:这个意思是说,consumer 不知道事件格式发生变化,可能会引起故障,需要一个机制,让所有人知道消息格式变了,而且消息格式需要兼容性。

使用 Avro/Protobuf + Schema Registry,你会得到:

  • 向前/向后兼容性
  • 严格类型标注
  • 演进支持

当团队壮大时,你会感谢自己的这种做法。

简单的Kafka架构图

          +------------------+
          |  Order Service   |
          |------------------|
          | Emits: order.created |
          +--------+---------+
                   |
                   v
          +--------+---------+
          |     Kafka         |
          |-------------------|
          | Topics:            |
          | - order.created    |
          | - order.retry      |
          | - order.dlq        |
          +--------+----------+
                   |
       +-----------+------------+
       |           |            |
       v           v            v
+-----------+ +--------------+ +------------------+
|Inventory  | |Email Service | |Analytics Service |
|Updater    | |(Consumer)    | |(Consumer)        |
+-----------+ +--------------+ +------------------+

每个服务都是一个独立的消费者组,对相同的事件做出反应。发件箱模式(未显示)在生产者端实现。

最终想法

Kafka 并不难。你跳过了那些让事情变得易于处理的模式,结果反而把事情弄复杂了。

你越早遵循这些原则,Kafka就越早成为一个健壮、可扩展的事件驱动系统的支柱,而不是凌晨3点令人头疼的调试难题。

原文:https://codingplainenglish.medium.com/kafka-is-hard-because-you-keep-ignoring-these-patterns-588b2ebac3c0

标签: Kafka
快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat