3. 调度架构：四种调度器的架构对比
调度架构这东西，说白了就是「谁来决策任务去哪儿」。我在不同公司见过四种主流方案，各有各的脾气。今天咱们就掰开揉碎聊聊——集中式、两级、共享状态、分布式，这四种调度器到底怎么选。
3.1 集中式调度器：简单但扛不住
集中式调度器，就是「一个大脑管所有」。所有任务都发给一个中心节点，它统一做决策。
核心特征：
- 一个调度器实例，全局唯一
- 掌握所有节点状态
- 任务排队，逐个分配
我最早做 Hadoop 时，JobTracker 就是典型。嗯，那时候集群小，几十台机器，跑得挺欢。但后来规模上到几百台，问题就来了——调度器成了瓶颈，任务排队越来越长。
避坑指南：我曾经在 500 节点集群上跑 JobTracker，调度延迟从 50ms 飙升到 2s。原因很简单——状态同步太频繁，锁竞争严重。后来我们不得不拆集群。
集中式的优点很明显：实现简单，全局最优。但缺点也致命：单点故障、扩展性差。适合中小规模集群（<200 节点）。
3.2 两级调度器：分工协作
两级调度器把决策拆成两层。第一层做资源分配，第二层做任务调度。最典型的例子就是 Hadoop YARN。
YARN 的 ResourceManager 管资源，ApplicationMaster 管任务。ResourceManager 把容器分配给各个应用，ApplicationMaster 再决定容器里跑什么任务。
// 两级调度伪代码
// 第一级：资源分配
ResourceManager.allocate(app, request) {
available = getClusterResources()
allocated = fairSchedule(app, request, available)
return allocated
}
// 第二级：任务调度
ApplicationMaster.schedule(tasks, containers) {
for task in tasks {
container = selectBestContainer(task, containers)
launchTask(task, container)
}
}
我个人习惯用两级调度器做多租户场景。为什么？因为第一级可以保证租户间的公平性，第二级又给了每个应用自主调度的空间。
经验之谈：我在做离线计算平台时，用 YARN 管理 3000 节点集群。两级调度让不同业务线互不干扰——广告部门跑 MR，推荐部门跑 Spark，资源分配清晰得很。
两级调度器的优势是扩展性好，支持多框架。但缺点是调度延迟比集中式高，因为多了层交互。
3.3 共享状态调度器：无主但有共识
共享状态调度器，说白了就是「多个调度器共享一份状态」。每个调度器都能看到全局资源视图，自己做决策。
Google 的 Omega 系统就是这种架构。它用乐观并发控制（OCC）解决冲突——多个调度器同时写状态，冲突了就回滚重试。
| 特性 | 集中式 | 两级 | 共享状态 |
|---|---|---|---|
| 决策节点数 | 1 | 多（两层） | 多（对等） |
| 状态存储 | 调度器本地 | RM 集中 + AM 本地 | 共享存储（如 ZooKeeper） |
| 冲突处理 | 无冲突 | 层级隔离 | 乐观并发控制 |
| 典型代表 | Hadoop JobTracker | YARN | Omega |
你想想看，共享状态调度器最大的好处是什么？调度器可以水平扩展，加机器就能提升吞吐。但代价是状态一致性维护复杂，冲突多了性能下降。
注意：我曾经在 Omega 风格的系统上踩过坑——冲突率超过 10% 时，重试开销让调度吞吐直接腰斩。后来我们加了预分区策略，把冲突降到 1% 以下才稳住。
3.4 分布式调度器：各管一摊
分布式调度器，每个节点自己管自己。没有中心节点，没有共享状态。任务直接发给目标节点，节点自己决定接不接。
这种架构在超大规模集群（万节点以上）很常见。比如 Google 的 Borg 演进到 Kubernetes 后，调度器就是分布式的——每个 Node 上的 kubelet 自己管理 Pod。
// 分布式调度简化模型
// 每个节点独立决策
NodeScheduler.receive(task) {
if (hasResource(task)) {
accept(task)
updateLocalState()
} else {
reject(task)
}
}
分布式调度器的优势是扩展性极强，没有单点瓶颈。但缺点也很明显——全局最优很难保证，任务可能被多个节点拒绝，导致调度失败。
核心对比总结：
- 集中式：简单，适合小集群
- 两级：灵活，适合多租户
- 共享状态：高吞吐，适合中等规模
- 分布式：超大规模，但牺牲全局最优
3.5 架构对比图
下面这张 SVG 图，把四种架构的核心逻辑画出来了。我建议你多看几遍，理解「谁决策、谁存状态、谁执行」这三个维度。
3.6 怎么选？我的建议
说实话，没有完美的调度架构。我见过不少团队盲目追求「分布式」，结果复杂度上去了，收益却没多少。
选型建议：
- 集群 < 200 节点：集中式就够了，别折腾
- 多租户、多框架：两级调度是首选
- 中等规模，高吞吐：共享状态调度器值得一试
- 万节点以上：分布式调度器是唯一选择
嗯，我记得有一次帮一个创业团队做架构评审。他们 50 台机器，非要上分布式调度器。我说你这不是杀鸡用牛刀吗？后来换成集中式，开发周期缩短了 3 周，跑得稳稳的。
所以，别被「分布式」三个字唬住。合适的才是最好的。