Mesos架构如下
这个图比较的著名了，也有很多文章介绍这个图，详情可以看文章http://mesos.apache.org/documentation/latest/architecture/，这里不做过多的介绍。
从图中可以看到，Mesos有Framework(Framework里面有Scheduler), Master(Master里面有allocator), Agent, Executor, Task几部分组成。这里面有两层的Scheduler，一层在Master里面，allocator会将资源公平的分给每一个Framework，二层在Framework里面，Framework的scheduler将资源按规则分配给Task。
Mesos的这几个角色在一个任务运行的生命周期中，相互关系如下：
Agent会将资源汇报给Master，Master会根据allocator的策略将资源offer给framework的scheduler。Scheduler 可以accept这个资源，运行一个Task，Master将Task交给Agent，Agent交给Executor去真正的运行这个Task。
这个图相对比较的简略，真正详细的过程比这个复杂很多，大家可以参考这篇博客http://www.cnblogs.com/popsuper1982/p/5926724.html，在代码级别分析了整个任务运行的过程，还画了一个泳道图http://images2015.cnblogs.com/blog/635909/201608/635909-20160806163718778-1628977219.png。
要研究Mesos，熟悉整个过程非常重要，这样一个任务运行出现问题的时候，才能比较好的定位问题在哪里，如果解决。Mesos将一个简单的任务的运行过程，分成如此多的层次，如此多的角色来做，是为了双层调度和灵活配置，这是一个内核应该做的事情。
我们如何干预一个Task的运行过程呢？
第一、写一个Framework
如果你想完全自己控制Task的运行，而非让Marathon来运行并保持一个无状态的Task长运行，就需要自己写一个Framework，在你的Framework里面，三个Task之间的关系你可以自己定义，而非像Marathon一样，Task * 3，3个任务不分彼此，你的Framework可以控制这三个Task一主两备，可以控制三个Task的启动顺序，可以将一个先启动的Task的IP，位置等通过环境变量告知另外两个Task。
写一个Framework需要写一个Scheduler，实现一些接口，如文档http://mesos.apache.org/documentation/latest/app-framework-development-guide/中所述。
然后使用使用MesosSchedulerDriver来运行这个Scheduler。
其实Mesos这些模块之间的通信都是通过Protocol Buffer定义消息来交互的，然而如果让Framework的开发人员还要学会如何使用Protocol Buffer消息和Mesos Master通信，是很痛苦的事情，所以MesosSchedulerDriver帮助你做了这个事情，你只需要实现Scheduler定义的接口就可以了，不需要了解这些接口是谁调用的，调用了接口之后，消息如何传给Mesos Master。
所有的接口里面，最重要的是resourceOffers函数，根据得到的offers(每个slave都有多少资源)，创建一系列tasks，然后调用MesosSchedulerDriver的launchTasks函数，MesosSchedulerDriver会将这些tasks封装为LaunchTasksMessage发送给Mesos Master。
第二、写一个Allocator
通过上面的描述，Mesos有两层调度，第一层就是Allocator，将资源分配给Framework。
Mesos允许用户通过自己写Module的方式，写一个so，然后启动的时候加载进去，然后在命令行里面指定使用so中的哪个Module。
当然写Allocator的不多，因为Mesos的DRF算法是Mesos的核心，如果不用这个算法，还不如不用mesos。
Mesos源码中默认的Allocator，即HierarchicalDRFAllocator的位置在$MESOS_HOME/src/master/allocator/mesos/hierarchical.hpp，而DRF中对每个Framework排序的Sorter位于$MESOS_HOME/src/master/allocator/sorter/drf/sorter.cpp，可以查看其源码了解它的工作原理。
HierarchicalDRF的基本原理
如何作出offer分配的决定是由资源分配模块Allocator实现的，该模块存在于Master之中。资源分配模块确定Framework接受offer的顺序，与此同时，确保在资源利用最大化的条件下公平地共享资源。
由于Mesos为跨数据中心调度资源并且是异构的资源需求时，资源分配相比普通调度将会更加困难。因此Mesos采用了DRF（主导资源公平算法 Dominant Resource Fairness）
Framework拥有的全部资源类型份额中占最高百分比的就是Framework的主导份额。DRF算法会使用所有已注册的Framework来计算主导份额，以确保每个Framework能接收到其主导资源的公平份额。
举个例子
考虑一个9CPU，18GBRAM的系统，拥有两个用户，其中用户A运行的任务的需求向量为{1CPU, 4GB}，用户B运行的任务的需求向量为{3CPU，1GB}，用户可以执行尽量多的任务来使用系统的资源。
在上述方案中，A的每个任务消耗总cpu的1/9和总内存的2/9，所以A的dominant resource是内存；B的每个任务消耗总cpu的1/3和总内存的1/18，所以B的dominant resource为CPU。DRF会均衡用户的dominant shares，执行3个用户A的任务，执行2个用户B的任务。三个用户A的任务总共消耗了{3CPU，12GB}，两个用户B的任务总共消耗了{6CPU，2GB}；在这个分配中，每一个用户的dominant share是相等的，用户A获得了2/3的RAM，而用户B获得了2/3的CPU。
以上的这个分配可以用如下方式计算出来：x和y分别是用户A和用户B的分配任务的数目，那么用户A消耗了{xCPU，4xGB}，用户B消耗了{3yCPU，yGB}，在图三中用户A和用户B消耗了同等dominant resource；用户A的dominant share为4x/18，用户B的dominant share为3y/9。所以DRF分配可以通过求解以下的优化问题来得到：
