深夜的急诊室，永远在打仗。胸痛患者刚被推进来，分诊护士只看一眼，就给他戴上红色腕带——危急。走廊里等着看感冒的人拿着绿色腕带，已经等了三个小时，没人给他插队。突然又推进来一个大出血的病人，急诊医生立刻放下手里的换药盘，先冲去抢救。没有人抱怨，因为大家心里都清楚：急诊室的天条是「先救最危急的」。 分布式集群的调度，就是一场永不落幕的急诊。成千上万的计算任务像患者一样涌进来，CPU、内存、GPU 这些「医生和床位」永远不够用。调度器就是那位分诊护士：它给每个任务发腕带（优先级）、安排排队（队列）、决定谁先上手术台。当危急任务到了却没床位时，它还得把不那么急的任务暂时请出去（抢占），把资源让给最需要的人。但如果每个人都喊自己「最危急」，急诊室就会乱成踩踏现场——这对应的正是调度领域的「抢占风暴」。 这篇文章用「急诊室的一天」当主线，把优先级队列、抢占触发、资源回收、风暴防护、Kubernetes 配置和 SLA 保障讲得明明白白。读完你会有种错觉：自己真的当过那晚的分诊护士，知道什么该保、什么该让、什么该防。

岗位关联

学会优先级与抢占，你就拿到了集群资源紧张时的「急救手册」——在混部与云原生场景下保住关键任务不掉 SLA、不饿死低优任务，这是 AI 工程师的核心竞争力。

目录
  1. 可视化演示
  2. 急诊分诊台：优先级队列设计
  3. 床位告急：抢占触发条件
  4. 绿色通道：资源回收策略
  5. 防踩踏：避免抢占风暴
  6. 科室制度：Kubernetes 里的配置
  7. 保命优先：SLA 与混部保障
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示优先级队列调度、抢占触发回收机制和四级优先级层级配置，切换模式查看调度核心环节。

本节配有交互动效（进入视口后自动加载，约 3KB）。

优先级队列调度 sys(1M):系统关键任务，最高优先级不可被抢占 prod(10K):在线服务，资源紧张时可抢占低优任务 出队复杂度=O(log n) 调度器从堆顶取出最高优先级任务分配资源

急诊分诊台：优先级队列设计

凌晨两点的急诊室，分诊护士面前排着长队。她不会按先来后到叫号，而是先看腕带：红色危急、黄色较重、绿色普通。红色腕带的病人哪怕刚进门，也会被立刻推进抢救室。分布式调度一模一样：成千上万的 Pod 和作业涌向集群，调度器面前也有「腕带」，只不过换成了数字——优先级。

在分布式调度里，每个任务提交时都会被赋予一个优先级数字。数字越大，在就绪队列里排得越靠前。调度器维护的不是一条队列，而是多条按优先级分级的队列：高优先级队列永远是第一个被翻阅的名单，中优先级次之，低优先级垫底。这跟分诊台完全同构——不同颜色腕带对应不同队列，护士总是先处理最危急的。

光有分级还不够，同一级里还要讲「权重」。假如中优队列任务特别多，权重机制可以让它按比例分到部分调度机会，而不是被高优队列彻底堵死。更关键的是，如果高优任务像洪水一样源源不断，低优任务可能永远轮不到——这就是「饿死」。急诊室的做法是让护士定期重新评估候诊病人，调度器对应的机制叫「老化」：任务等得越久，有效优先级自动抬升。

急诊室的护士每隔一小时重新扫一遍候诊区：如果某个绿色腕带的病人已等四个小时，她会给他换一条黄色腕带。老化机制做的正是这件事——排队再靠后的任务，也不会被永远遗忘在角落。

Peff(t)=Pbase+⌊twaitTage⌋\displaystyle P_{\text{eff}}(t) = P_{\text{base}} + \left\lfloor \frac{t_{\text{wait}}}{T_{\text{age}}} \right\rfloor
老化公式：等待时间每超过一个老化周期，有效优先级就自动加一档，让低优任务排得再久也有机会轮上。
  1. 有效优先级 $P_{\text{eff}}(t)$调度器真正用来排序的分数，等于基础优先级加上等待带来的加成。
    Peff(t)P_{\text{eff}}(t)
  2. 基础优先级 $P_{\text{base}}$任务刚提交时由用户或优先级类指定的原始优先级，相当于入院时发的腕带。
    PbaseP_{\text{base}}
  3. 取整符号 $\lfloor \cdot \rfloor$向下取整，只有等待满一个完整周期才升级，避免优先级抖动过频。
    ⌊twaitTage⌋\left\lfloor \frac{t_{\text{wait}}}{T_{\text{age}}} \right\rfloor
  4. 老化周期 $T_{\text{age}}$一个可配置的时间窗口，等待时长除以周期，得到攒了几次「升级机会」。
    twaitTage\frac{t_{\text{wait}}}{T_{\text{age}}}

床位告急：抢占触发条件

急诊室的病床全部占满，走廊里又推进来一个大出血的病人。护士长不能让他站着等，只能想办法腾床。分布式集群里，调度的「病床」就是节点的 CPU、内存、GPU。高优任务到达时，调度器先做一件看似朴素的事：算账。

算账的规则很直白：一个节点上所有任务已经分配的资源，加上新任务需要的资源，不能超过节点总容量。这就像病床区有多少张床、住了几个人、新病人需要几张床，一加一减立刻见分晓。算完账发现装不下，抢占机制才有资格登场。

但「装不下」只是前提，真正的抢占触发需要三个条件同时满足：第一，高优任务在任何现有节点上都放不下；第二，存在低优任务占用着可回收资源；第三，高优任务的等待时间已经超过预算。三个条件缺一不可，否则调度器只会把任务继续放到队列里等，不会贸然抢。这一步在 Kubernetes 里叫「抢占预选」——先假装驱逐一遍，看资源够不够，不够就放弃。

护士长不会一看到病床满了就立刻赶人。她会先确认：新病人是不是真的危急？病房里有没有能转移的病人？转移后床位够不够？三个答案都是「是」，绿色通道才会真正打开。

∑i∈NRi(alloc)+Rneed≤RN(cap)\displaystyle \sum_{i \in N} R_i^{(\text{alloc})} + R_{\text{need}} \leq R_N^{(\text{cap})}
调度可行性公式：节点上已分配资源加上新任务需求，必须小于等于节点容量；不等式不成立，就是抢占的「病危通知书」。
  1. 已分配总和 $\sum_{i \in N} R_i^{(\text{alloc})}$节点上所有已调度任务占用的资源之和，相当于病床区已入住人数。
    ∑i∈NRi(alloc)\sum_{i \in N} R_i^{(\text{alloc})}
  2. 新任务需求 $R_{\text{need}}$待调度高优任务需要的资源量，相当于新病人要占的床位数。
    RneedR_{\text{need}}
  3. 节点容量 $R_N^{(\text{cap})}$节点的总资源能力，房间一共就这么多床，住满了就是住满了。
    RN(cap)R_N^{(\text{cap})}
  4. 不等式方向 $\leq$放得下就正常调度，放不下则不等式被打破，抢占流程随即启动。
    ∑i∈NRi(alloc)+Rneed≤RN(cap)\sum_{i \in N} R_i^{(\text{alloc})} + R_{\text{need}} \leq R_N^{(\text{cap})}

绿色通道：资源回收策略

既然决定腾床，下一个问题就是：把谁请出去？护士长有自己的算盘——绝不能把刚做完手术的重症病人挪走，那会出人命。她会挑伤势最轻、搬动风险最小的病人，转移到临时观察区。调度器里的角色叫「受害者选择」，原则完全一样：挑代价最小的那个。

代价怎么衡量？用调度领域的代价函数。优先级越低的任务，被选中当受害者的权重越大；占用的资源越多，搬动它造成的浪费越大；运行到一半的任务被终止，还要背负回滚和重算成本。于是公式把「资源规模」和「优先级差值」乘在一起，得到每个任务的抢占代价，再选代价最小的一个。

资源回收不是一锤子买卖，而是一套流程。首先选出受害者列表；然后对每个受害者发起「优雅终止」——不是直接 kill，而是先发信号让它保存 checkpoint、清理状态、优雅退出，就像把病人转移到观察区前先测个血压；接着更新资源记账，把释放的资源划给高优任务；最后把受害者放回就绪队列重新排队。如果驱逐一个还不够，就按代价从低到高继续循环，直到资源凑够为止。

护士长把伤势最轻的病人推到临时观察区，同时给他绑好监护仪、写好交接单——病人没受伤害，床位也腾出来了。优雅终止的精髓就在这：让出资源，但不留下烂摊子。

C(v)=Sv×(Pmax⁡−Pv+1)\displaystyle C(v) = S_v \times \left( P_{\max} - P_v + 1 \right)
受害者代价公式：任务规模乘以优先级差值。规模越大、优先级越低，被选中当受害者的代价越高，就越容易被优先「请出去」。
  1. 抢占代价 $C(v)$把任务 $v$ 挪走造成的综合损失，调度器要选损失最小的那个。
    C(v)C(v)
  2. 任务规模 $S_v$任务占用的 CPU、内存等资源量，规模越大，搬动越痛。
    SvS_v
  3. 优先级差 $(P_{\max} - P_v + 1)$优先级越低，这个权值越大，越容易被选中；加一防止出现零权重。
    (Pmax⁡−Pv+1)\left( P_{\max} - P_v + 1 \right)
  4. 最终选择遍历所有候选者，取代价函数值最小的作为受害者。
    v∗=arg⁡min⁡vC(v)v^{*} = \arg\min_{v} C(v)

防踩踏：避免抢占风暴

如果有一天，所有病人都挂上红色腕带大喊「我最危急」，分诊护士就彻底失灵了——她无法判断谁先谁后，抢救室门口挤成一片，医生连手术台都够不着。这种混乱在调度系统里有一个专门的名字：抢占风暴。

抢占风暴的机制像多米诺骨牌。某个业务高峰，大量高优任务同时到达，低优任务被一个个踢出节点；这些被踢的任务重新排队，又被下一波高优任务抢先；甚至有任务刚跑两秒就被更高优的任务再次抢占。集群的 CPU 全耗在「抢占—重调度—再抢占」的循环里，真正干活的时间少得可怜，系统像进入了「活锁」——谁也没饿死，但谁也干不成活。

防止踩踏，急诊室有三件套。第一，限流：单轮调度只允许有限的抢占名额，就像抢救室一次只推进一个危重病人。第二，冷却：一个节点或队列在冷却窗口内最多被抢占指定次数，被反复欺负的节点会进入「休整期」。第三，软抢占：不直接动粗，而是提示受害者自愿让出——比如触发垃圾回收、优雅缩容，低优任务自己体面退场。这些手段共同把抢占从「人人自危的踩踏」变成「有序让位的协奏」。

急诊室从不会让所有病人同时涌进抢救室——那会把医生淹没。限流和冷却就是给抢占装上「红绿灯」，让系统在高压下依然有序运转。

Wpreempt=Npreempt(Twindow)Twindow≤Wmax⁡\displaystyle W_{\text{preempt}} = \frac{N_{\text{preempt}}(T_{\text{window}})}{T_{\text{window}}} \leq W_{\max}
抢占速率限制公式：在冷却窗口内统计抢占次数除以窗口时长，得到抢占速率；超过上限就暂停新的抢占，让系统喘口气。
  1. 抢占速率 $W_{\text{preempt}}$单位时间内的抢占次数，相当于每分钟冲进抢救室的病人数。
    WpreemptW_{\text{preempt}}
  2. 窗口内次数 $N_{\text{preempt}}(T_{\text{window}})$在一个冷却窗口内实际发生的抢占总数。
    Npreempt(Twindow)N_{\text{preempt}}(T_{\text{window}})
  3. 窗口时长 $T_{\text{window}}$统计的时间段，比如 60 秒，窗口结束后计数清零。
    TwindowT_{\text{window}}
  4. 速率上限 $W_{\max}$配置的抢占阈值，超过后调度器进入「暂停抢占」状态，等待窗口重置。
    Wmax⁡W_{\max}

科室制度：Kubernetes 里的配置

医院会把分诊规则写成制度手册，贴在护士站墙上：什么病挂红腕带、什么病挂绿腕带、抢救室准入条件是什么。Kubernetes 的调度系统也有这样一本手册，核心章节叫 PriorityClass。

PriorityClass 就是腕带等级的定义书。管理员创建一个优先级类，给它起名字、赋数值，数值范围从 0 到 10 亿，越大越优先；还能决定这类任务是否允许抢占别人——preemptionPolicy 两个选项：Never 表示这类任务永远不去抢别人，PreemptLowerPriority 表示可以抢占低优先级任务。如果用户创建 Pod 时没指定优先级类，系统就用 globalDefault 指定的默认类兜底。

配置完成后的工作流，就像急诊室的完整接诊流程。用户提交 Pod 时引用一个 PriorityClass，API 服务器校验合法性，然后调度器开始找节点：先看哪个节点能装下，装不下就启动抢占预选——选出受害者、优雅驱逐、把 Pod 放进去。注意，抢占发生在「调度失败之后」，而不是 Pod 提交的那一瞬间，这跟护士是「发现没床位才去腾床」一个道理。

制度手册存在的意义，是让分诊不依赖于某个护士的个人判断。有了 PriorityClass 和白纸黑字的抢占策略，任何人来操作集群，都知道该给哪个任务挂什么颜色的腕带。

Ppod=max⁡(Pclass,Pdefault),P∈[0,109]\displaystyle P_{\text{pod}} = \max\left( P_{\text{class}}, P_{\text{default}} \right), \qquad P \in [0, 10^9]
Pod 有效优先级公式：一个 Pod 的最终优先级取它引用的优先级类值与系统默认值中的较大者，取值范围是 0 到 10 亿。
  1. Pod 优先级 $P_{\text{pod}}$调度器为这个 Pod 排序时使用的最终分数，相当于它手腕上的最终颜色。
    PpodP_{\text{pod}}
  2. 类值 $P_{\text{class}}$Pod 引用的 PriorityClass 中定义的值，是显式指定的「腕带颜色」。
    PclassP_{\text{class}}
  3. 默认值 $P_{\text{default}}$globalDefault 指定的兜底优先级，用户没指定时自动套用。
    PdefaultP_{\text{default}}
  4. 取值范围 $[0, 10^9]$系统约定优先级数值上限为 10 亿，这个上限值是 Kubernetes 预留的「系统级抢救资源」。
    P∈[0,109]P \in [0, 10^9]

保命优先：SLA 与混部保障

急诊室里最神圣的区域是 ICU：监护仪不能断电，呼吸机不能停摆。对应到集群，那些「不能断」的任务就是在线推理、实时推荐这类延迟敏感服务——晚响应一秒钟，用户就流失了。它们要的保障叫 SLA，翻译成人话就是「我说多久跑到，就得多久跑到」。

现实是，昂贵的 GPU 集群白天夜里都空着很浪费，于是大家玩起了「混部」：让在线服务（急诊 ICU）和离线训练（普通门诊）住进同一个集群。白天在线服务高峰，低优的离线任务被抢占让路；深夜在线流量低谷，离线训练回来把空闲资源填满。这正是优先级与抢占最经典的商业场景——一份资源，两种用途，成本直接砍半。

为了不让「保命」变成「谋杀」，调度器还要配齐三样保障。第一，给延迟敏感任务设置最高优先级类，并预留最小资源配额，相当于 ICU 床位永远锁给危重病人。第二，对在线任务做延迟感知调度，优先把它放到离数据近、网络抖动小的节点。第三，用老化机制给离线任务兜底——等待超过阈值就强制提升优先级，保证低优任务只是「让路」，而不是「断气」。

急诊室最后要守住的两条底线是：危重病人立刻能救，普通病人等得起。SLA 保障让「立刻」成为承诺，老化机制让「等得起」成为事实——这就是调度系统的人道主义。

Peff(j)=Pmax⁡iftwait(j)>Tstarvation\displaystyle P_{\text{eff}}(j) = P_{\max} \quad \text{if} \quad t_{\text{wait}}(j) > T_{\text{starvation}}
饥饿保护公式：当任务的排队等待时间超过饿死阈值，它的有效优先级被强制拉满，确保再低优的任务也一定能轮到执行。
  1. 等待时间 $t_{\text{wait}}(j)$任务从提交到现在一直没被调度的累计时间，相当于病人在候诊区坐的长短。
    twait(j)t_{\text{wait}}(j)
  2. 饿死阈值 $T_{\text{starvation}}$管理员设定的容忍上限，超过这个时间仍未执行，就判定为「濒临饿死」。
    TstarvationT_{\text{starvation}}
  3. 强制升级 $P_{\text{eff}}(j) = P_{\max}$把任务的有效优先级直接提升到全局最高，插队抢救。
    Peff(j)=Pmax⁡P_{\text{eff}}(j) = P_{\max}

AI 应用场景

在线推理与离线训练混部

阶段：模型训练与推理服务的资源调度阶段

解决的问题：传统做法把训练集群和推理集群分开建设，GPU 利用率低、成本翻倍。用优先级加抢占让在线推理（高优）压过离线训练（低优），算力高峰让给推理，低谷填给训练，一份资源干两份活。

具体案例：某推荐团队在 8 卡 A100 集群上同时跑 CTR 模型训练和线上推理。高峰期推理 Pod 因显存不足，P99 延迟从 20ms 飙到 800ms。后来给推理 Pod 配置 PriorityClass=100、训练 Pod=10，并开启 PreemptLowerPriority，显存不够时调度器自动抢占训练 Pod，P99 回落到 25ms。

Kubernetes 大数据混部

阶段：大数据批处理（Spark）与在线微服务的混部调度

解决的问题：在线业务白天空闲夜里高峰，大数据任务白天跑批夜间闲置，两边错峰。混部调度加抢占让两拨任务复用同一批节点，省下近一半机器成本。

具体案例：某电商平台用 Volcano 调度 Spark 作业，把它们塞进在线服务的空闲节点。在线服务 PriorityClass 设为系统级，Spark 设为低优。白天在线高峰，Spark 的 Pod 被优雅驱逐撤退；深夜在线低谷，Spark 回来把节点占满，当年节约 40% 硬件开支。

长尾批任务饥饿保护

阶段：离线训练作业的公平调度

解决的问题：混部场景里低优训练任务总被抢占，可能一周都跑不完一个 epoch。用老化机制让等待久的任务自动提升优先级，给长尾任务一条「死线」。

具体案例：某数据科学团队的低优调参任务在混部集群中频繁被抢。配置老化策略（等待超 30 分钟提升一级优先级）后，任务最迟 2 小时内必定获得执行机会，调参进度不再被在线业务堵死。

Python 演示

python87 行
# -*- coding: utf-8 -*-"""优先级调度与抢占模拟：演示高优任务抢占低优任务并回收资源""" import heapq  class Job:    """一次计算任务，priority 数字越小越紧急"""     def __init__(self, name, priority, duration):        self.name = name        self.priority = priority        self.remaining = duration     def __lt__(self, other):        if self.priority != other.priority:            return self.priority < other.priority        return self.name < other.name  class PreemptScheduler:    """简化版全局调度器：就绪堆 + 抢占逻辑"""     def __init__(self, cores=2):        self.cores = cores        self.ready_queue = []      # 就绪队列（小顶堆）        self.running_map = {}      # 核编号 -> 正在运行的 Job        self.preempt_count = 0     # 抢占总次数        self.starved_count = 0     # 结束时仍滞留的低优任务数     def submit(self, job):        heapq.heappush(self.ready_queue, job)     def _find_victim(self):        """在运行任务中挑优先级最低（数字最大）的当受害者"""        best = None        for core_id, job in self.running_map.items():            if best is None or job.priority > best[1].priority:                best = (core_id, job)        return best     def schedule(self):        """先填空闲核，再判断队首任务是否需要抢占"""        while len(self.running_map) < self.cores and self.ready_queue:            job = heapq.heappop(self.ready_queue)            self.running_map[len(self.running_map)] = job         if not self.ready_queue:            return         top = self.ready_queue[0]        victim = self._find_victim()        if victim is not None and top.priority < victim[1].priority:            core_id, old_job = victim            del self.running_map[core_id]            heapq.heappush(self.ready_queue, old_job)            self.running_map[core_id] = heapq.heappop(self.ready_queue)            self.preempt_count += 1     def tick(self):        """每个时间片：运行任务剩余时间减一，返回刚完成的任务名"""        finished = []        for core_id, job in list(self.running_map.items()):            job.remaining -= 1            if job.remaining <= 0:                finished.append(job.name)                del self.running_map[core_id]        self.schedule()        return finished     def run(self, total_ticks=18):        for _ in range(total_ticks):            for name in self.tick():                print("完成:", name)        self.starved_count = sum(1 for j in self.ready_queue if j.priority >= 2)        print("抢占次数:", self.preempt_count)        print("低优任务滞留数:", self.starved_count)  if __name__ == "__main__":    sched = PreemptScheduler(cores=2)    sched.submit(Job("批处理A", 2, 14))    sched.submit(Job("批处理B", 2, 12))    sched.submit(Job("批处理E", 2, 10))    sched.submit(Job("在线C", 1, 6))    sched.submit(Job("高优D", 0, 4))    sched.run(18)
目的：用一个小型模拟器演示高优任务到达后如何抢占低优任务、受害者如何回队重排，以及低优任务在资源紧张时可能滞留多少。
  1. def __lt__(self, other):为 Job 定义「谁更紧急」：优先级数字小者排前，同级别按名字排序。
  2. heapq.heappush(self.ready_queue, job)新任务入就绪堆，O(log n) 保持有序，队首永远是最紧急的任务。
  3. top = self.ready_queue[0]只看不弹，先瞄一眼队首是否比受害者更紧急。
  4. victim = self._find_victim()在所有运行任务里挑优先级最低的当受害者，对应「最小代价」原则。
  5. if top.priority < victim[1].priority:抢占触发条件：队首的紧急程度压过正在运行的最不紧急任务。
  6. del self.running_map[core_id]先释放受害者占用的核，资源立即回收给高优任务。
  7. heapq.heappush(self.ready_queue, old_job)受害者不是被杀，而是回炉重新排队，对应优雅终止后的 re-queue。
  8. self.starved_count = sum(...)统计结束时仍滞留的低优任务数，直观看到饿死风险。

常见误区

误区我只要把所有任务的 PriorityClass 都设成最高，资源紧张时我的任务就不会被抢走了吧？反正数值越大越厉害。

正解这是典型的「优先级通胀」。所有人都挂红腕带，分诊护士就分不出谁最危急。当所有任务都是最高优，抢占机制反而会频繁启动，高优任务之间互相抢，抢占风暴随之而来。正确做法是只给真正需要保 SLA 的任务设高优先级，其余用中低优先级，并配合配额限制。

为何常见：直觉上认为「数字大 = 赢面大」，忽略了调度系统是一个全局博弈的场所，局部最优叠加起来往往是全局灾难。

误区高优任务来了，把低优任务 kill 掉，资源立刻释放，多干脆，为什么要搞那么复杂？

正解生产环境里的任务往往有状态：算到一半的模型、写了一半的中间结果，直接 kill 意味着数据丢失和高昂的重算成本。真正的抢占走「优雅终止」流程：先发信号让任务保存 checkpoint、清理资源、体面退出，再把它送回队列排队。Kubernetes 驱逐 Pod 时同样先触发终止流程，给足宽限期。

为何常见：从单机进程的视角理解抢占，以为 kill 就是全部，没考虑分布式任务的状态持久化和重启代价。

误区只要设了优先级，调度器就会公平处理，低优任务等一等总有机会跑的，不会永远轮不到。

正解优先级只决定「谁排前面」，不保证「低优的也能排上」。如果高优任务持续到达，低优任务会无限期排在队尾，这就是饿死。必须配合老化机制（等待越久优先级越高）、最小配额或队列权重，低优任务才真正有机会执行。

为何常见：把「优先级」误当成「公平性保证」，实际上它只是排序规则，排不上队的任务再多优先级也只能干瞪眼。

误区监控面板上抢占次数很高，说明调度器在积极保护高优任务，系统状态应该很健康吧？

正解抢占率高往往是预警信号，而不是功劳簿。它说明资源长期不足、优先级配置失衡，系统把大量算力耗在「抢占—重调度—再抢占」的循环里，有效吞吐反而下降。正确做法是设置抢占速率上限，并通过冷却窗口和软抢占降低频率，同时关注任务实际完成时间而非抢占动作次数。

为何常见：混淆了「动作」与「结果」。抢占只是手段，让关键任务按时完成才是目的，手段本身不值得庆祝。

面试题

Q1. 调度器中任务「优先级」的核心作用是？

单选题 · easy

  • A.决定任务在队列中的先后调度顺序← 正确答案
  • B.决定任务占用 CPU 主频的高低
  • C.决定任务可用内存容量的大小
  • D.决定任务允许运行的时间上限

答案：A。优先级就像急诊室的腕带，只决定排队次序——谁先上手术台，不决定手术台本身的质量。CPU 主频、内存大小、运行时长都跟优先级无关，它们由资源规格和配额决定。

Q2. 抢占（Preemption）最直接的触发场景是？

单选题 · easy

  • A.低优任务运行太慢导致任务超时
  • B.高优任务到达但集群没有空闲资源← 正确答案
  • C.节点磁盘空间即将被数据写满
  • D.两个任务之间发生了数据冲突

答案：B。抢占的本质是「没床位了，危急病人又来了」。高优任务到达时发现节点资源放不下，才会考虑把低优任务请出去。运行超时、磁盘写满、数据冲突都不是抢占的典型触发条件。

Q3. Kubernetes 中 PriorityClass 的 priority 值范围是？

单选题 · mid

  • A.1 至 100 的整数区间
  • B.0 至 255 的整数区间
  • C.0 至 10 亿的整数区间← 正确答案
  • D.0.0 至 1.0 的浮点区间

答案：C。Kubernetes 规定优先级取值范围是 0 到 10 亿（1000000000），越靠近上限越相当于「系统级抢救」。这个上限刻意留得很大，让管理员有充足的分级空间，避免所有人挤在同一档造成排序失效。

Q4. 下列哪些情况应当触发抢占机制？

多选题 · mid

  • A.高优任务在现有节点上放不下← 正确答案
  • B.存在可回收的低优任务资源← 正确答案
  • C.集群内所有任务都在排队等待
  • D.低优任务运行时间超过一小时

答案：AB。触发抢占需要「放不下」和「有可回收资源」两个必要条件同时成立，就像腾床既要新病人危急，又要病房里有可转移的病人。全员排队说明没有资源可回收，运行时长超过一小时也未必代表资源可被剥夺。

Q5. 调度器「老化」（Aging）机制的主要作用是？

单选题 · mid

  • A.减少系统上下文切换的开销
  • B.降低集群资源碎片化的程度
  • C.加快高优任务执行的速度
  • D.防止低优任务长期得不到执行← 正确答案

答案：D。老化让等待时间转化为优先级加成，等待越久有效优先级越高，相当于护士定期给候诊病人更换更高级的腕带。它对抗的是饿死问题，与上下文切换、资源碎片化、高优任务加速都无关。

Q6. 下列哪些属于抢占风暴的有效防护手段？

多选题 · mid

  • A.限制单轮抢占的任务数量← 正确答案
  • B.设置抢占冷却时间窗口← 正确答案
  • C.优先采用软性抢占协议← 正确答案
  • D.把所有任务调成最高优先级

答案：ABC。限流、冷却、软抢占是防踩踏三件套：限制数量避免一拥而上，冷却窗口给系统喘息时间，软抢占让低优任务自愿让出。把所有任务调成最高优先级只会加剧风暴，是典型的优先级通胀。

Q7. 抢占受害者选择时，代价函数更偏向挑选？

单选题 · hard

  • A.优先级高且占用资源多的任务
  • B.优先级低且恢复代价小的任务← 正确答案
  • C.运行时间最长的大型批处理任务
  • D.内存占用最少的小型短任务

答案：B。代价函数把「规模」和「优先级差」乘在一起。优先级低说明它不重要，恢复代价小说明搬走它不痛。运行时间最长的大任务往往有大量中间状态，强行抢占反而代价高昂。

Q8. PriorityClass 配置 preemptionPolicy: Never 时表示？

单选题 · mid

  • A.该类任务永远不会被其他任务抢占
  • B.该优先级类永远不被调度器派发
  • C.该类任务永远不去抢占低优任务← 正确答案
  • D.低优任务永远不被调度器选中

答案：C。preemptionPolicy: Never 管的是「这类任务会不会主动抢别人」，相当于制度规定这类腕带的病人绝不插队。它不保证自己不被更高优任务抢，也不影响调度器是否派发它。

Q9. 在线离线混部场景中，保障在线任务 SLA 的手段有？

多选题 · hard

  • A.为在线任务设置更高的优先级← 正确答案
  • B.抢占离线任务来回收节点资源← 正确答案
  • C.对在线任务做延迟敏感调度← 正确答案
  • D.禁止任何任务使用抢占机制

答案：ABC。混部保障靠三管齐下：在线任务高优先级保证排队靠前，必要时抢占离线资源保证物理可用，延迟敏感调度保证放到好节点。完全禁止抢占等于让 ICU 和普通门诊抢床位，在线任务 SLA 反而无法保障。

Q10. 抢占风暴在系统层面本质上表现为？

单选题 · extreme

  • A.任务反复被抢的活锁式抖动← 正确答案
  • B.多个任务互相等待的死锁
  • C.节点内存泄漏导致的宕机
  • D.分布式事务的数据不一致

答案：A。抢占风暴是「任务被抢走—重新排队—又被抢走」的循环，资源全耗在抢占和重调度上，任务却始终无法完成，这是典型的活锁式抖动。死锁是互相等待，内存泄漏是资源耗尽，数据不一致是共识问题——都不是抢占风暴的本质。