网络中的长尾问题

（1）长尾请求

定义：

长尾请求一般是指请求时间明显高于均值的那部分占比较小的请求。 业界关于延迟有一个常用的P99标准， 也就是99%的请求延迟要满足在一定耗时以内， 1%的请求会大于这个耗时， 而这1%就可以认为是长尾请求。

参考：安全验证 - 知乎

危害：

长尾请求虽然占比一般比较少，但是对用户的体验也会有较大影响， 考虑到当前长尾请求占比为1%， 如果客户端并发100来请求这个服务， 则这个服务也就100%处于长尾的高耗时状态, 不是100的并发就有一个概率折算公式， 并发越高， 客户端处于长尾耗时的概率就越大。 另外就是用户即便是单并发的来请求， 一百个里面有一次慢的， 也会另用户影响深刻。

产生原因：

在分布式系统中， 导致长尾请求的原因有很多, 针对系统自身来说，主要有三类情况，

一种是依赖的系统和环境出现了问题，例如硬盘慢了， 操作系统执行了后台操作造成cpu调度走了。

第二种是自己的调度原因, 例如采用了简单的锁竞争机制，导致有的倒霉的线程一直得不到运行权。

第三种是系统压力太大，造成了任务队列积压。

总结来说软硬件因素都可能导致一个请求出现高于均值的耗时。

BRPC和其他RPC相比，主要解决的是第二类调度问题， 其构建了读写wait-free的调度，充分利用CPU，避免在CPU有空闲的情况下，因为自身调度不够灵活导致的长尾。

解决方法：

作为外部的客户端来说， 一个通用的解决长尾请求的方案是发送备用请求， 例如对一个后端的数据请求， 本来只需要发送1次， 而我们分别给三个实例发送三次， 最快的一个返回即终止其余的两个请求即可。

（2）尾延迟Tail Latency

定义

开发和运维高并发系统的工程师可能都有过类似经验，明明系统已经调优完毕，该异步的异步，该减少互斥的地方引入无锁，该减少IO的地方更换引擎或者硬件，该调节内核的调节相应参数，然而，如果在系统中引入实时监控，总会有少量响应的延迟高于均值，我们把这些响应称为尾延迟（Tail Latency）。

参考：高并发系统中的尾延迟Tail Latency_捭阖寰宇的博客-CSDN博客

影响

对于大规模分布式系统来说，尾延迟的影响尤其严重，例如大规模搜索引擎，单个请求可能就会发送到上万台服务器，系统不得不等待尾延迟响应返回之后才能返回给用户。

解决

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冲突的共享资源分析

下边分别谈谈这些引起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在共享资源的隔离机制

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

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

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