两个网关副本的P95能直接平均吗：用合成分布核对全站延迟

两个副本的P95分别是十毫秒和一千毫秒，全站P95不是它们的平均五百零五毫秒。分位数描述排序位置，丢掉原始分布后通常无法再合并。本文用样本量悬殊的合成延迟，分别计算离散精确分位与经典直方图近似，不使用真实用户耗时。

先固定离散分位数的秩规则

副本a有一百个十毫秒样本，副本b有十个一千毫秒样本。本文排序后取向上取整的百分之九十五秩：a的P95十，b的一千；直接平均得到五百零五。合并后一共一百一十项，秩为第一百零五项，落在慢样本区，所以精确全站P95是一千。

即使按样本量加权平均两个P95，也不能恢复全站排序位置。每个副本只留下一个分位数字，内部哪些样本接近边界已经丢失。Prometheus官方文档因此区分预计算分位和可聚合分布。展示各副本P95可以定位异常节点，但不能把它们取平均后贴上“全站P95”的标签。

直方图先合桶，再估计分位

附件有限桶边界为十、一百、五百、一千毫秒，各桶使用累计计数，并补正无穷桶。合并后在五百毫秒处累计一百，一千处累计一百一十。百分之九十五目标数量为一百零四点五，在五百到一千桶内按线性假设估计，得到七百二十五毫秒。它与原始精确秩一千不同，是桶内分布未知造成的近似。

不能看到七百二十五就声称有真实请求耗时正好等于这个数。更细桶可能降低部分误差，但也增加指标成本；应围绕需要判断的阈值设计。没有匹配边界、单位和时间窗的分布不能直接求和。混入累计计数与非累计频数，也会得到看似可计算却没有明确意义的结果。

查询时保留桶标签和共同时间窗

经典直方图查询形态可使用下式，实际指标名按部署替换：

histogram_quantile(0.95,
  sum by (le) (rate(gateway_request_duration_seconds_bucket[5m]))
)

示例指标单位为秒，附件样本单位为毫秒，适配时要转换，不能把两个数直接对照。应先对每条计数序列计算rate，再按le合并；保留业务域标签时也要明确聚合范围。不同副本桶配置、不同观测窗口或缺少正无穷桶，都应先报口径错误。本批只运行离线分位与插值计算，没有启动Prometheus或执行这条查询。验收交付的是可重算反例和桶表，不能把参考七百二十五写成生产延迟实测。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C027。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c027-replica-latency.json、c027-bucket-counts.csv。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文提醒监控P95/P99而非平均延迟；本文解决多副本如何聚合分位数的数学与指标口径，既不重写监控安装，也不把原始样本分位与桶内插值混为一谈。