上线配置要保护核心链路不能让所有请求平等抢资源资源紧张时如果所有请求共享同一批 worker、队列和连接最重要的用户操作往往也会一起变慢。把连接池调大或多开几个 worker只能暂时推高上限不能回答一个更根本的问题资源不够时系统准备保留什么又允许放弃什么。以判题服务为例提交代码和查询判定结果通常属于核心路径生成详细解释、批量统计、缓存预热等能力则可能延迟或暂停。优先级策略的价值在于把这种业务判断落实到队列、并发、超时和反馈上而不是写一段口号放在故障预案里。先把能力分成可执行的等级优先级不宜太细。先列出必须在压力下继续服务的路径、可以等待的路径和可以临时关闭的路径并写清每一种失败时用户会得到什么反馈。低优先级任务进入独立队列或有独立并发上限时即使它们积压也不会立刻吃掉核心路径全部工作者。队列满了不能悄悄丢任务。不同任务可选择拒绝并提示稍后再试、持久化后延迟执行、合并重复任务或交给后台处理。具体策略取决于任务是否可重试、是否有副作用、用户是否需要及时看到结果。关键是状态明确调用方知道任务没有被无声吞掉。不要把所有请求都标成高优先级。标签一旦失去区分能力系统又会回到无序竞争。优先级需要由真正的用户影响和业务时限决定而不是由每个功能负责人自行申请。配置要可审查也要能快速收紧优先级、队列容量、并发预算和降级开关应由版本化配置管理。配置至少应有默认值、负责人、变更说明和上一版本的回退方式。业务节奏变化时可以调整策略而不必修改和发布一段临时代码故障时也能快速关闭非核心能力。配置的修改仍需要评审。把某项任务升为高优先级意味着它会与其他核心任务争资源不是一次无成本的标签变更。对于敏感操作可要求变更同时说明受影响的队列、预期负载和恢复条件。开关的语义要单一。例如“停止生成解释”只影响解释生成不应同时关闭提交记录或结果查询。开关越模糊故障期间越容易误伤核心功能。上线前就要确认开关在配置中心、服务缓存和各副本间的生效时间不能等事故发生后才发现有的实例还在跑旧策略。防止低优先级占住关键资源简单的优先级队列不一定足够。低优先级任务可能先拿到数据库连接、文件句柄、沙箱配额或共享锁然后让高优先级任务在资源前等待这就是常见的优先级反转。排查时不要只看队列顺序还要看关键共享资源由谁持有、持续多久。对最关键的资源可以设置预留额度或按类别隔离。比如核心判题保留一部分 worker 与沙箱容量后台统计只能使用其余容量或者低优先级任务达到阈值后不再进入会占用共享锁的阶段。隔离会降低平时的资源利用率但在高峰或故障时能换来更可预测的服务。等待也需要上限。低优先级任务无限积压会占用内存和调度开销超过保留窗口后应按任务类型取消、合并、落库或通知调用方。清理策略必须保留审计信息避免用户无从得知任务为何没有完成。在压力下验证策略而不是只测正常路径测试环境可以同时发起不同等级的请求逐步增加负载观察核心路径的等待、错误率和资源占用是否仍在目标范围内。然后触发低优先级开关、模拟队列满和共享资源紧张确认核心服务确实得到保护而不是只有监控面板上的标签变化。还应测试优先级标记错误、配置回滚和副本配置不一致。错误标记不应让任务绕过全部限制回滚后积压任务如何处理也需要有预期。演练结果要能说明策略的边界而不是只证明某一轮压测成功。降级并不承诺每个功能在任何时候都可用。它做的是一件更实际的事资源不足时优先把有限能力留给最需要的操作。把这个判断写进配置、队列和资源管理核心链路才不会在高峰时被非核心工作悄悄挤掉。