开发和运维高并发系统的工程师可能都有过类似经验，明明系统已经调优完毕，该异步的异步，该减少互斥的地方引入无锁，该减少IO的地方更换引擎或者硬件，该调节内核的调节相应参数，然而，如果在系统中引入实时监控，总会有少量响应的延迟高于均值，我们把这些响应称为尾延迟（Tail Latency）。对于大规模分布式系统来说，尾延迟的影响尤其严重，例如大规模搜索引擎，单个请求可能就会发送到上万台服务器，系统不得不等待尾延迟响应返回之后才能返回给用户。

尾延迟可能是程序设计本身导致的毛病，但是，即便程序设计完全无误，尾延迟依然可能存在。华盛顿大学的Jialin Li等人经过研究发现，硬件，操作系统本身，都可能导致尾延迟响应，例如：主机系统其他进程的影响，应用程序里线程调度，CPU功耗设计等等。

在本公众号之前提到的数据中心操作系统设计中，我们提到了Distributed OS设计的核心挑战——如何让延迟敏感性任务和批处理型任务混跑，这个核心挑战，就在于如何对付尾延迟。我们在当时提到了Google最新的成果Heracles，在国内还没有造出Borg类似机制的框架时，Heracles已经可以让Google数据中心的资源利用率达到90%以上。那么我们也就顺道来介绍一下Heracles以及它是如何对付尾延迟的。

Heracles把数据中心运行的任务分为两类：BE(Best Effort Batch)和LC(Latency Critical)，LC型任务运行依赖严格的SLO(Service Level Objectives，包含CPU缓存，主存，IO，以及网络等主机物理资源)。混排时，由于物理资源的SLO冲突导致LC任务会有更多的尾延迟发生。Heracles的目标在于提供对这些共享资源更好的隔离机制，尽可能避免SLO冲突。下边分别谈谈这些引起SLO冲突的共享资源：

CPU方面：
操作系统的资源调度，不能简单地给LC任务分配更高的优先权来达到目标，通常的Linux内核调度算法CFQ(公平调度器)在LC和BE混跑时，会轻易导致大量SLO冲突。实时调度算法如SCHED_FIFO则会导致很低的资源利用率。CPU设计中的超线程机制，也会给问题带来更多的复杂性，例如：一个超线程在执行BE任务时，会从CPU指令带宽，共享L1/L2缓存，TLB等方面影响另一个超线程执行的LC任务。

内存方面：
大多数LC型任务都会依赖巨大的内存，例如搜索，内存KV等等，因此，这些任务的延迟对于内存的带宽非常敏感。目前并不存在硬件机制来确保内存带宽隔离，而在多CPU机器上简单地采用NUMA机制又会导致不能充分使用内存，或者访问远端CPU Socket内存区域而带来更大的延迟。

网络方面：
大多数数据中心都会通过精细设计拓扑图来确保机器之间双向通信的带宽。在单机情况下，可以通过修正一些协议栈确保LC型的短消息能够比BE的大型消息有更高的优先权

功耗是另外一个不得不考虑的因素：
大多数CPU都有节能设计，系统会根据平均负载来动态调整CPU的主频，因此混跑时的负载取决于LC和BE的平均负载，当CPU主频降低时，LC型任务的延迟也会受到影响。

Heracles在设计上引入多种隔离机制，在确保SLO时尽可能提升资源使用负载：

CPU方面：Heracles会借助cpuset和cgroups尽可能让LC和BE型任务不在同一个Core上运行。此外，Heracles采用了目前Intel CPU上的CAT(Cache Allocation Technology)技术，这是个硬件机制。CAT可以在共享的L1/L2缓存上定义分区，确保缓存不会相互污染。

内存方面：由于目前并不存在硬件的隔离机制，因此Heracles实现了一个软件层面的监控机制，定期检查内存带宽使用情况，并估计LC和BE的带宽使用，如果LC没有获得足够的带宽，Heracles会减少BE使用的CPU Core数目。

网络方面：Heracles使用了Linux流量控制机制——qdisc调度器，确保BE任务的吞吐量和配额，并频繁更新调度策略。

功耗方面：Heracles基于现有硬件支持的特性实现了主频监控。

通过这些工作，Heracles让Google数据中心的集群资源使用率达到了惊人的90%。在思路上，Heracles的实现并不复杂，但它是跟Borg一体化的系统，我们不能说实现了这些资源隔离手段就能解决了尾延迟，因为单机的资源管理与隔离跟数据中心操作系统是一体化的。

实时上，除了依赖于复杂的Heracles和Borg机制，Google之前也曾经公开了另一种简单有效的策略对付尾延迟：在12年左右我们曾经看到过Google基础架构之神Jeff Dean的一篇Slide，里边提到了Google分布式系统响应的概率延迟分布。在该Slide发布的时候，并没有引起本人的关注，因为当时并没有猜透这些概率分布的背后代表了什么意义。结合尾延迟，我们终于可以更好的了解这些意图：尾延迟的发生可以看作是随机行为，引入多副本，任何一个请求，都会多次发送到多副本之上，系统会选择延迟最短的响应返回，就可以大大降低尾延迟对于最终响应的影响，十分简单有效的思路。至于发送多少次，就是这些概率延迟分布数字本身的意义了。

可能这个思路对于大多数基础架构开发者来说，是更加简单有效的策略，与其试图从操作系统内核和Distributed OS来解决这个挑战，不如放到应用层，多副本多次发送单个请求。在复杂与简单上，Google都是我们重点学习的对象。