[译]集群调度架构的变革 (三)

全分布式架构 将分化做的更彻底，调度器间没有任何协调，并且使用许多独立的调度器来处理进入的负载，就像图 1d里面展示的。每个调度器只与他们的本地数据，通常是集群的过期数据工作。任务可以提交给任何调度器，每个调度器又会将任务放置在集群的任何位置。不像两层调度器，调度器不对隔离负责。相反，全局调度器和资源分区是在统计了多样与随机性的负载造成的结果后做的决策 - 类似于共享状态调度器，只是没有中央控制。

最近的分布式调度器运动应该是起始于Sparrow(http://dl.acm.org/citation.cf...，虽然底层的概念（多样随机性选择）第一次出现实在1996年。Sparrow的关键前提是假设我们在集群中运行的任务会变得更短，基于一个争论(http://dl.acm.org/citation.cf...，即细粒度的任务有更更多的好处。作者假设任务会变得越来越多，意味着调度器应该支持一种更高层的吞吐量。由于一个单一的调度器可能无法保持这样的吞吐（假设每秒有100W的任务！），Sparrow将负载转移到许多的调度器上。

这很有意义：中央控制的缺乏可以变成一个很好的特性 ，它对一些负载适配的很好 - 在未来更多。 由于分布式调度器不需要互相协调，他们可以做到比高级单体，2层，或者共享状态调度器的逻辑更简单。例如：

1. 分布式调度器可以基于一个简单的“槽”概念，将每个机器划分成n个标准的槽，对应n个并行的任务。这样简化了任务需要的资源不是统一的。
2. 在worker端也使用了队列作为简单的服务逻辑（如，Sparrow的FIFO），保证调度有弹性，调度器可以仅仅选择在哪台机器上做任务的入队操作。
3. 分布式调度器很难进行一个全局调度（如：公平策略或严格的优先级控制），因为没有中央控制。
4. 由于它们都被设计为在只有很少知识时进行快速决策，分布式调度器不能支持复杂或定制应用策略。避免干涉任务，例如，用一些后门手段。

---

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流Email: [email protected]