当一个服务节点向多个服务节点扇出请求时，通常情况下其响应时间取决于最慢的那个下游节点的响应。假设请求命中了某个不常用的逻辑路径导致其延迟突然增大概率是万分之一，那么100台下游服务器中至少有一个服务器命中了慢速路径的概率是: 1 - (9999/10000)^100， 可以看出100台服务器全部命中快速路径的概率是(9999/10000)^100 约等于0.99，那么反过来至少有一个服务器命中慢速路径导致整体延迟上涨的概率就是0.01，那么从数学期望的角度看，我们每一百次请求就会有一个请求命中慢速路径，而我们的QPS如果超过100，那么每秒中都会有一个请求命中，因此我们的p99延迟将取决于整个系统命中那万分之一概率的慢速路径。
换一个角度去看: 100 个请求都落在 99 分位内延迟才会小于 1s，所以延迟小于 1s 的概率是 pow(0.99, 100) = 0.3660323412732292，也就是说一定有 63% 的概率会超过 1s。
从概率的角度看，一个聚合窗口期内(1s)可以发现响应时间与请求数量之间是呈长尾分布的，高延迟的请求数量是极少的。
当通过看p99分位的延迟与p95分位的延迟时，发现他们之间的数值差距巨大就说明该系统存在长尾延迟问题。
解决长尾延迟有什么意义? 最大的意义就是可以优化p99的指标，提升用户体验，而对于一个计算机系统来说性能是一切的货币，无论是任何机器学习算法都必须在规定的时间内返回结果，p99延迟越低，那么算法就可以做更多的模型策略优化业务指标，获得业务增长。所以对于服务端系统来说，优化延迟是一个永恒的话题。
资源竞争: 现代服务端架构中，为提高资源的利用效率在各个层面都存在着资源共享，而资源共享在并发场景下就会衍生出资源竞争的问题，竞争会在资源不足或者存在临界资源时产生较大的延迟。例如，网络交换机，内存/CPU/IO，SSD的垃圾收集，数据库。
后台任务: 延迟是对交互任务而言的，对于非交互任务来说，我们不关心他是否可以快速响应，只要能保证在一段时间后完成即可，我们更关注其吞吐量，这样的任务就是后台任务，例如GC，LSM的compact，Hive的MR任务等。这些任务在执行时会消耗大量资源，导致提供给交互任务的资源不足进而升高延迟。
排队等待: 资源是有限的，在系统的各个层面都存在着因资源不足而等待执行的情况，这种等待就如同开往目的地时要经过的红绿灯，其必然会增加整个请求的延迟。
过载保护: 在硬件层面cpu会因为超频使用而过热，有融化风险此时cpu会拒绝指令，导致延迟升高。软件层面，系统会因为短时间内大量请求的突增而耗尽资源导致系统性崩溃，因此会有过载保护机制，对突发流量进行拒绝，或延迟处理，这就会导致请求延迟升高。
直觉上来看，可以分析产生问题的原因并提出解决方案，而原因通常来自于上述的四种情况，我们需要良好的观测手段发现大型分布式系统中存在的这些不会稳定复现的问题，进而解决。
但对于一个大规模分布式系统来说，逻辑链路复杂，需求频繁迭代，服务节点数量众多。这都导致不可能凭借人力来找到所有的慢速路径，就算某一次版本修复了所有慢速路径也会因为马上发布的新版本从而引入新的风险，更不用说计算机底层系统的复杂性所带来的风险(交换机，网卡，cpu等)。
所以换一个思路来看: 既然长尾延迟必然存在，那我们就影响想办法阻止长尾延迟的影响。
当出现长尾请求后利用冗余副本资源来降低长尾延迟影响的技术。
一个直觉的方案是，同时请求用来容灾的副本谁优先返回结果则以谁的结果为准，这样对于命中慢速路径的请求通过副本返回的数据进行了兜底。