延迟的度量：P50、P99、P999延迟的含义，如何正确测量端到端延迟
聊到实时数据流，大家最关心的就是延迟。但说实话，很多人对延迟的理解还停留在「越快越好」这个层面。我见过不少团队，一上来就盯着平均延迟看，结果系统上线后用户投诉不断，排查半天才发现是长尾延迟在作祟。
今天我们就来掰扯清楚，延迟到底该怎么量、怎么测。
一、为什么不能只看平均延迟？
先讲个我自己的经历。几年前我负责一个实时风控系统，数据从产生到决策必须在 100ms 内完成。上线前压测，平均延迟只有 30ms，团队都很满意。结果上线第一天，业务方就炸了——有大量交易被误判为超时。
查日志才发现，虽然平均延迟低，但每 1000 条数据里就有几条延迟飙到了 500ms 以上。这些「倒霉蛋」刚好撞上了 GC 暂停或者网络抖动。你看，平均延迟把问题全掩盖了。
所以，我们真正需要关注的是延迟的分布情况，而不是一个简单的平均值。
二、P50、P99、P999 到底在说什么？
这几个概念其实不复杂。说白了，它们就是延迟的「百分位点」。
- P50（中位数延迟）：一半的数据延迟低于这个值，一半高于这个值。它代表「典型情况」下的延迟。
- P99（99 分位延迟）：99% 的数据延迟低于这个值，只有 1% 的数据比它慢。它代表「大多数情况」下的上限。
- P999（99.9 分位延迟）：99.9% 的数据延迟低于这个值，只有 0.1% 的数据比它慢。它代表「极端情况」下的表现。
举个例子，假设你统计了 1000 条消息的延迟：
| 指标 | 延迟值 | 含义 |
|---|---|---|
| P50 | 20ms | 一半的消息在 20ms 内完成 |
| P99 | 80ms | 99% 的消息在 80ms 内完成 |
| P999 | 500ms | 99.9% 的消息在 500ms 内完成 |
你想想看，如果只看平均延迟，可能只有 30ms。但 P999 高达 500ms，这意味着每 1000 条消息里就有 1 条会延迟半秒。对于实时交易系统来说，这 0.1% 的慢请求足以让用户体验崩盘。
核心原则：优化延迟，先看 P99 和 P999，再看 P50。把长尾砍掉，比把平均拉低更重要。
三、如何正确测量端到端延迟？
测量延迟这件事，坑比想象中多。我见过有人把「消息入队时间」和「消息出队时间」的差值当成端到端延迟，结果漏掉了网络传输、序列化反序列化、业务处理等环节。这显然不对。
端到端延迟，指的是从数据产生的那一刻，到数据被消费方真正使用的那一刻，中间经历的全部时间。
3.1 埋点方案
我个人习惯的做法是：在数据源头和生产端分别埋两个时间戳。
- 源头时间戳（T1）：数据在业务系统生成时，立即打上时间戳。注意，这个时间戳要尽可能靠近数据产生点，不要等经过几层缓存后再打。
- 消费时间戳（T2）：数据到达消费端，开始被处理时，打上时间戳。
端到端延迟 = T2 - T1。
嗯，这里要注意：T1 和 T2 必须使用同一台时钟源，或者至少保证时钟同步。否则你算出来的延迟可能是负数——我在项目里就踩过这个坑，两台机器的系统时间差了 10 秒，排查了半天才发现是 NTP 没配好。
3.2 采样 vs 全量
全量记录每条消息的延迟，对高吞吐系统来说成本太高。我建议的做法是：
- 全量统计 P50、P99：用 HdrHistogram 这类数据结构，可以在不记录每条数据的情况下，精确计算出百分位延迟。内存开销很小。
- 采样记录 P999：对于极端延迟，可以单独采样记录，方便事后排查。
小技巧：我曾经用 HdrHistogram 在每秒百万级消息的系统中做延迟统计，每个节点的额外开销不到 1MB 内存。强烈推荐。
3.3 代码示例：用 HdrHistogram 统计延迟
// 初始化 Histogram，记录 1ms 到 1s 的延迟，精度 3 位小数
Histogram histogram = new Histogram(1_000_000, 3);
// 每条消息处理完后，记录延迟
long latency = endTime - startTime;
histogram.recordValue(latency);
// 定期输出百分位延迟
System.out.println("P50: " + histogram.getValueAtPercentile(50) + "ms");
System.out.println("P99: " + histogram.getValueAtPercentile(99) + "ms");
System.out.println("P999: " + histogram.getValueAtPercentile(99.9) + "ms");这段代码很简单，但很实用。你可以在每个处理节点上都跑一个 Histogram，然后统一上报到监控系统。
四、端到端延迟的构成
为了更清楚地理解延迟从哪来，我画了一张图，把整个链路拆开来看。
从图上可以清楚看到，端到端延迟不是单一环节的延迟，而是多个环节的累加。每个环节都可能成为瓶颈。
避坑指南：我曾经遇到过一个案例，P999 延迟突然飙升到 2 秒，排查后发现是 Kafka 的消费者 rebalance 导致的。rebalance 期间消费者会暂停消费，所有消息都在队列里排队。所以，测量延迟时一定要把 rebalance、GC 暂停这类「隐形杀手」考虑进去。
五、测量延迟的常见误区
- 只测平均不测分位：平均延迟会掩盖长尾问题，必须看 P99 和 P999。
- 时钟不同步：T1 和 T2 来自不同机器，时间差会导致测量结果完全失真。
- 忽略采样偏差：如果只采样慢请求，统计结果会偏大。如果只采样快请求，结果会偏小。要保证采样随机性。
- 把处理延迟当成端到端延迟：处理延迟只是端到端延迟的一部分，别忘了网络和排队时间。
我的建议：在系统上线前，先跑一遍端到端的延迟压测，把 P50、P99、P999 都记录下来作为基线。上线后持续监控，一旦 P999 超过基线的 2 倍，立刻告警。这样能第一时间发现异常。
好了，关于延迟的度量就聊到这里。记住一句话：没有度量，就没有优化。先把延迟量准了，后面谈优化才有意义。
公众号:蓝海资料掘金营，微信deep3321