网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

当你解决了“权限”和“限流”之后，很容易产生一种错觉：

系统已经安全了
不会乱执行了

但很快你会遇到另一个问题：

该执行的任务，被延迟
不重要的任务，占满资源
关键任务，反而卡住

一个真实场景

Agent 系统同时收到：

A：用户实时请求（高优先级）
B：后台数据整理（低优先级）
C：批量任务执行（中优先级）

结果：
B 和 C 占满资源
A 被延迟 3 秒
用户体验崩溃

核心问题

当资源有限时，AI 系统应该“先做什么”？

本质一句话

资源调度，不是“如何执行”，而是“谁先执行”。

一、问题本质：资源永远是不够的

无论是端侧还是云端：

CPU 有限
内存有限
并发有限
API 配额有限

但任务是：

持续增加
动态变化
优先级不同

核心矛盾

所有任务都想“立刻执行”，但系统做不到。

二、错误方式：先来先服务

最常见的调度方式：

谁先来 → 谁先执行

看起来公平：

简单
可预测
易实现

实际问题：

低价值任务阻塞高价值任务
突发请求无法优先处理
系统响应变慢

本质

“公平”，不等于“合理”。

三、核心设计：优先级驱动

正确方式是：

让“重要的任务先执行”。

基本模型

高优先级 → 先执行
低优先级 → 后执行 / 延迟

示例

queue.sort((a, b) => b.priority - a.priority);

本质

调度系统，本质是“价值排序系统”。

四、关键设计一：优先级分级模型

必须定义清晰的优先级层级：

示例

P0：实时用户请求（最高）
P1：关键业务逻辑
P2：普通任务
P3：后台任务（最低）

特点

层级清晰
可控
易调优

本质

没有分级，就没有调度。

五、关键设计二：动态优先级

优先级不能是“固定的”。

示例

等待时间越长 → 优先级越高
用户交互任务 → 自动提升
系统负载高 → 降低低优先级任务

示例代码

task.priority += waitTime * factor;

本质

优先级必须“会变化”。

六、关键设计三：资源隔离

不能让所有任务“抢同一池资源”。

必须拆分：

实时任务池
后台任务池
批处理任务池

示例

if (task.type === "realtime") {
  useRealtimePool();
}

本质

不同任务，必须用不同资源。

七、关键设计四：并发控制

即使允许执行，也必须限制：

同时执行多少任务

示例

if (runningTasks > maxConcurrency) {
  queue.push(task);
}

本质

系统不能“同时做太多事”。

八、关键设计五：抢占机制

高优先级任务，必须可以“插队”。

示例

低优先级任务正在执行
高优先级任务到来 → 中断低优先级

示例代码

if (newTask.priority > current.priority) {
  preempt(current);
}

本质

关键任务，必须“立即响应”。

九、关键设计六：饥饿保护

优先级系统有一个副作用：

低优先级任务永远得不到执行

解决方式

等待时间越长 → 优先级提升

示例

if (task.waitTime > threshold) {
  task.priority = elevate(task.priority);
}

本质

不能让任务“永远排队”。

十、关键设计七：任务拆分

大任务会“阻塞系统”。

示例

一个任务执行 10 秒 → 阻塞所有资源

解决

拆成多个小任务
分片执行

示例

for (chunk of task) {
  execute(chunk);
}

本质

小任务，更容易调度。

十一、关键设计八：延迟与队列设计

调度系统，本质就是“队列系统”。

常见队列策略

优先级队列（Priority Queue）
多队列（Multi-Queue）
时间轮（Time Wheel）

示例

priorityQueue.push(task);

本质

调度 = 队列管理。

十二、关键设计九：与限流系统结合

调度不能独立存在。

必须结合

限流（Rate Limit）
配额（Quota）
权限系统

示例

if (!rateLimit.allow(task)) {
  delay(task);
}

本质

调度决定“顺序”，限流决定“规模”。

十三、关键设计十：可观测性与调优

你必须知道：

任务排队时间
执行时间
被延迟次数
优先级分布

示例

{
  "task": "send_email",
  "wait_time": 120ms,
  "priority": "P1"
}

本质

调度系统必须“可调优”。

十四、实战架构：资源调度系统

完整架构如下：

任务提交（Task）
↓
优先级计算（Priority）
↓
队列系统（Queue）
↓
调度器（Scheduler）
↓
并发控制（Concurrency）
↓
执行（Execution）
↓
监控（Monitoring）

核心特征

优先级驱动
动态调整
资源隔离
可观测可调优

总结

资源调度的本质，不是：

如何执行任务

而是：

在资源有限的情况下，做出“最合理的选择”。

我们可以用一句话总结：

权限 → 决定能不能做
限流 → 决定做多少
调度 → 决定先做谁