尾延迟与长尾效应是什么
请求延迟分布并不均匀，绝大多数请求很快，少数请求极慢，形成长尾。单服务的 P99 看着不高，但一个页面或接口往往要扇出调用多个下游，任何一个慢就会拖慢整体，端到端尾延迟被显著放大。这正是「平均延迟看起来正常、用户体验却很差」的常见原因。治理思路是降低扇出、并行调用、控制排队、识别慢节点，并把重试控制在不会放大整体负载的范围内。
基本信息
| 成因 | GC 停顿、锁竞争、慢节点、队列排队、重试与超时叠加 |
|---|---|
| 放大机制 | 扇出多个下游时，慢请求概率近似 1-(1-p)^N |
| 观测口径 | P95、P99、P999 与超时占比，而不是平均值 |
| 治理手段 | 并行化、对冲请求、超时预算、慢节点摘除、减少串行依赖 |
| 典型来源 | 排队等待是最常见的可治理因素，优先级高于优化单次计算 |
典型使用场景
- 聚合页面：一个页面调用多个下游，必须并行并设置统一超时预算
- 支付链路：单次异常延迟直接影响转化，需要重点治理 P99
- 微服务调用链：识别链路中贡献尾延迟最大的依赖
- 批处理调度：慢任务拖慢整批完成时间，需要单独隔离
- 容量评估：压测结论要按分位数而非均值解读
- 体验治理：把端到端 P99 作为发布门槛的一部分
扇出放大粗算
扇出放大粗算
# 单下游出现慢请求的概率为 p，扇出 N 后整体变慢的概率
单下游慢概率 p = 1%
扇出 N = 10：端到端至少一个慢的概率 ≈ 1-(1-p)^N ≈ 9.6%
扇出 N = 50：≈ 39.5%
# 对策顺序：先并行化，再对冲，最后才考虑重试
# 并行化：把串行依赖改成并行，端到端取最慢而非求和
# 对冲：超时后向另一副本再发一份，取先返回者（注意流量放大）
# 重试：设限并错开时机，避免连锁放大下游负载观测与手段对照
| 现象 | 可能原因 | 优先手段 |
|---|---|---|
| P99 高但均值正常 | 少量慢请求来自排队或慢节点 | 定位长尾源，摘除慢节点，压缩排队时间 |
| 所有分位同时抬高 | 整体容量不足或依赖普遍变慢 | 扩容、限流与降级，先止血 |
| 延迟呈周期性尖峰 | 定时任务、GC 或缓存批量失效 | 错峰、调优 GC、TTL 抖动 |
| 尾延迟随流量上升而恶化 | 队列排队成为主因 | 限流、隔离线程池、降低排队深度 |
改善 P99 的关键是找到长尾来源：先判断是排队、GC 还是慢依赖，再选手段；不做定位就并行加机器，往往只是在为排队付出更多成本。
重试是双刃剑：它在下游抖动时会把流量放大，本身又制造新的尾延迟，必须先限制次数并配合熔断与退避。