今天阅读了一个berkeley学生Andrew Konwinski的有关集群资源调度的技术报告，其中对于目前现有集群调度技术的分类，我觉得说的很好，另外，它还介绍了一种模拟实验的蒙特卡洛方法，现在做一个摘要与总结，报告链接：http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-273.html
里面还说了一个比较重要的特点是，悲观锁和乐观锁：
The pessimistic concurrency control approach is to have the database server lock the row on User A's behalf, so User B has to wait until User A has finished its work before proceeded. We effectively solve the problem by not allowing two users to work on the same piece of data at the same time. It just prevents the conflict.
The optimistic concurrency control approach doesn't actually lock anything - instead, it asks User A to remember what the row looked like when he first saw it, and when it's time to update it, the user asks the database to go ahead only if the row still looks like he remembers it. It doesn't prevent a possible conflict, but it can detect it before any damage is done and fail safely.
动机
目前，大型web服务主要运行在普通服务器集群上面。这个主要是由于（1）更加廉价的计算资源和（2）通过公有云和私有云接口访问这些资源的方便性。这个现象导致了多种编程模型的出现，比如为处理留作业的MapReduce，Dryad，MapReduce Online以及为图计算开发的Pregel和很多其他的系统。
新的计算框架会持续的出现，没有一个单独的框架能满足所有的需求。这个就导致了我们希望在同一个集群中同时运行不同的计算模型，为某个应用选择最好的框架。这个需求就需要一个支持多编程模型的集群资源管理系统，这个系统需要满足一下要求：
可伸缩性：对于节点的数目和能处理的作业到达速率的增长，系统有很好的伸缩性。
灵活性：支持高度异构的混合作业同时运行在普通的集群中。
可用性和可维护性：在集群中方便地兼容新的作业。部署/升级编程框架简答。
错误隔离：隔离不同种作业的错误，防止错误的级联。
资源利用率：提高整个集群资源的利用率。
集群负载的分类
为了达到以上的目的和设计出满足要求的系统，我们需要对目前集群中的作业进行一个分类：
服务任务和终止任务(Service Jobs vs Terminating Jobs)
服务任务是一直运行的程序，比如web服务器和关系数据库。
终止任务类似于批处理程序，它们根据一定的输入进行一定的处理，然后退出。
目前的资源管理系统一般只会处理其中的一种任务。
任务选择率(Task pickiness)
任务可以选择为其提供服务的资源的要求和偏好。
作业弹性(Job elasticity)
可能根据作业不同时间的负载动态的伸缩资源。
任务和作业的持续时间(Job and task duraton)
终止作业可能有不同的持续时间。
任务调度时间敏感性
有的任务会有响应时间的要求，这回影响到用户体验。
集群调度的分类
目前所有的集群调度技术可以以下面的方式分类：
单代理（Monolithic）：
集群中仅仅只有一个调度器，它串行的做出所有的调度决策。
这个是目前大多数集群管理系统，比如Hadoop和Torque系统使用的架构，优势在于简单。但是有很多先天的劣势：
1单调度策略，在伸缩性，灵活性和拓展性方面均不好。
对于混合的作业流，这个方式并不能很好适应。批处理式的作业比较适合用非抢占的公平调度而延迟敏感的作业需要使 用优先级抢占策略，这样的架构不能满足这些要求。
2单点故障。
3负载瓶颈。
4Head of line(HOL) blocking饿死现象。
多代理架构
状态分区的调度（Partitioned State Scheduling)
静态分区
优势：没有单点故障，等待调度延迟小，更好的错误隔离。
劣势：劣势主要集中在静态的分区上，比如1）一个超过一个分区的作业就不能运行。2）一个分区可能对于一个小作业来说太大了。3）碎片问题
动态分区
优势：如静态分区，并加上其的劣势。
劣势：需要维护一个元数据服务器，这个元数据服务器需要上锁，可能会有性能开销。
以上的两个部分分区方案就类似于数据库中控制同步的方式中的悲观并发控制。这种方式要求提前就把调度管理域给划分开来。
复制状态的调度（Replicated State Scheduling）
这个调度策略允许调度管理域重叠，比较像数据库中同步控制中的乐观并发控制。
这个架构目前是最灵活的，但是需要更复杂的处理逻辑以及同步的控制。