Apache Mesos 是一个集群管理器类似于YARN，提供了有效的、跨分布式应用或框架的资源隔离和共享，可以运行 Hadoop、MPI、Hypertable、Spark。

使用场景：

假设某公司需要频繁进行大数据计算，该任务运行时需要 N 多 CPU 和内存，为了满足这个需求，我们有两种思路：

思路一）使用小型机，单机即可为任务提供足够 的资源；

思路二）分布式计算，即提供一批普通配置的机器（计算节点），也就是集群，将计算任务拆分到各机器上计算，然后汇总结果。

思路二是当前正在流行的做法，为了达到思路二的要求，我们需要建立数据中心（集群）。进一步，为了充分利用数据中心（集群）的资源（譬如为不同的任务分配不同资源，按任务优先级分配资源等），我们就需要一个工具来进行整个数据中心资源的管理、分配等， 这个工具就是 Mesos。 与 Mesos 类似的工具还有 YARN。

除此之外， Mesos 不仅为计算任务 Offer 资源， 它也支持运行长时任务（譬如 Web应用）。目前国外好多互联网公司都在使用 Mesos 来作为它们的集群管理工具，这里是一个 Powered by Mesos list：https://mesos.apache.org/documentation/latest/powered-by-mesos/

Mesos 和 Cloudera 的差别：

Mesos 的主要目标就是去帮助管理不同框架（或者应用栈）间的集群资源。例如，有一个业务需要在同一个物理集群上同时运行Hadoop，Storm及 Spark。这种情况下，现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器，它可以允许多个框架 运行在一个集群里。但是，要使用框架特定的算法或者调度策略的话就变得很难了，因为多个框架间只有一种调度算法。

例如：MPI 使用的是组调度算法，而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。

Mesos特性：

Mesos 是一个双层调度器。在第一层中，Mesos 将一定的资源提供（以容器的形式）给对应的框架。框架在第二层接收到资源后，会运行自己的调度算法来 将任务分配到 Mesos 所提供的这些资源上。和 Hadoop YARN 的这种中央调度器相比，或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说，多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是，随着新框架的诞生，比如说 Samza 最近就被 LinkedIn 开源出来了——有了 Mesos ，这些新框架可以试验性地部署到现有的集群上，和其它的框架和平共处。

MESOS典型应用场景：

1）Spark on Mesos （这是标配 ）

2）Jenkins on Mesos

3）Mesos 做 docker 的编排服务等。

与 OpenStack 相比， 首先，物理机和虚拟机都可以作为 Mesos 的集群节点；其次， 粒度不同， Mesos 的基本计算单元是容器（LXC） , 而 OpenStack 的是 VM（听说现在也支持Docker 容器技术了），前者资源利用率更高；最后，轻量级，Mesos 只负责 Offer 资源给Framework，不负责调度资源。 OpenStack 更贴近于 IaaS 层，而 Mesos 在 IaaS 之上。所以有人称其为 DCOS，或者分布式操作系统。

MESOS的优点与缺点：

优点：

资源管理策略 Dominant Resource Fairness(DRF), 这是 Mesos 的核心，也是我们把Mesos 比作分布式系统 Kernel 的根本原因。通俗讲，Mesos 能够保证集群内的所有用户有平等的机会使用集群内的资源，这里的资源包括 CPU，内存，磁盘等等。

轻量级。相对于 YARN，Mesos只负责 Offer 资源给 Framework，不负责调度资源。这样，理论上，我们可以让各种东西使用 Mesos 集群资源，而不像 YARN 只拘泥于 Hadoop，我们需要做的是开发调度器（Mesos Framework）。

提高分布式集群的资源利用率：这是一个 Generic 的优点。从某些方面来说，所有的集群管理工具都是为了提高资源利用率。VM 的出现，催生了 IaaS；容器的出现，催生了 K8s, Mesos 等等。简单讲，同样多的资源，我们利用 IaaS 把它们拆成 VM 与 利用 K8s/Mesos 把它们拆成容器，显然后者的资源利用率更高。

缺点：

门槛太高，为了使用Mesos，你需要不同的 Mesos Framework，像 Marathon，Chronos，Spark 等等。或者自己写 Framework 来调度 Mesos给的资源，这让大家望而却步。

目前对 Stateful Service 的支持不够。Mesos 集群目前无法进行数据持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver，数据持久化问题将得到改善。

脏活累活不会少。Team 在使用 Mesos 前期很乐观，认为搞定了 Mesos，我们的运维同学能轻松很多。然而，根本不是那么回事儿，集群节点的优化，磁盘，网络的设置，等等这些，Mesos 是不会帮你干的。使用初期，运维的工作量不仅没有减轻，反而更重了。Mesos 项目还在紧锣密鼓的开发中，很多功能还不完善。

Mesos + Marathon 基本上现在最稳定的 Docker 集群化调度框架了。

Mesos 和 Zookeeper的关联：

Zookeeper 是一个为分布式应用提供一致性服务的软件， 而 Mesos 是一个分布式应用。所以在生产环境，我们需要使用 Zookeeper 来为 Mesos 提供一致性服务。

MESOS特点：

带日志模块，但是功能比较简单，没有一个全局的展示

可以进行性能统计

Mesos 是根据当前的集群资源统计来决定给调度器分配多少资源的，资源耗尽只会导致新的应用无法部署，不会影响正在运行的东西。

可以配置负载均衡。 并且 Mesos 本身也有多 Master 机制

MESOS如何调度资源？

Mesos 本身不负责分配资源，它只是将当前集群的剩余资源提供给注册到它的调度器，由调度器本身来决定使用多少资源，以及合适释放资源。