说起任务调度，管理后台+调度中心+执行节点这种中心化调度往往是首先被想到的，它是最先出现，最直观的方式。但是随着技术发展，近几年出现的调度框架基本都是去中心化的，中心化与去中心化调度有什么区别呢？以下从调度框架的演进过程，对各种方式的调度进行对比。
1. 中心化调度 Monolithic scheduler
2. 两级调度 Two-Level Scheduling
3. 共享状态调度 Shared-State Scheduling
4. 全分布式 Distributed Scheduling
5. 混合调度 Hybrid Scheduling
6. revolver 的设计其中灰色的方块对应一个机器，不同颜色的圆圈代表不同的任务，有“S”标志的圆角矩形代表调度器（这个图简化了一些，实际上，每台机器运行多个任务，许多调度器适合多个资源纬度的任务，而不是简单的slots），箭头代表调度器决定的作业放置位置，三种颜色代表不同的工作负载。
01. 中心化调度
Monolithic scheduler，单一的调度进程在一台机器上运行（例如Hadoop V1的JobTracker、Kubernetes的kube-scheduler），调度器负责将任务指派给集群内的机器。在中心化调度框架下，所有的工作负载都是由一个调度器来处理，所有的作业都通过相同的调度逻辑来处理。XXL-JOB 是中心化调度里最简单的调度框架。
上图就是 XXL-JOB 的模式，调度中心部署了三台机器，为了保证调度的准确性和安全性，只允许leader执行调度工作，此时leader就是忙碌的，follower几乎无事可做，只作为灾备，leader的处理能力就成了整个任务系统的上限。
XXL-JOB的选主通过数据库锁实现，
select * from xxl_job_lock where lock_name = 'schedule_lock' for update;加锁成功的就是主节点，整个任务调度，一直支持这把数据库锁。
XXL-JOB的优点：设计简单、稳定、比较容易控制，容易上手，接入容易。
缺点：
- 吞吐量有限。leader 从 DB 中扫描未来 5 秒内需要执行的任务，然后在本地调度执行。假如有1分钟一次、2分钟一次、5分钟一次.......，大大小小的任务50个，大概率会有任务在同一秒执行，假如其中有几个任务耗时>1分钟，多少核的CPU，线程池核心多大能保证不延迟？想想就知道，如果是腾讯那个用户量级，每天有那么多推送任务，用这种任务调度是绝对不可能完成的。
- 依赖执行节点必须提供API供调用，适合少量且固定的任务。一个不提供接口能力的服务怎么调度？每增加一种任务就增加一个API？
- 最少要三台调度节点+三台执行节点以达到高可用
- 集群不能提高调度中心的吞吐量
02. 两级调度
Two-Level Scheduling，两级调度框架通过将资源调度和作业调度分开，很明显Yarn就是这种，ElasticJob 应该也是这种。
在宣称去中心化调度框架中，最出名的调度框架之一就是elasticJob。在 elasticJob 加入 apache 之后，比 XXL-JOB 高出几个等级，现在叫 apache shardingsphere-elasticjob，在es-job 里没有调度中心，取而代之的是注册中心（分片中心），各任务节点自治。Scheduler 是各作业节点，resource manager 是分片中心。
ElasticJob 是一个分布式调度解决方案，由 2 个相互独立的子项目 ElasticJob-Lite 和 ElasticJob-Cloud 组成。
ElasticJob-Lite 定位为轻量级无中心化解决方案，使用jar的形式提供分布式任务的协调服务；
ElasticJob-Cloud 使用 Mesos 的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。ElasticJob的基本逻辑是在执行任务时，各节点都去ZK注册节点，注册成功的就取得了调度权，流程如下：
03. 共享状态调度
Shared-State Scheduling，这种更复杂的一种设计理念，实际工作中还没遇到。共享状态调度通过半分布式的模式来解决这个问题，在这种模式下应用层的每个调度器都拥有一份集群状态的副本，并且调度器会独立地对集群状态副本进行更新，一旦本地的状态副本产生了变化，调度器会发布一个事务去更新整个集群的状态，有时候因另外一个调度器同时发布了一个冲突的事务时，事务更新有可能失败。在共享状态调度的框架中，最著名的是Google的Omega、Microsoft的Apollo，Apollo跟其他两个调度框架不同之处在于其共享状态是只读的，调度事务是直接提交到集群中的机器上，机器自己会检查冲突，来决定是接受还是拒绝这个变化，这使得Apollo即使在共享状态暂时不可用的情况下也可以执行。
04. 全分布式架构
Distributed Scheduling，全分布式架构更加去中心化，这种没有见过。调度器之间根本没有任何的协调，并且使用很多各自独立的调度器来处理不同的负载，如图1d所示。每个调度器都作用在自己本地（部分或者经常过时的）集群状态信息。在分布式调度架构下，作业可以提交给任意的调度器，并且每个调度器可以将作业发送到集群中任何的节点上执行。与两级调度调度框架不同的是，每个调度器并没有负责的分区，相反的是，全局调度和资源划分都是服从统计和随机分布的，与共享状态调度架构有些相似，但是没有中央控制。
真正意义的全分布式调度是从Sparrow论文开始的，Sparrow论文假设集群上任务周期都会变的越来越短，作业会变得越来越多，这意味着调度器必须支持更高的吞吐量，而单一的调度器并不能支持如此高的吞吐量（假设每秒有上百万个任务），因此Sparrow将这些负载分散到很多调度器上。它具有以下特点：
- 分布式调度器是基于简单的“slot”概念，将每台机器分成n个标准的“slot”，并放置n个并行作业，这简化了任务的资源需求不统一的事实。
- 它使用了拥有简单服务规则的worker-side队列（例如，Sparrow中的FIFO规则），这样限制了调度器的灵活性，因为调度器只能选择将作业放置在哪台设备的队列上。
- 分布式调度器很难执行全局不变量（例如，公平策略和严格的优先级优先），因为它没有中央控制。
- 因为分布式调度器是基于最少知识做出快速决策而设计，它无法支持或承担复杂或特定应用的调度策略，例如，避免任务之间的相互干扰对分布式调度来说很困难。
05. 混合调度
Hybrid Scheduling，混合式调度架构是最近（学术界提出的）提出的解决方法，它的出现是为了解决全分布式架构的缺点，它结合了中心化调度和共享状态的设计。这种方式例如Tarcil、Mercury和Hawk一般有两条调度路径，一条是为部分负载设计的分布式调度（例如非常短的作业或者低优先级的批作业），另外一条是中心式作业调度来处理剩下的负载，混合调度器的每个组成部分的行为与上述描述的部分架构相同。实际上，据我所知，目前还没有真正的混合调度器应用于生产环节当中。
06. revolver 是如何设计的
revolver 以去中心化为基本设计。第一版基础设计在《自研分布式任务调度框架 revolver 基本设计》有简单介绍，去中心化的基本思路如下：
- 任务注册之后，没有指定调度执行资源，但是指定了执行的业务模块。
- Leader 节点作为分片中心，负责将没有认领的任务，合理的分配给执行节点，这里需要知道各节点情况。
- 分片完成之后，各节点只调度属于自己的任务，避免争抢，节省资源。
- 节点停服之后，依靠注册中心通知节点，进行故障转移。
- 任务执行之后会写状态。
- 任务状态变更，执行节点验证状态
去掉调度中心、增加分片中心，节点自治，即使节点挂掉，也只是影响部分任务，故障转移之后会继续执行。