在现代分布式系统架构中，故障 不再是偶发的异常，而是具有 统计必然性的常态。任何规模化的微服务系统在长期运行中，都不可避免地会面临网络分区、节点资源耗尽或数据库连接饱和等问题 [1]。因此，系统架构设计必须建立在「故障必然发生」这一基本假设之上。
虽然基础的 重试机制 能通过指数退避策略解决暂时的网络抖动，但在高并发场景下，单纯依赖重试往往独木难支，甚至可能引发灾难性的后果。为了构建具备高韧性的系统，我们需要引入更高级的中间件模式来解决供需失衡与级联故障问题：
-
消息队列（Message Queue）—— 流量的持久化容器与缓冲
当上游请求量远超下游处理能力，且数据决不允许丢弃时，同步调用会导致系统崩溃或数据丢失。消息队列在此扮演了「蓄水池」的关键角色。- 异步解耦与持久化：将请求写入具备持久化能力的队列中，确保即使下游暂时不可用，数据依然安全存储不丢失。
- 削峰填谷：系统利用队列的堆积能力容纳突发流量，将上游的瞬时高压转化为下游可以接受的平稳流速，实现存储空间换处理时间、延迟时间换服务质量的策略。
-
限流器（Rate Limiter）—— 流量整形与下游保护
为了防止重试风暴（Retry Storm）或积压数据的瞬间释放击穿下游，限流器不再作为拒绝策略执行者，而是作为 流量整形器（Traffic Shaper） 存在。- 平滑速率：采用令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法，严格控制消息投递给下游的速率。无论队列中积压了多少数据，都强行将流速限制在下游系统的安全水位之下。
- 背压机制（Backpressure）：当达到限流阈值时，严禁直接丢弃请求。策略转变为暂缓从队列拉取消息。这种机制将压力反向传导至消息队列进行积压，确保下游服务始终在最佳负载下运行，同时保证了所有业务请求最终都能被处理。
综上所述，消息队列负责 全量接纳并保存 突发流量，而限流器负责 匀速释放 流量。两者结合，在确保数据不丢失的前提下，有效解决了上下游处理能力不对等的问题。
分布式系统：概念与设计 (原书第 5 版)。 ↩︎
2026/1/1大约 13 分钟
