The Tail at Scale，是 Google 2013 年发表的一篇论文，大规模在线服务的长尾提早问题。
要晓得怎么解决长尾问题，先要了解长尾提早是个什么问题，在开发在线服务的时候，咱们都晓得要关注服务的 p99/p999 提早，要让大部分用户都可能在预期的工夫范畴内取得响应。
上面是一个不同响应工夫的申请数分布图：
大部分零碎也都遵循这种散布法则，当初互联网的零碎规模比拟大，一个服务依赖几十上百个服务的状况都是有可能的。繁多模块的长尾提早会在有大量依赖的状况下，在服务粒度被放大，《The Tail at Scale》论文里给出了这样的例子。
思考一个零碎，大部分服务调用在 10ms 内响应，但 99 分位数的提早为 1 秒。如果一个用户申请只在一个这样的服务上解决，那么 100 个用户申请中只有一个会很慢（一秒钟）。
这里的图表概述了在这种假如的状况下，服务级别的提早是如何被十分小概率的大提早值影响的。
如果一个用户申请必须从 100 个这样的服务并行收集响应，那么 63% 的用户申请将须要超过一秒钟（图中标记为 “x”）。
即便对于只有万分之一概率在单台服务器上遇到超过一秒的响应提早的服务，如果服务的规模达到 2000 实例的话，也会察看到简直五分之一的用户申请须要超过一秒（图中标记为 “o”）。
Xargin 注：
- 因为申请是并行的，所以只受最慢的那个影响，100 个申请都落在 99 分位内提早才会小于 1s，所以提早小于 1s 的概率是 pow(0.99, 100) = 0.3660323412732292，也就是说肯定有 63% 的概率会超过 1s。
- 第二个，咱们落在 99 分位的概率是 pow(0.9999, 2000) = 0.8187225652655495，也就是将近 20% 的用户响应会超过 1s。
下面的表格列出了一个实在的谷歌服务的测量后果，该服务在逻辑上与前文简化过的场景类似；根服务通过两头服务将一个申请散发到十分多的叶子服务。表展现了大量扇出 (fan-out) 调用时，对提早散布的影响。
在根服务器上测量的单个随机申请实现的 99 分位提早是 10ms。然而，所有申请实现的 99 分位数提早是 140ms，95% 的申请 99 分位数提早是 70ms，这意味着期待最慢的 5% 的慢申请要对总的 99 百分位数提早的一半负责。对这些慢申请场景进行优化，会对服务的整体提早产生微小影响。
为什么会有长尾提早？
单个服务组件的长尾高提早可能因为许多起因产生，包含：
共享资源 (Shared resources，Xargin: 混部当初越来越多了)。机器可能被抢夺共享资源(如 CPU 外围、处理器缓存、内存带宽和网络带宽) 的不同利用所共享，而在同一利用中，不同的申请可能抢夺资源。
守护程序 (Daemons)。后盾守护程序可能均匀只应用无限的资源，但在运行时可能会产生几毫秒的峰值抖动。
全局资源共享 (Global resource sharing)。在不同机器上运行的应用程序可能会争抢全局资源(如网络交换机和共享文件系统)。
保护流动 (Maintenance activities)。后盾流动(如分布式文件系统中的数据重建，BigTable 等存储系统中的定期日志压缩，以及垃圾收集语言中的定期垃圾收集) 会导致周期性的提早顶峰。
排队(Queueing)。两头服务器和网络交换机中的多层队列放大了这种可能性。
同时也是因为以后硬件的趋势：
功率限度 (Power limits.)。古代 CPU 被设计成能够临时运行在其平均功率之上(英特尔睿频减速技术)，如果这种流动继续很长时间，之后又会通过节流(throttling) 限度发热；
垃圾收集 (Garbage collection)。固态存储设备提供了十分快的随机读取拜访，然而须要定期对大量的数据块进行垃圾收集，即便是适度的写入流动，也会使读取提早减少 100 倍；
能源管理(Energy management)。许多类型的设施的省电模式能够节俭相当多的能量，但在从非流动模式转为流动模式时，会减少额定的提早。
解决方案
模块内尽量升高长尾提早
** 服务分级 && 优先级队列(Differentiating service classes and
higher-level queuing)**。差异化服务类别能够用来优先调度用户正在期待的申请，而不是非交互式申请。放弃低级队列较短，以便更高级别的策略更快失效。
缩小队头阻塞(Reducing head-of-line blocking)。将须要长时间运行的申请打散成一连串小申请，使其能够与其它短时间工作交织执行；例如，谷歌的网络搜寻零碎应用这种工夫宰割，以避免大申请影响到大量其它计算成本较低的大量查问提早。(队头阻塞还有协定和连贯层面的问题，须要通过应用更新的协定来解决，比方 h1 -> h2 -> h3 的降级思路)
** 治理后盾流动和同步中断(Managing background activities and
synchronized disruption)**。后台任务可能产生微小的 CPU、磁盘或网络负载；例子是面向日志的存储系统的日志压缩和垃圾收集语言的垃圾收集器流动。能够联合限流性能，把重量级操作分解成老本较低的操作，并在整体负载较低的时候触发这些操作(比方中午)，以缩小后盾流动对交互式申请提早的影响。
申请期间内的一些自适应伎俩
对冲申请(Hedged requests)。克制提早变动的一个简略办法是向多个正本收回雷同的申请(Go 并发模式中的 or channel)，并应用首先响应的后果。一旦收到第一个后果，客户端就会勾销残余的未解决申请。不过间接这么实现会造成额定的多倍负载。所以须要思考优化。
一个办法是推延发送第二个申请，直到第一个申请达到 95 分位数还没有返回。这种办法将额定的负载限度在 5% 左右，同时大大缩短了长尾工夫。
捆绑式申请(Tied requests)。不像对冲一样期待一段时间发送，而是同时发给多个正本，但通知正本还有其它的服务也在执行这个申请，正本工作解决完之后，会被动申请其它正本勾销其正在解决的同一个申请。须要额定的网络同步。
跨申请的自适应伎俩
微分区(Micro-partition)。把服务器辨别成很多小分区，比方一台大服务器分成 20 个 partition，这样无论是流量调整或者故障复原都能够快十分多。以细粒度来调整负载便能够尽量升高负载不均导致的提早影响。
选择性的复制 (Selective replication)。为你检测到的或预测到的会很热的分区减少复制因子。而后，负载均衡器能够帮忙扩散负载。谷歌的次要网络搜寻零碎采纳了这种办法，在多个微分区中对风行和重要的文件进行额定的复制。( 就是热点分区多筹备些实例啦，感觉应该须要按具体业务去做一些预测)
将慢速机器置于考察期 (Put slow machines on probation)。当检测到一台慢速机器时，临时将其排除在操作之外(circuit breaker)。因为迟缓往往是临时的，监测何时使受影响的零碎从新上线。持续向这些被排除的服务器收回影子申请，收集它们的提早统计数据，以便在问题缓解时将它们从新纳入服务中。( 这里就是简略的熔断的实现)
一些其它的衡量
思考“足够好”的响应 (Consider ‘good enough’ responses)。一旦所有的服务器中有足够的一部分做出了响应，用户可能会失去最好的服务，即失去轻微的不残缺的后果，以换取更好的端到端提早。( 这里应该是大家常说的降级，如果不残缺的后果对于用户来说曾经足够有用，那不重要的不展现也能够)
应用金丝雀申请(canary requests)。在具备十分高扇出的零碎中可能产生的另一个问题是，一个特定的申请触发了未经测试的代码门路，导致解体或同时在成千上万的服务器上呈现极长的提早。为了避免这种相干的解体状况，谷歌的一些 IR 零碎采纳了一种叫做“金丝雀申请”的技术；根服务器并不是一开始就把一个申请发送给成千上万的叶子服务器，而是先把它发送给一个或两个叶子服务器。其余的服务器只有在根服务器在正当的工夫内从金丝雀那里失去胜利的响应时才会被查问。