1. 调度概述：什么是集群调度、调度系统的核心目标、调度策略的分类

大家好，我是你们的讲师。今天咱们聊聊集群调度。说实话，这个概念听起来挺唬人的，但说白了，它解决的就是一个核心问题：这么多机器，任务该扔给谁跑？

我刚开始接触分布式系统时，觉得调度不就是个“分配任务”嘛，有啥难的？后来被线上故障狠狠教育了一顿，才明白这里面的门道有多深。嗯，咱们今天就把这块地基打牢。

想象一下，你手头有100台服务器，同时有1000个任务要跑。谁先跑？谁后跑？跑在哪台机器上？机器资源够不够？这就是调度系统要干的事。

集群调度，本质上是一个匹配问题：把任务和资源做最优匹配。我习惯把它拆成三步：

核心要点：调度不是一次性的，它是持续进行的。任务跑着跑着可能挂了，机器可能宕了，新任务不断涌入——调度器得像个永动机一样，不停地做决策。

我在项目中遇到过一种情况：调度器只做“初次分配”，任务上去后就不管了。结果某台机器内存泄漏，任务全挤在一起，其他机器闲着。这就是典型的“调度只管生不管养”，后来我们加了重调度机制才解决。

调度系统好不好，看三个指标：吞吐量、延迟、资源利用率。这三个指标就像“不可能三角”，你很难同时做到极致。

指标	定义	我踩过的坑
吞吐量	单位时间内能调度多少个任务	曾经为了追求吞吐量，把调度队列搞成无锁的，结果数据一致性崩了
延迟	从任务提交到开始执行的时间	有个用户反馈任务提交后等了30秒才启动，查了半天是调度器在等全局锁
资源利用率	集群资源被有效使用的比例	为了省资源，把任务都往几台机器上塞，结果那几台机器CPU打满，其他机器空转

你想想看，这三个目标其实是互相打架的：

我的建议：别想着三个指标都做到99分。先明确你的业务场景——是离线批处理（重吞吐量）还是在线服务（重延迟）？然后针对性地优化。我一般会定一个“底线指标”，比如延迟不能超过500ms，在这个前提下尽量优化吞吐量和利用率。

调度策略五花八门，但万变不离其宗。我个人习惯把它们分成三大类：

静态调度：任务提交前就把调度方案定死。比如Hadoop的MapReduce，任务启动前就规划好每个Map跑在哪。好处是简单，坏处是——集群状态一变，方案就废了。

动态调度：运行时根据集群状态实时调整。比如Kubernetes的调度器，每来一个Pod就重新算一次。灵活，但计算开销大。

我曾经在一个离线数仓项目里用了纯静态调度，结果某台机器磁盘坏了，任务全卡住。后来改成动态调度，虽然调度耗时多了几十毫秒，但健壮性提升了一个档次。

性能优先：怎么快怎么来，怎么省资源怎么来。典型代表是贪心调度——哪个机器剩余资源最多，就把任务扔过去。简单粗暴，但容易导致“富者愈富，穷者愈穷”。

公平优先：保证每个用户或每个任务都能分到差不多的资源。比如Dominant Resource Fairness (DRF)算法，它会看每个任务对CPU和内存的“主导资源占比”，然后尽量让大家的占比均衡。

注意：公平不等于平均。我见过一个团队把公平调度理解成“每人分一样多的CPU”，结果有的任务需要大量内存，CPU用不完；有的任务需要大量CPU，内存用不完。两边都浪费。DRF的精髓是看“谁最缺什么”，而不是“谁要什么就给什么”。

集中式调度：一个调度器管所有节点。比如Google的Borg。好处是全局最优，坏处是单点瓶颈——集群大了，调度器自己就成了瓶颈。

分布式调度：多个调度器各管一摊。比如Apache Mesos。好处是可扩展，坏处是——调度器之间怎么协调？资源怎么分？搞不好就出现“资源碎片”。

嗯，这里要注意：分布式调度不是简单的“分而治之”。我见过一个案例，两个调度器同时认为某台机器有空闲资源，同时把任务调度上去，结果机器直接OOM。后来加了资源预留机制才解决。

说了这么多，咱们用一张图把本章的核心逻辑串起来。这张图是我自己画的，每次给新人讲调度时都会拿出来用。

这张图把咱们今天讲的内容全串起来了。你看，从“任务与资源的匹配”出发，到三个核心目标，再到三大分类维度。每个维度下面都有具体的策略选择。

避坑指南：我曾经犯过一个错误——上来就选了一个看起来很牛的调度策略（比如DRF），结果发现业务场景根本不需要公平性，反而因为计算复杂拖慢了调度速度。后来我学乖了：先搞清楚你的业务到底要什么，再选策略。别为了用技术而用技术。

好了，这一章就到这里。调度是个大话题，咱们后面会一个一个策略深入讲。记住今天这三个核心目标、三种分类方式，后面你会反复用到它们。