一些资料
cpu带宽控制的原理是在给定周期内（cpu.cfs_period_us）内限制进程组的运行时间（cpu.cfs_quota_us），这两个参数值通过cpu子系统来设置。
cfs_rq相关的两个成员是 runtime_remaining 和 runtime_expires ，前者是当前进程组的剩余时间片，后者是时间片的到期时间。
内核的做法是：
目前cpu亲缘性设置有两种方式：
但是有一点需要注意的是，通过sched_setaffinity设置的cpu_mask不允许超出cpuset.cpus的范围，超出部分是无效的。
举例，进程A所在的cpuset控制组cpuset.cpus参数值是0,1,2,3,4，但是进程运行期间调用sched_setaffinity()修改cpu_mask为0,1,2,4,7。因为7并不在cpuset.cpus范围里，所以内核会把7忽略掉，最终进程只能在0,1,2,4这几个CPU上运行。
以内核3.10.79为例。这里分析一下内核对于cgroup.memory进程组oom的过程，以及混部环境下需要什么样的oom策略。
内核对于每个memory cgroup维护一个计数器，统计当前cgroup内已经使用了的内存。每当cgroup内进程创建页面时，页面大小所占用的内存就会通过res_counter_charge_locked()函数计入计数器里。而当内存占用超过memory.limit_in_bytes所设置的阈值时，charge失败，返回ENOMEN错误。
int res_counter_charge_locked(
struct res_counter *counter, unsigned long val, bool force)
{
int ret = 0;
if (counter->usage + val > counter->limit) {
counter->failcnt++;
ret = -ENOMEM;
if (!force)
return ret;
}
counter->usage += val;
if (counter->usage > counter->max_usage)
counter->max_usage = counter->usage;
return ret;
}
另外有一个问题需要注意的是，内存这个子系统是拓扑型控制的，不是平级控制的。下一级子系统的所有limit_in_bytes之和不能超过父亲的limit_in_bytes值，否则会设置失败。
所以内存计数的时候：
子cgroup也许内存配额有冗余，但父cgroup不一定会有冗余，所以在反向递归计数的时候，谁内存超过阈值了，就oom谁（选择这个cgroup下的某个进程kill掉，所以这里是有可能某个cgroup明明内存没有被超限但也会被莫名的干掉了）。
libprocess是mesos中非常重要的一个基础库，提供一些很方便的helper函数以及并发编程所需要的基本原语，例如下面我将重点讲的future/promise。
为了更好的解释future/promise是什么，我抽取了一段mesos中的代码作为例子：
Future<Socket> PollSocketImpl::accept()
{
return io::poll(get(), io::READ)
.then(lambda::bind(&internal::accept, get()));
}
这个函数的基本作用是：使用io::poll()注册io::READ事件，并且当事件ready的时候，调用internal::accept()。
显然，这是一个异步的accept()方法。
google服务器集群的管理系统，类似于百度的Matrix，阿里的fuxi，腾讯的台风平台等等，还有开源的mesos
Borg provides three main benefits: it
论文 http://mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf
这篇论文主要从面向运维友好的角度，思考了大规模分布式系统的设计和部署相关的一些原则和最佳实践。
We have long believed that 80% of operations issues originate in design and development, so this section on overall service design is the largest and most important.
When systems fail, there is a natural tendency to look first to operations since that is where the problem actually took place. Most operations issues, however, either have their genesis in design and development or are best solved there.
对服务整体设计影响最大的一些运维友好的基本原则如下：
