背景
我们使用Mesos也有一段时间了，目前有两个项目使用Mesos作为底层资源管理系统，各自部了一套集群。这中间对比Mesos的论文和源码实现，到底哪些功能实现了，哪些功能未实现，版本是否稳定，使用是否顺畅，有哪些坑会遇到等等这些问题，同组的同事们都遇到了不少。大致总结一下使用过程中的感受吧。
Mesos使用方式
Mesos Master在给framework分配资源的时候采用的是多资源下的最大最小公平算法，即DRF算法，对于Mesos的第一层调度来说，使用方实现的Scheduler应该实现自己的调度策略和资源分配策略，Mesos Master对所有的framework一视同仁，尽量为各个framework的资源分配做到”公平”。对于这一点，我们在使用Mesos实现Scheduler的时候，有两种使用方式。
第一种，项目Q会起一个long-running的framework，作为QMaster，负责接收业务系统发来的任务请求。这个情况下，QMaster接收整个Mesos集群的机器的所有资源，任何一种请求任务都会被调度到某台Mesos Slave上的Executor执行，完了之后把资源返还给Mesos集群，从而在QMaster处再次resourceOffer的时候再接收到。这种场景下，QMaster内部需要维护很多内容，比如不同用户请求来的任务需要队列管理，队列和队列之间的优先级、session管理、调度策略等都需要QMaster内部维护。
第二种，项目D也会起一个long-running的DMaster Framework，负责接收业务系统发来的任务请求。针对不同请求，DMaster会起新的DEngine来管理这一次任务，而DEngine本身也是一个Framework，实现了Mesos Scheduler，DEngine根据自己获得的资源，会选择Slave起Executor做任务的执行，并且这次任务的监控和执行情况由DEngine管理，所有的DEngine的生命周期、资源等是由DMaster掌控的。DMaster也需要维护DEngine的管理。
其实两种使用方式本质上是一样的，我们在使用Mesos的时候，在Mesos的第二层也实现了双层调度。只是第一种使用方式中，把我们的第二层都维护在了同一个Framework下面，把一些元数据写到了zk上，帮助容错。而第二种使用方式会产生很多Framework，但是从结构上来说比较清晰一些，比较适用于任务本身比较重的情况，相比较之下，第一种使用方式还是比较轻量级的。
Mesos优点
使用下来，感觉Mesos的轻量级使用蛮好用的。Executor和Scheduler之间的简单通信，通过frameworkMessage这样的接口传输一些消息还是比较方便的。如果Executor Lost了，Schedule能够接收到事件并尝试重启；如果Executor出异常后上报给了Scheduler，Scheduler就可以killTask掉该Executor；如果Executor正常结束，使用driver.sendStatusUpdate()更新状态，并最后显示driver.stop()关闭，可以看到Executor正常Finish完成任务。以上这些管理和调度可以依赖Mesos轻量级地实现，并且Mesos对机器资源的使用情况有监控作用，分配任务的时候增加一些自己的调度策略，负载均衡也是很好实现的。
Mesos不足
Mesos对每种Framework的分配策略限定在DRF算法，没有YARN丰富，这点其实倒也不算是不足。Mesos目前比较大的问题是一套Mesos集群只适合一种计算框架，多套计算框架在一套Mesos集群上使用，无法做到框架之间的资源隔离。对于Mesos来说，为不同业务模块Framework分配资源这件事情是不区分的，Scheduler在接收到CPU和MEM的时候，可以根据机器信息使用Scheduler的offerRescinded接口拒绝分配来的资源，理论上能做到一定的过滤，但是被拒绝掉的资源不会实时在这次资源分配中再次分配出去，而是会在下次资源分配触发的时候再分发出去，而且分配的资源的机器属性也是不能控制的。综上，Mesos没有提供多框架之间的隔离、分组能力，我们使用的时候只能给多个应用部署多套Mesos集群。
Mesos和YARN
Mesos和YARN是双层调度系统的代表。Mesos早于YARN诞生，是C实现的。两者在底层CPU的隔离上都使用了cgroup。但是对于内存资源，为了能够更灵活的控制内存使用量，YARN采用了进程监控的方案控制内存。
在资源分配模型方面，在YARN中，用户以队列的形式组织，每个用户可属于一个或多个队列，且只能向这些队列中提交application。每个队列被划分了一定比例的资源。而Mesos的资源分配模型应该是很简单的，对于CPU和内存也没有YARN那些的虚拟使用方式，往往资源也会白白浪费掉，而且不太好预估。
在资源保证机制方面，YARN采用的是增量资源分配机制，优先为应用程序预留一个节点上的资源，优点是不会发生饿死现象，但有一定的浪费。Mesos使用的是All or nothing的模式，可能会造成作业饿死（大资源的作业长时间无法得到满足）。
资源调度系统发展
Google新的Omega应该是在开发中，论文参见。。。，Mesos的作者Andy也在参与Omega的开发。从Hadoop v1的JobTracker，到Mesos和YARN，再到Omega，资源管理系统经历了三代的演变。Omega的简单介绍可以参考董的解析Google集群资源管理系统Omega，以下我从他的文章里摘抄几点：
中央式调度器：
资源的调度和作业的管理功能全部放到一个进程中完成，典型的代表是Hadoop JobTracker。这种设计方式的缺点是扩展性差：首先，集群规模受限，其次，新的调度策略难以融入现有代码中，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央式调度器中是一项很难的工作。
双层调度器：
各个框架调度器并不知道整个集群资源使用情况，只是被动的接收资源； Master仅将可用的资源推送给各个框架，而框架自己选择使用还是拒绝这些资源；一旦框架（比如Hadoop JobTracker）接收到新资源后，再进一步将资源分配给其内部的各个应用程序（各个MapReduce作业），进而实现双层调度。
双层调度器有两个缺点，其一，各个框架无法知道整个集群的实时资源使用情况；其二，采用悲观锁，并发粒度小。
共享状态调度器：
为了克服双层调度器的以上两个缺点，Google开发了下一代资源管理系统Omega，Omega是一种基于共享状态的调度器，该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据（状态）和针对这些数据的验证代码，而这里的“共享数据”实际上就是整个集群的实时资源使用信息。一旦引入共享数据后，共享数据的并发访问方式就成为该系统设计的核心，而Omega则采用了传统数据库中基于多版本的并发访问控制方式（也称为“乐观锁”, MVCC, Multi-Version Concurrency Control），这大大提升了Omega的并发性。
参考
全文完 :)