mesos 集群架构
mesos技术架构简图
以下内容参考了别的内容：
四个组件组成，分别是Mesos-master，mesos-slave，framework和executor
master主要负责管理各个framework和slave，并将slave上的资源分配给各个framework，
slave进程则负责运行计算框架的计算任务，向master汇报集群节点的资源和计算框架的任务运行状态。
framework和节点主要信息都存在zookeeper中
Framework：计算框架，如：Hadoop，Spark,marathon等，通过MesosSchedulerDiver接入Mesos
Executor：执行器，安装到mesos-slave上，用于启动计算框架中的task。
Scheduler：做资源的调度，这里master和框架都有调度器，也就是双层调度
Master scheduler :整个集群的资源管理和调度
FrameworkScheduler:单个应用程序的管理和资源二次调度，基本操作均包括注册、资源申请/获取、资源分配（给内部的任务）等
第一层调度：调度器将master统计的这部分资源，发送给应用程序框架，供应用程序框架进行选择，框架需要资源时，就会给master 发送有关资源申请(相当于接受master资源邀约)的信息，一旦master收到了来自框架的接受资源邀约或者申请的消息，就会自动更新slave资源使用情况
第二层：框架自己的调度器将申请来的资源分配给自己内部的任务。
Master主要任务：
1.管理维护框架应用程序，框架程序中记录正在运行的任务、已经完成的任务，发送给应用程序框架但还没有收到回复的resource offer、框架的已分配资源、在slave上运行的执行器信息
2.管理维护存活的slave。slave中需要记录在slave上运行的应用程序框架的执行器、在slave上运行的所有任务，属于slave上的已经发送给应用程序框架但没有收到回应的offer，slave上所有offer占用的资源，（所有分配的）已被任务和执行器使用的资源，负责slave心跳保活的process。
注：
Slave 和 framework需要向master注册，注册的主要信息存储在zookeeper中。Master的元数据信息没有持久化，而是在内存中维护，为了方便交互。
Slave持久化的数据分成五个部分，分别是slave的信息framework的信息、executor的信息、任务的信息，和任务的状态变化
调度算法：Resource Allocation
Mesos 提供两种资源分配的算法, 第一种是max-min fairness 调度算法, 另一种是严格的资源限制。默认使用后者
Mesos 提供两种删除资源的方法, 比如这个framework长时间的占用资源, 这个时候怎么办, 比如想MapReduce 这样的任务, 那么就直接杀死, 因为对MapReduce这种架构而言, 单个任务的影响是不大的. 但是对MPI这种任务就不行, 因为MPI里面任务都不独立. 所以对于想MPI这种任务, allocation module提供了guaranteed allocation 的保证. 现在Mesos的做法比较简单, 如果一个framework在它保证的资源一下, 都不杀死, 如果超过了 全部杀死
调度的局限性 ：
由于不同framework需要的资源不一样, 这种Two level 调度, 不能把多种类型打包起来, 分配资源不够合理
因为在运行各种不同类型的framework的时候, 容易把所有的资源碎片化, 导致有一些framework需要大任务运行不起来. 如果是中心化调度的话, 因为他知道所有的需要调度的请求, 因为不存在这个问题
task创建流程;
task删除
删除任务则较为简单，删除任务是由framework发起的，killTaskMessage沿着framework、master、slave、执行器这一条链路上进行传递，但在处理killTaskMessage信令时，正常情况下都不会直接删除task，而是在后续处理StatusUpdateMessage时，检测到task状态为failed、killed和finished才会真正删除task。
对于docker容器任务执行完，状态为exited，slave上不会立刻删除，而是在一定的时间后才会删除