尾延迟治理手册 把 P99 从 800ms 压回 120ms

P50 好看、P99 崩盘是服务型产品最常见的性能形态。用户投诉往往不是"整体慢"，而是"偶尔特别慢"。尾延迟治理不是调一个参数，而是一组互相配合的手段。本文按排查顺序给出可执行手册。

一、先测量对：不要拿平均值骗自己

import "github.com/prometheus/client_golang/prometheus"

lat := prometheus.NewHistogramVec(prometheus.HistogramOpts{
    Name:    "http_request_duration_seconds",
    Buckets: []float64{.005, .01, .025, .05, .1, .2, .5, 1, 2, 5},
}, []string{"route", "code"})

分位数的正确算法是在时间窗口内对 bucket 做聚合再算 quantile，而不是把各实例的 P99 求平均——后者会得到一个没有任何物理意义的数字。

histogram_quantile(0.99, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))

三个必备视图：QPS 时序、P50/P95/P99 三线同图、以及各下游依赖的 P99。尾延迟问题九成出现在依赖侧。

二、六个根因与识别指纹

| 根因 | 指纹 | 首要动作 | |---|---|---| | 队列等待（并发不足） | CPU 未满但 P99 高，in_queue 堆积 | 扩并发/加实例 | | GC 停顿 | P99 与 GC 周期同频，延迟图有锯齿 | 减分配、调 GOGC | | 连接池等待 | 依赖侧 P99 高，池 wait_count 上升 | 调池参数 | | 缓存未命中雪崩 | 命中率骤降时刻 P99 陡起 | singleflight、预热 | | 慢查询长尾 | DB P99 远大于 P50，锁等待 | 索引/超时/拆分 | | 冷 JIT / 首次初始化 | 新实例上线后前 N 个请求慢 | 预热 + 渐进引流 |

三、 hedging 与超时预算

对幂等读请求做**投机重试（hedged request）**是压 P99 最直接的手段：第 150 毫秒还没返回就并发发第二份，取先回来的。

func GetWithHedge(ctx context.Context, key string) (string, error) {
    ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
    defer cancel()

    type res struct { v string; err error }
    ch := make(chan res, 2)
    go func() { v, err := cache.Get(ctx, key); ch <- res{v, err} }()

    t := time.NewTimer(30 * time.Millisecond)
    defer t.Stop()
    select {
    case r := <-ch:
        return r.v, r.err
    case <-t.C:
        go func() { v, err := cache.Get(ctx, key); ch <- res{v, err} }()
        r := <-ch
        return r.v, r.err
    }
}

代价是双倍流量，务必只对幂等读开启，并配合下游容量确认。

超时预算比 hedging 更重要：入口给 300ms，那么每跳下游必须收敛。

func budget(ctx context.Context, ratio float64) (context.Context, context.CancelFunc) {
    if dl, ok := ctx.Deadline(); ok {
        left := time.Until(dl)
        if left < 10*time.Millisecond {
            left = 10 * time.Millisecond
        }
        return context.WithTimeout(ctx, time.Duration(float64(left)*ratio))
    }
    return context.WithTimeout(ctx, 200*time.Millisecond)
}

四、并发与队列治理

小队列 + 快速失败，几乎总是优于大队列 + 排队。核心原因：请求排了 500ms 队再执行，用户早已离开，服务端却还在算。

sem := make(chan struct{}, 64)                 // 并发上限
if !tryAcquire(sem, 5*time.Millisecond) {
    metrics.RejectedTotal.Inc()
    http.Error(w, "busy", http.StatusServiceUnavailable)
    return
}
defer release(sem)

配合两条：

1. 负载均衡算法选 P2C 或 Least-Conn，轮询会把慢节点放大到全体；
2. 每个下游独立熔断器，一个慢依赖不能占满入口 worker。

breaker := gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name: "pricing", Timeout: 10*time.Second, ReadyFunc: nil,
    Counters: &metrics,
})

五、GC 与内存（Go 项目）

Go 的 GC 停顿通常只有毫秒到几十毫秒，但分配率高时会放大尾延迟。诊断：

GODEBUG=gctrace=1 ./server 2>&1 | grep gc
go tool pprof http://localhost:6060/debug/pprof/allocs

收益最大的三类改动：

1. 消除热路径上的临时分配（strings.Split 拼 key、fmt.Sprintf 日志、[]byte↔string 转换）；
2. 对象池化（sync.Pool 复用大 buffer）；
3. 主动设 GOMEMLIMIT + 合理 GOGC，把 GC 频率与内存换用做交换。

func init() {
    debug.SetGCPercent(200)
    debug.SetMemoryLimit(3 << 30)
}
var bufPool = sync.Pool{New: func() any { b := make([]byte, 0, 32<<10); return &b }}

六、冷启动预热

新实例的第一个请求要付：连接建立、TLS 握手、DNS 解析、JIT/反射缓存、连接池初始化。解决办法是 readiness 门控 + 内部预热：

func warmup(ctx context.Context) error {
    for _, path := range []string{"/api/v1/articles?page=1&page_size=10", "/api/v1/tags"} {
        for i := 0; i < 50; i++ {
            req, _ := http.NewRequestWithContext(ctx, http.MethodGet, "http://127.0.0.1:8080"+path, nil)
            if resp, err := http.DefaultClient.Do(req); err == nil {
                io.Copy(io.Discard, resp.Body)
                resp.Body.Close()
            }
            time.Sleep(5 * time.Millisecond)
        }
    }
    return nil
}

配合 K8s 的 readinessProbe 与慢启动（Service minReadySeconds、或服务网格 warmup 配置），让流量从零逐步升到全量。

七、验证收尾

治理完必须回到同一张图上看：P99 收敛、P50 未变差、错误率未升、下游 QPS 未异常放大（防止为了 P99 疯狂重试把依赖打挂）。把优化项按"每 QPS 成本"排序做，尾延迟治理通常能拿到产品体验上最明显的一次提升。

小结

手册的顺序是：测准分位数 → 定位根因指纹 → 收敛超时预算 → 小队列快速失败 + 熔断 → hedged 幂等读 → GC 与内存 → 冷启动预热。其中"每跳等比收敛的超时预算"和"快速失败优于排队"两条，几乎是任何 P99 优化都绕不开的地基。