第 1 章一笔订单为什么需要 Kafka

先从一个熟悉的场景开始

你在购物网站按下“下单”。订单服务把订单写进数据库，随后还需要通知库存、发送短信、更新销售统计。最直接的做法是订单服务挨个调用这些系统。

这会产生两个问题。第一，慢系统拖累下单：短信服务卡了五秒，用户也可能等待五秒。第二，业务彼此绑得很紧：每增加一个新系统，订单服务都需要增加调用逻辑。

我们可以改成：订单服务记录“订单已经创建”这个事实，把它交给 Kafka；短信服务、统计服务分别从 Kafka 读取它。订单服务不用知道所有读者是谁。

订单服务 ──发送──> Kafka 的 orders 主题
                       ├──> 通知服务
                       ├──> 销售统计
                       └──> 风控分析

这叫作异步解耦。“异步”表示后续工作不必全部在同一次请求中结束；“解耦”表示系统减少对彼此实现细节和可用性的依赖。

假设平时每秒 100 个订单，促销时变成每秒 5,000 个。下游每秒只能处理 1,000 个，Kafka 可以暂时保存来不及处理的记录，让下游稍后继续。这叫削峰填谷。它不会凭空增加处理能力：流量长期高于消费能力时，积压仍然持续增长，最终会遇到存储或保留时间边界。

如果后来新增一个“订单地区分析”系统，它可以读取仍被保留的历史记录。这叫回放。已经被保留策略删除的数据不能靠修改消费进度找回来。

Kafka 是分布式事件流平台。现在先把它想象成一套“可多人订阅、按序追加、保存一段时间的日志”。日志在这里是一串数据记录，不只是程序报错文件。

Kafka 适合持续产生的大量事件、多个独立读者、需要历史回放的业务。它不自动替你完成库存事务、短信重试和订单查询。只需要少量后台任务时，更简单的任务队列也可能足够；按订单号查当前状态，通常仍然使用业务数据库。

本章自测：Kafka 能让慢消费者永远不扩容吗？不能。它能缓冲压力，不能消除长期的处理能力缺口。