高并发系统为什么总选Kafka？它究竟在扛什么压力？

之前我们聊过 Redis 在高并发场景里的作用，核心是它能把大量原本直接冲击数据库和下游服务的高频请求先拦截下来，做一轮缓冲和分散。

但光靠 Redis 还不够。

高并发系统真正难扛的，往往不只是“读多写多”，还有另一类更棘手的问题：

• 某个瞬间请求量太大，后端处理速度跟不上
• 一个动作要连带触发一堆后续操作，调用链越拉越长
• 某个下游服务突然变慢，把整个请求拖死
• 有些操作根本不需要同步完成，却全堵在主链路里
• 短时间的流量尖峰直接把系统打穿

这时候就需要消息队列出场。

而在大多数公司里，首选往往是 Kafka。

很多人都知道 Kafka 常被用在高并发场景，也清楚它是一个消息队列。可如果再追问一句：Kafka 到底在扛什么？答案就容易停留在“异步”“解耦”“削峰填谷”这几个关键词上。

这些词本身没错，但如果只背概念而不理解本质，很容易“知道名词，不知道为什么”。

更准确地说：Kafka 在高并发系统里扛的，核心并不是“消息”本身，而是那些本来不该直接压在主链路上的处理压力。

这篇文章就把这件事拆开讲透。

一、先抛结论：Kafka 不是“高级版队列”，而是流量缓冲和异步解耦层

不少人第一次接触 Kafka，会把它简单理解成“从一个服务把消息传给另一个服务的中间件”。这个理解太窄了。

在高并发系统里，Kafka 实际承担的角色通常包括：

• 异步解耦
• 削峰填谷
• 缓冲突发流量
• 延迟处理
• 广播通知
• 顺序消费
• 日志采集和流式处理

所以 Kafka 真正的价值并不只是“消息传递”，而是：它把本来必须同步完成、必须立刻压到下游、必须在当前请求里做完的事情，改造成了可缓冲、可异步、可逐个拆解的事情。

二、为什么高并发系统光靠同步调用很容易扛不住？

举一个最常见的业务场景：用户下单。

如果全程同步处理，链路可能是这样的：

1. 写订单
2. 扣库存
3. 发优惠券
4. 发站内信
5. 记录日志
6. 更新推荐系统
7. 通知物流系统

也就是说，一个请求进来，主线程要一口气把这些事全做完。

问题也很明显：

• 只要其中一个环节变慢，整个请求就变慢
• 只要其中一个下游挂掉，整个请求就容易失败
• 只要流量突然暴涨，后面的服务就会被直接牵连压垮

所以高并发系统最忌讳的就是把所有事情串在主链路上同步执行——同步链路越长，系统越脆弱。

而 Kafka 的第一大价值，就是把大量“不必当场做完”的事情从同步调用中拆出来。

三、Kafka 最常见的作用之一：异步解耦

继续看下单这个例子。

对用户而言，真正核心的可能就两件事：

1. 订单创建成功
2. 系统及时给出响应

至于：

• 发短信
• 发优惠券
• 写行为日志
• 推送给推荐系统
• 通知其他业务方

这些事确实重要，但未必要在用户请求还挂着的时候同步完成。

这时就可以改成：

• 主流程完成核心操作
• 发一条消息到 Kafka
• 其他服务各自异步消费这条消息

这样改动的价值很大：

1. 主链路明显缩短
2. 用户响应更快
3. 下游服务故障不会立刻拖死主流程
4. 系统耦合度大幅下降

所以 Kafka 在这里解决的，本质上是把“强耦合同步链路”变成“弱耦合异步协作”。

四、Kafka 为什么特别适合“削峰填谷”？

这是 Kafka 在高并发场景中最经典的用途之一。

所谓削峰填谷，说白了就是：流量瞬间涌来时很猛，但后端处理能力是有限的，绝不能任凭流量直接砸到下游。

比如秒杀、抢购、活动报名这类场景，常见情况是：

• 某一秒内突然涌入几万甚至几十万请求
• 但后面的订单服务、库存服务、数据库根本处理不过来

如果这些请求全部同步打到后端，极容易出现：

• 服务线程打满
• 数据库连接池耗尽
• 接口超时
• 整条链路雪崩

Kafka 在这里的作用就像一个缓冲带：

• 前面先把请求对应的消息写入 Kafka
• 后面的消费者按自己能承受的速度处理
• 突发流量先堆在队列里，而不是直接打穿下游

换句话说：Kafka 把“瞬时并发压力”转换成了“可持续消费压力”。 这就是削峰填谷最本质的意义。

五、为什么 Kafka 能扛“峰值”，而数据库扛不住？

因为两者设计目标截然不同。

数据库更擅长：

• 持久化数据
• 复杂查询
• 事务保证
• 结构化存储

而 Kafka 更擅长：

• 高吞吐写入
• 顺序追加
• 批量消费
• 流式传递

简单比方：

• 数据库像是一个要认真记账、校验、维护索引和一致性的系统
• Kafka 更像一条专门用来“先收下来，再慢慢分发”的高速通道

因此，面对短时间的大量写入，Kafka 通常比数据库更适合作为第一层承接点。这也是为什么很多高并发架构不会让所有请求直接“先干数据库”，而是先进消息队列。

六、Kafka 到底在“扛”什么？

1. 主链路压力
本来必须同步完成的事情，现在可以异步化，主请求压力就下来了。

2. 下游承载上限
本来流量会直接冲击库存、优惠券、通知、推荐等下游服务，现在先被 Kafka 缓住。

3. 流量尖峰
本来瞬间高峰会直接打爆后端，现在变成先写入队列、后续慢慢处理。

4. 系统耦合
本来一个服务要直接依赖一大堆下游，现在只需要发消息，消费者各自处理。

所以 Kafka 扛的不是某一个具体接口，而是同步链路里那些本来不该直接压在核心请求上的处理压力。

七、Kafka 为什么常常和“最终一致性”一起出现？

因为一旦你把同步改成异步，就意味着：有些事情不会在同一个时刻全部完成了。

比如用户下单成功后，优惠券系统、积分系统、消息通知系统可能要几秒后才陆续处理。

这时系统就从“强同步一致”变成了“最终一致”。

所以 Kafka 常见的语义不是：

• 现在立刻全部完成

而是：

• 核心动作先成功
• 其他动作稍后异步完成
• 最终系统整体状态一致

这也解释了为什么 Kafka 经常出现在：

• 订单后处理
• 账户流水通知
• 数据同步
• 异步补偿
• 事件驱动架构

这些典型场景里。

八、Kafka 适合什么样的业务？

综合来看，满足下面这些特征的业务，就很适合引入 Kafka：

1. 后续处理很多，但不必同步完成
比如下单后发券、支付后发通知、注册后发欢迎消息。

2. 流量可能突然暴增，需要缓冲
比如秒杀、活动报名、抢券、热点事件触发的大量消息。

3. 需要异步解耦多个下游
比如一个订单事件要被多个系统消费；一个用户行为要被推荐、风控、画像等多个系统使用。

4. 更关注吞吐量，而不是单条消息的即时处理
比如日志采集、埋点上报、行为流处理。

九、Kafka 不是万能的，它也会带来新问题

Kafka 帮你解决了异步解耦、削峰填谷、流量缓冲、高吞吐传递这些问题，但同时也带来一批新的挑战：

• 消息重复消费
• 消息丢失风险
• 消费积压
• 顺序消费难题
• 消费失败重试
• 幂等处理
• 生产者和消费者的延迟监控
• 消息堆积导致的业务延迟

也就是说：Kafka 不是消灭了问题，而是把“同步压力问题”转换成了“异步链路治理问题”。
所以高并发系统上了 Kafka，并不是变轻松了，只是问题的类型变了。

十、为什么 Kafka 常常和幂等一起讲？

因为消息队列场景里一个非常现实的问题是：同一条消息，消费者可能不止处理一次。

原因有很多：

• 消费后还没来得及提交就挂掉了
• 重试机制导致重复消费
• 网络抖动造成状态不确定
• 上游重复发送

所以只要用了 Kafka，就基本绕不开幂等设计。比如：

• 同一笔订单不能重复发券
• 同一笔支付不能重复记账
• 同一条注册消息不能重复赠送新人礼包

这也是为什么很多人讲高并发时，会把 Kafka、异步、幂等放在一起讲——它们天生就是一组问题。

十一、Kafka 和 Redis 的角色有什么不同？

Redis 更偏向：

• 快速访问
• 热点缓存
• 高频状态操作
• 计数
• 限流
• 轻量协调

Kafka 更偏向：

• 异步传递
• 流量缓冲
• 解耦下游
• 削峰填谷
• 广播事件
• 延迟处理

总结一下：

• Redis 更像是“高频访问前置层”
• Kafka 更像是“高并发异步缓冲层”

所以它们经常一起出现，但解决的不是同一类问题。

十二、所以高并发为什么常用 Kafka？

因为高并发系统最怕的就是把所有请求、所有处理、所有下游调用都堆在主链路和瞬时峰值上，而 Kafka 正好能把这些压力拆开、缓冲、异步化。

更具体地说，Kafka 被广泛采用，是因为它特别擅长做这几件事：

1. 把非核心处理从主链路里拆出去
2. 先把突发流量接住，避免直接打穿下游
3. 将同步调用改造成异步消费
4. 让多个系统围绕同一事件进行松耦合协作

所以 Kafka 真正解决的，远不止“它能发消息”这么简单。
而是当流量飙升、链路变长、下游变多时，系统绝不能把所有压力都塞在当前请求里硬扛，而 Kafka 正好用来分担这部分压力。

十三、最后总结

1. Kafka 在高并发系统里，不只是消息队列，更是异步解耦和流量缓冲层。
2. 它最核心的价值，是把原本会直接压在主链路和下游服务上的压力拆开、削峰、异步化。
3. 常见使用场景包括：异步通知、订单后处理、削峰填谷、流式处理、系统解耦等。
4. Kafka 解决的是高并发下的吞吐和链路压力问题，但它也会带来重复消费、积压、顺序、幂等等新问题。
5. 所以 Kafka 不是“万能解”，但它确实是高并发系统里非常重要的一层异步缓冲能力。

如果对高并发架构或消息队列的落地细节还有疑问，欢迎到云栈社区一起交流。