本文分享使用 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点令人头疼的调试难题。