4.1 资源管理与调度算法

4.1 资源管理与调度算法

本节摘要：基站面前排着一堆要发数据的用户，可资源就那么多——调度器就是那个"按什么规矩分菜"的人。本节把轮询、最大吞吐、比例公平三种调度算法摆在一起，看它们如何用同一份资源换不同的公平与吞吐组合，并指出比例公平为何在实战里最能打。

承接 1.4 的多址资源块与 2.4 的链路预算，本节回答"资源块怎么分给各用户"：物理层的余量在这里被换算成一条条用户的排队券。

资源这么紧，谁来决定"这口饭端给谁"

空口资源（时隙、子载波、功率）是实打实稀缺的，而基站面前总排着几十上百个都想发数据的用户。调度器就是这个"同时段分菜口"的出纳——它每隔一个调度周期，根据各用户的信道质量、队列积压、业务优先级，决定这笔资源端给谁、端多少。分得太平均，信道好人挨饿、吞吐低下；分得太偏心，边缘用户长期饿肚子。调度，本质上就是把"稀缺资源配置"这笔账，在每个瞬间都算一遍。

为什么说这是笔账？因为它要对冲三个互相打架的目标——吞吐要尽量高、用户要尽量公平、携带的业务要尽量被满足。这三个目标不可兼得，就像一桌菜要同时满足"大厨出菜快（吞吐）、人人有得吃（公平）、主客点的那道菜必须上（业务满足）"一样，只能在优先级上分个次序。你能做的，是选一套称手的"分菜规矩"——这规矩的不同，正是三种经典调度的差别所在。

落到链路预算的语境，调度并不增加物理层的总增益，它做的是把物理层好不容易攒下的那点余量，在用户间重新分配：信道好的用户被喂给更多资源，等于把账上的"富余"用到刀刃上；信道差的用户也要给个机会，等于给账上的"边缘"留着活路。这就是资源管理这层的中心思想——不算错账，只把既有的账分得聪明。

学习目标

• 各用一句话说清轮询、最大吞吐、比例公平三种调度的"分菜规矩"。
• 说出比例公平在吞吐与公平之间找到平衡的机理。
• 在具体业务形态下（视频、后台下载、语音）判断该偏心谁。

调度器是谁，管什么

空口资源（时隙、子载波、功率）是稀缺的。调度器每隔一个调度周期，根据每个用户的信道质量、队列长度、优先级别权等，决定这个周期把多少资源分给谁。它是这一层"资源账"的出纳——份量给错，要么有人挨饿、要么纵向秩序乱。

调度算法的追求大致三句话：吞吐尽量高、用户尽量公平、携带的业务尽量被满足。可这三者相互打架，于是派生出不同的取舍。

三种调度，三种性格

• 轮询：一人一勺，循环均分。最公平地"平均"，但完全不管信道好坏——信道好的浪费、信道差的硬塞，总吞吐自然垫底。
• 最大吞吐：谁信道好就把资源全给谁。吞吐冲到顶，可边缘用户永远饿着，公平性坍塌。
• 比例公平：各用户按"自己相对历史平均的比例"来打分，"近期表现差的给个补尝机会、信道又好的优先"。结果是在总吞吐不太掉的前提下，把公平稳稳拉起来——所以它是 4G/5G 事实上的主调度。

用一张对照表把取舍摆平

把三个算法各自的分菜依据、吞吐与公平朝向、典型归宿放在同一张表上，一眼能挑出各自适用的土壤。

一次"分菜"的决策演练

用一段脚本模拟三种调度在同一批用户上的吞吐与公平结算：

def schedule(mode, snrs):
    # snrs 为各用户信噪比; 简化按份数分
    if mode == "round_robin":
        alloc = [1] * len(snrs)                        # 一人一根
    elif mode == "max_throughput":
        alloc = [0] * len(snrs); alloc[snrs.index(max(snrs))] = len(snrs)  # 全给最好
    else:  # proportional_fair, 简单近似
        alloc = [1.2 if s < sum(snrs)/len(snrs) else 1.0 for s in snrs]
    return alloc

snrs = [8, 10, 14, 20, 25]
for mode in ["round_robin", "max_throughput", "proportional_fair"]:
    a = schedule(mode, snrs)
    tp = sum((s/10)*x for s, x in zip(snrs, a))
    fair = min(a)/max(a) if max(a) > 0 else 0
    print(f"{mode:>16} | 总吞吐 {tp:5.1f} | 公平度 {fair:.2f}")
​

输出的规律清晰：轮询公平度满但吞吐低，最大吞吐吞吐高但公平度趋零，比例公平则两头上翘。这也是为什么把比例公平捧成 4G/5G 的当红主调度。

把调度放回"分菜"的比喻里，你还可以看到它为什么永远做不到完美：这盘菜既是稀缺的、又是要即时派发的、还得照顾一堆口味不一样的主顾。同一个小区里，有正在看视频的用户（要持续的大块资源）、有在后台同步云盘的用户（有得用就行）、还有四处走动聊语音的用户（要低时延的快餐）。调度器每毫秒都要看着他们的信噪比、队列积压和优先级别，在"喂饱谁、饿着谁、多久喂一次"之间重新分一次。没有哪个算法能让所有人都满意，所以真正的功力不是选一个"最优算法"，而是在算法之上叠加业务特征与应急机制，让这套分菜的规则能随着每秒翻转的现场，把不同脾气的用户都伺候到各自的及格线。

还要记住，调度不是孤立存在的一张"分菜表"，它时刻在跟前面的物理层和后头的 QoS 打交道：物理层给它的信道质量有多准，直接决定它对"喂谁更划算"判断得有多对；而后面的 QoS（第 4.3 章）为不同业务标定的优先级，又反过来约束它该怎么分。一个真正能打的调度方案，从不是某一种算法的独角戏，而是"信道估计、算法取舍、业务加权"三股力量拧成一个整体的产物。所以读本节请带着"它是我整个资源分配链条里承上启下的一环"的视角，而别只停留在三种算法的名字上。

易踩的坑

常见坑：以为"调度越复杂越高级"。实际调度还要看业务形态——排队的视频可以偏心大数据块，突发语音必须低保时延快给。算法之外，业务特征与队列优先级才是最终加权的那只手。

本节要点回顾

• 调度三目标打架：高吞吐、公平、业务满足，三者互为代价。
• 轮询：纯公平、低吞吐；最大吞吐：高效率、零公平。
• 比例公平：按历史比例追补，吞吐与公平兼得，实战主调度。
• 业务加权：最终分菜还要叠加业务类型与优先级，才落到 4.3 的 QoS。