流控、背压与稳定性机制

Category

server / runtime 子树。节点定位：流控、背压与稳定性机制解决「系统快不起来时会怎样」——高峰先炸队列、背压传播路径、容量上限显式设计、背压与业务优先级同设计。

Definition

流控、背压和稳定性机制，解决的不是“系统快不快”，而是“系统在快不起来的时候会怎样”。这对游戏运行时尤其关键，因为很多故障不是来自完全崩溃，而是来自慢慢积压：

• 消息越堆越多。
• 队列越排越长。
• 慢消费者拖垮快生产者。
• 某个节点还活着，但延迟越来越离谱。

如果没有流控和背压，系统通常不会优雅退化，而会在一段时间后突然雪崩。

Problem

渐进积压式故障比崩溃更常见也更难查：「先接住再慢慢处理」通常是坏策略，队列满员时的体验劣化顺序应由优先级决定而不是随机发生。容量上限必须显式设计，背压必须和业务优先级一起设计。

为什么高峰时真正先炸的是队列

游戏系统里最容易积压的地方通常不是 CPU，而是队列：

• 网关写缓冲。
• Actor 邮箱。
• 异步任务队列。
• 持久化写队列。
• 广播待发列表。

高峰来时，如果系统只会“继续接、继续塞、继续等”，那么所有慢链路最终都会把压力传给队列。流控和背压的意义，就是在队列失控前把压力显式表达出来。

流控、背压和稳定性机制分别在做什么

流控

流控关注的是：系统允许多少请求、多少消息、多少任务进入某条链路。它更偏入口治理。

背压

背压关注的是：下游已经变慢时，上游如何感知并减速、丢弃、降级或拒绝。它更偏链路传播。

稳定性机制

稳定性机制关注的是：系统在负载异常时如何仍保持可恢复、可解释、可降级。它通常包括流控和背压，但不止于此。

为什么“先接住再慢慢处理”通常不是好策略

这是最常见的直觉错误。很多系统在高峰来时会选择：

• 能收就先收。
• 任务先入队。
• 后面慢慢消费。

这种策略在短时小峰值下可能有效，在持续高压或下游慢故障场景下通常很危险。因为：

• 队列增长会带来更大尾延迟。
• 更大尾延迟又让超时和重试变多。
• 重试变多会进一步放大入口流量。

最后系统不是“顶住了”，而是靠积压把故障推迟了一会儿。

背压最常见的几种传播路径

连接层背压

网关或连接层发不出去，写缓冲开始积压。如果业务层无感知，仍继续推送，最终会拖垮连接或整条事件循环。

Actor / 队列背压

某个 Actor、房间或消费者处理不过来，邮箱或队列堆积。如果上游继续按正常速度生产，热点模块就会成为全局稳定性风险。

存储层背压

数据库、缓存、日志系统变慢，上游任务大量等待回写。如果没有隔离，核心逻辑也会被拖慢。

稳定系统通常会准备哪些手段

比较稳妥的系统，通常不会只准备一种手段，而会组合使用：

• 入口限流。
• 队列容量上限。
• 优先级隔离。
• 超时和丢弃策略。
• 降级路径。
• 熔断与快速失败。

举例来说：

• 登录洪峰时，外围通知可以延后，核心鉴权优先。
• 房间广播积压时，非关键状态可以降频或覆盖旧值。
• 活动高峰时，埋点和报表可异步降级，奖励发放链路优先保。

关键不是“永不丢消息”，而是“关键链路先活下来”。

容量上限必须是显式设计

成熟系统通常会给关键缓冲和队列明确上限：

• 单连接写缓冲上限。
• 单房间广播积压上限。
• 单 Actor 邮箱上限。
• 单节点异步任务队列上限。

一旦超限，就必须有明确策略：

• 拒绝。
• 降级。
• 丢弃过期消息。
• 转托管。
• 暂停接单。

没有上限的队列，本质上只是把故障延迟暴露。

背压必须和业务优先级一起设计

背压从来不是纯技术动作，它必须结合业务优先级一起设计。否则系统会出现很荒诞的情况：

• 公告、红点、聊天把战斗广播拖慢。
• 埋点、日志回写把结算链路拖慢。
• 外围活动任务把登录峰值拖住。

所以一个更实用的问题是：如果系统现在只能处理一半流量，哪一半必须活，哪一半可以晚、可以降、可以丢。

一个更贴近实践的退化顺序

比较稳妥的系统往往会按层次退化：

1. 先丢低优先级和可过期消息。
2. 再降级外围异步链路。
3. 再限制新流量进入。
4. 最后才考虑影响核心主链路。

如果系统没有这套退化顺序，高峰时就只能全线一起抖。

为什么这些机制必须提前做

很多团队喜欢等压测后再补流控和背压。这个顺序通常太晚了。因为：

• 没有容量边界，压测很难看出真实故障形态。
• 没有优先级隔离，压测只能证明系统会一起死。
• 没有降级路径，高峰演练没有任何工程抓手。

流控、背压和稳定性机制不该是“优化项”，而是架构起点之一。

常见误区

• 把队列当成无限缓冲器，觉得“先接住总没错”。
• 没有优先级隔离，结果外围流量拖垮核心链路。
• 只看平均吞吐，不看尾延迟、积压长度和超限行为，最后系统表面没挂，体验却已经不可用。

真正成熟的系统，不是没有高峰，而是在高峰到来时仍然知道该先保什么、该放弃什么。

实战案例：一次「公告把战斗广播拖垮」的背压与优先级排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「为什么高峰时真正先炸的是队列」「容量上限必须是显式设计」「背压必须和业务优先级一起设计」用到深水区：系统没崩，广播却慢了 50 倍——这是渐进积压式故障的排查，也是「怎样让关键链路在高峰先活下来」的完整展开。

背景与现象：某 MMO，一场整点全服活动开始后，房间广播延迟从 60 毫秒涨到 3.5 秒；战斗手感全面劣化但没有任何服务崩溃，指标上「一切正常」。网关写缓冲峰值 2.8 万条，持续 5 分钟才消化完。

第一步：现象与口径——把「没崩」和「不可用」分开记

延迟口径：房间广播 P99 60 毫秒 → 3.5 秒，劣化 58 倍；CPU 利用率只有 45%——不是算力不够，是消息排不上队。

积压口径：网关写缓冲峰值 2.8 万条，其中全服公告、红点刷新、聊天消息占 83%——外围消息把战斗广播挤在了后面。

超时口径：战斗操作超时率 0.2% → 2.1%，玩家重试进一步放大入口流量。

第二步：分层归因——按本页三条传播路径排查

广播延迟劣化归因  占比
  无优先级隔离，外围消息与战斗广播同队列      61%
  无容量上限，队列无界增长                    24%
  无降级与丢弃策略，超限只能硬扛             15%

排查路径：三条传播路径里中了两条——连接层背压（写缓冲积压）和队列背压（广播待发列表堆积）。存储层正常。根子在第 61% 那条：所有消息一个队列一个优先级，公告一刷，战斗广播就得排队。

第三步：根因——背压没有和业务优先级一起设计

队列能装下所有消息，却没有回答「只能处理一半流量时，哪一半必须活」。公告、红点、聊天和战斗广播同优先级同队列，高峰一来外围流量把核心链路拖慢——正是本页说的那种「表面没挂，体验却已经不可用」。

第四步：处置与回填——先分优先级，再设上限，最后定退化顺序

1. 优先级隔离：战斗广播、结算确认走高优先级队列；公告、红点、聊天走低优先级队列，且单连接写缓冲按优先级配额。
2. 显式容量上限：单连接写缓冲、单房间广播积压、单节点任务队列各自设上限；战斗广播超限丢弃可覆盖的旧状态，公告超限直接延后。
3. 退化顺序四层：先丢低优先级可过期消息，再降级外围异步链路，再限制新流量进入，最后才动核心主链路。
4. 广播积压治理：非关键状态降频或覆盖旧值，不做逐条补发。

复核账：广播 P99 延迟 3.5 秒 → 80 毫秒；写缓冲峰值 2.8 万条 → 4000 条；战斗操作超时率 2.1% → 0.1%；下一次全服活动同口径复测，核心链路无劣化。

回填清单：

回填项	动作	回填处
优先级隔离	战斗广播与外围消息分队列，写缓冲按优先级配额	为什么高峰时真正先炸的是队列
显式容量上限	写缓冲、广播积压、任务队列各自设上限，超限有明确策略	容量上限必须是显式设计
退化顺序	丢低优先级 → 降外围 → 限入口 → 动核心，四层写进预案	一个更贴近实践的退化顺序
背压与优先级同设计	「哪一半必须活」按业务优先级回答，不按到达顺序	背压必须和业务优先级一起设计

案例的三个教训

1. 「先接住再慢慢处理」是把故障推迟，不是顶住。队列无界增长只会把雪崩挪到几分钟后，且来得更猛。
2. 没有优先级隔离，高峰就是外围拖垮核心。公告一刷、战斗就卡——哪一半必须活必须提前回答，不能等高峰来现场分。
3. 指标上「没崩」不等于体验可用。CPU 利用率 45% 的系统照样能把广播拖慢 58 倍——要看尾延迟、积压长度和超限行为，不能只看平均吞吐。

Used By

高峰防护设计；队列与容量上限约定；背压传播路径评审。

• Nakama（commit e920249）：背压落到连接层的直接证据——写出口队列满主动断开（server/session_ws.go:438，ErrSessionQueueFull），保活靠读截止与 ping 心跳（:194、:383）

Related

关系链：高峰炸队列 → 三机制分工 → 接住策略辨析 → 传播路径 → 手段集 → 显式上限 → 优先级。上游：runtime/03（Tick 与任务配合）。下游：server/capacity（容量模型）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。