Google Omega解决什么问题

要解决单体调度的什么问题:
1.扩展性。都写在单体系统代码难扩展。
2.性能瓶颈
3.隔离性。比如长服务的scheduler计算会导致head-of-line blocking

要解决两层调度的什么问题：
1.悲观并发控制吞吐有限。
这个问题不太好理解，我们知道在JVM里并发编程时，cas比加锁性能好的原因是加锁overhead高，但在分布式编程里、在这个场景下，悲观并发控制应该没有这种缺点呀？反倒是乐观并发控制要重试、吞吐更低吧？
其实悲观锁不是问题，问题是google的长服务scheduler会花比较长的时间做计算（号称NP hard问题），这段时间一直锁着大offer会影响其他大任务，比如此时有另一个batch任务需要消耗大量资源，就只能等待这个大offer被释放，甚至在大量重试后放弃执行。

image.png

按论文的说法，Mesos的设计假设是scheduler能做出快速调度决策，但这种假设不符合google的workload。

image.png

visibility。比如A scheduler拿到一个高优先级任务，但是offer不够大，又看不到在跑低优先级的机器资源。

个人理解，可能存在的问题：

1.饥饿问题。比如一个吞吐很高的批处理scheduler会害得长服务scheduler饥饿；虽然Omega号称用增量获取资源的方式，但是长服务真的可以进行资源的拆分、增量获取资源么？
2.长时间的scheduler计算不断遇到乐观锁冲突。

思考总结：

1.改个并发调度策略都能出一篇论文……
2.很难说这种架构就比两层调度好，这种架构可以理解成是针对长时间计算的scheduler算法做的优化，如果没有用这种慢算法，那单体调度、两层调度完全能满足需求？
3.真想优化并发冲突还能进一步优化：给每个scheduler分配一个建议区间以及全局信息，scheduler优先在自己的建议区间选资源，不得已才用全局的，再不得已再抢占。

实验部分没怎么看懂，时间有效只挑了结论看。