分布式系统如何设计降级优先级？

简化版

降级优先级应按业务价值、正确性风险、资源消耗和依赖关系预先分级：先关闭高成本低价值、可延迟或可替代的能力，最后才影响交易主链路。优先级必须落实为独立配额、队列和开关，并通过压测验证；事故现场临时决定“先关什么”通常已经太晚。

详细版

可以把能力分为核心、重要、增强和后台四级。核心能力要守住业务不变量和最小闭环；重要能力允许限额或延迟；增强功能可返回默认结果；后台任务可暂停。排序不能只看产品价值，还要看关闭后释放多少瓶颈资源，以及它是否是其他能力的前置依赖。

工程上建立“功能—依赖—资源”矩阵，计算每项能力的 QPS、CPU、数据库连接和下游调用。为不同级别设置独立并发池和配额，过载时按顺序丢弃，而不是让低优先级流量先占满共享资源。降级响应必须明确是旧数据、处理中还是不可用，不能伪造成功。

触发依据应组合资源水位与用户 SLI，并使用连续窗口和滞回防抖。恢复时顺序与关闭相反但要逐级放量，确认容量余量后再恢复下一层。每个开关都要有所有者、有效期、审计和演练。

完整版教学

一、为什么降级需要优先级

系统过载时资源已经不足，不可能让所有功能保持原服务水平。若没有优先级，线程调度和请求到达顺序会随机决定谁成功，批量报表甚至可能抢走支付请求的数据库连接。主动牺牲低价值工作，才能让有限容量用于核心闭环。

降级优先级不是简单的产品功能排行榜。一个页面装饰功能价值低但几乎不耗资源，关闭它无助于数据库过载；一个高价值历史报表查询很耗资源且可延迟，事故时反而应先暂停。

心法：优先关掉“释放瓶颈资源最多、业务损失最小”的能力，而不是只关看起来不重要的页面元素。

二、先定义业务最小闭环

最小闭环是故障期间仍要完成的端到端业务。例如电商可以定义为登录、查询关键商品信息、创建订单和确认支付；推荐、评价、个性化排序不属于最小闭环。若库存事实不可用，下单也不能为了“保可用”而虚假成功。

可按四级整理：P0 核心且不可错误，P1 重要但可限额，P2 可替代或返回旧值，P3 可暂停后台工作。分级要由业务、研发和运维共同确认，避免事故中争论。

级别	示例	过载动作	数据语义
P0	支付确认、库存扣减	保证配额，必要时快速失败	不允许假成功
P1	订单查询	限流、短时旧快照	标记更新时间
P2	推荐、评价摘要	默认榜单或关闭	允许旧/默认结果
P3	报表、离线回填	暂停并保留进度	恢复后继续

三、用资源收益校准关闭顺序

每项能力都要映射到真实瓶颈。数据库连接耗尽时，关闭只耗 CPU 的功能效果有限；出口带宽满时，缩减大响应比减少轻量查询有效。可以用“释放资源/业务损失”作为排序思路，但不必伪造一个绝对精确分数。

假设推荐接口占 25% CPU、10% 数据库连接，关闭后转热门缓存；报表只占 5% CPU，却占 35% 数据库连接。当前瓶颈是连接池时应先停报表；CPU 满时推荐降级收益更大。优先级可随故障类型选择不同预案。

数据库过载预案：暂停报表 -> 限制复杂查询 -> 查询走快照 -> 保护交易写
CPU 过载预案：关闭实时推荐 -> 降低序列化成本 -> 限制大响应 -> 保护核心计算

四、隔离资源才能执行优先级

只有标签没有资源隔离，低优先级请求仍会先占满公共线程池。应为不同级别设置并发上限、队列、数据库连接配额或消费者组；调度器在拥塞时优先拒绝低级别，并保证 P0 至少拥有保留容量。

假设连接池共 100 个，可为 P0 保留 50，P1 最多 30，P2/P3 共用 20。平时可允许借用空闲配额，但过载时要能回收，否则“弹性共享”会让保留失效。队列也需独立，避免 P3 的 1 万个任务排在 P0 前面。

跨服务传递优先级时不能信任外部客户端任意声明 P0，应由可信网关根据认证身份和业务路由赋值，防止优先级滥用。

五、触发和防抖怎么设计

单个 CPU 尖峰不应立即关闭功能，持续过载又不能等到超时爆发才动作。可组合队列等待、连接池使用率、P99 和错误率，要求连续多个窗口超阈值；恢复阈值应低于进入阈值并保持一段时间。

进入一级降级：连接池>85% 且持续60秒，或 P99>800ms 连续3个窗口
进入二级降级：连接池>95% 或核心错误率>2%
退出一级降级：连接池<65% 且核心 SLI 正常持续5分钟

触发规则必须用压测和历史事件校准。固定阈值不理解周期容量时，可加入自适应基线，但关键保护仍需硬上限。

六、降级结果必须保持业务诚实

关闭推荐可以隐藏模块，查询走缓存应展示更新时间，写请求无法确认时应返回处理中或失败。最危险的是把技术兜底值当成真实业务事实，例如风控超时默认通过、库存未知默认有货，这会把可用性故障变成安全或资损事件。

对机器调用方要给稳定错误码和 Retry-After；对用户要避免诱导重复操作。降级期间产生的待处理任务需要持久化和幂等键，以便恢复后安全执行。

功能开关默认值也要安全。配置中心不可达时，P0 保护策略不应自动失效。

七、恢复顺序和演练

资源恢复后先保证 P0 稳定，再逐级恢复 P1、P2、P3。后台积压最容易在恢复时制造洪峰，应按剩余容量限速处理。若恢复 P2 后核心 P99 再次恶化，应自动退回上一级，而非继续全开。

演练要模拟不同瓶颈并验证实际释放量。例如关闭报表后数据库活跃连接是否从 98 降到 65，支付成功率是否恢复；若没有改善，优先级矩阵或依赖认知有误。

degradation_level: 2
disabled_capabilities: [reports, realtime_recommendation]
db_connections_released: 33
core_success_rate: 99.97%
pending_background_jobs: 82000

八、常见误区与追问

• 误区：非核心功能都应最先关闭。 要看它是否消耗当前瓶颈资源，关闭零成本功能并不能止血。
• 误区：有功能开关就完成了降级设计。 还需资源隔离、触发规则、响应语义和恢复流程。
• 误区：高优先级请求永远不应失败。 守不住正确性时要快速失败，不能用错误结果维持表面成功。
• 误区：恢复时一次性打开所有功能。 缓存回源和积压会形成二次洪峰，应逐级恢复并观察。
• 追问：优先级如何防伪造？ 由可信入口根据身份与业务类型赋值，内部签名或受控传播，不接受用户自由指定。
• 追问：保留容量会不会浪费？ 可在正常时允许低优先级借用，但必须在拥塞时可抢占或快速回收。
• 追问：怎样证明降级有效？ 用故障场景压测，比较动作前后瓶颈资源、核心 SLI 和业务损失。

九、加强记忆

按“定核心、找瓶颈、算收益、隔资源、慢恢复”设计降级优先级。先守住业务不变量和最小闭环，再选择真正能释放当前瓶颈的能力；用独立配额让优先级可执行，明确退化语义，最后逐级恢复并处理积压。降级的价值不在关掉多少功能，而在有限资源下保住正确的功能。