2. 低延迟基础概念：延迟与吞吐量的区别、P99/P999延迟指标、延迟的构成

在构建低延迟评分通道之前，必须精确理解几个核心度量指标。很多团队在优化初期混淆了“快”与“多”的关系，导致架构选型方向错误。本节从三个维度建立基础认知：延迟与吞吐量的本质区别、百分位延迟的工程含义、以及延迟的物理构成。

2.1 延迟与吞吐量的区别

延迟（Latency） 衡量单个请求从发出到收到完整响应所经过的时间，单位通常是毫秒（ms）或微秒（μs）。吞吐量（Throughput） 衡量系统在单位时间内能处理的请求总数，单位是每秒请求数（QPS）或每秒事务数（TPS）。

两者并非线性关系。当系统接近吞吐量上限时，延迟会急剧上升——这就是著名的“延迟悬崖”现象。低延迟架构的核心目标之一，就是在高吞吐下仍保持低延迟。

2.2 P99/P999 延迟指标

平均值（Avg）会掩盖尾部延迟问题。一个系统平均延迟 10ms，但可能有 5% 的请求延迟超过 200ms。在评分通道中，这 5% 的慢请求可能导致用户扣款失败、风控超时等严重事故。

百分位延迟 是低延迟系统的核心度量：

• P50（中位数）：50% 的请求快于该值，反映典型体验。
• P99：99% 的请求快于该值，即最慢的 1% 请求的边界。
• P999：99.9% 的请求快于该值，即最慢的 0.1% 请求的边界。
• P9999：99.99% 的请求快于该值，通常用于核心金融通道。

下图展示了典型延迟分布曲线，帮助理解尾部延迟的含义：

2.3 延迟的构成：网络、计算、IO

一次评分请求的总延迟可以分解为三个主要部分。只有精确分解，才能找到真正的优化点。

2.3.1 网络延迟

数据在客户端与服务端之间传输所花费的时间。包括：

• 传播延迟：光速/电信号在物理介质中的传输时间，受距离限制（例如：北京到上海约 10ms RTT）。
• 传输延迟：数据包大小除以带宽，例如 1KB 数据在 1Gbps 链路上约 8μs。
• 处理延迟：路由器、交换机、负载均衡器的转发与排队时间。
• 排队延迟：数据包在中间设备队列中等待的时间，是网络延迟中最不可控的部分。

2.3.2 计算延迟

CPU 执行评分逻辑、规则引擎、模型推理等操作所消耗的时间。关键因素：

• CPU 指令执行：分支预测失败、缓存未命中会显著增加延迟。
• 上下文切换：线程切换导致 TLB 刷新、缓存污染。
• 锁竞争：多线程争用同一资源时的等待时间。
• GC 暂停：Java/Go 等语言中垃圾回收导致的 STW（Stop-The-World）。

2.3.3 IO 延迟

数据从磁盘、内存、网络接口等外设读取或写入的等待时间。包括：

• 磁盘 IO：SSD 随机读约 50~100μs，HDD 约 5~10ms。
• 网络 IO：远程 RPC 调用、数据库查询的网络往返。
• 内存 IO：DRAM 访问约 100ns，但 NUMA 跨节点访问可能增加 2~3 倍。

下图展示了评分请求的延迟分解结构：

2.4 延迟分解实战：一个评分请求的旅程

假设一次用户评分请求从客户端发出到返回结果，总延迟为 85ms。通过埋点可以分解如下：

总延迟: 85ms
├── 网络延迟 (客户端 → 负载均衡): 8ms
│   ├── 传播延迟: 5ms (跨城)
│   ├── 排队延迟: 2ms
│   └── 传输延迟: 1ms
├── 负载均衡处理: 1ms
├── 网络延迟 (负载均衡 → 应用服务器): 2ms
├── 应用服务器计算: 12ms
│   ├── 请求反序列化: 1ms
│   ├── 规则引擎执行: 6ms
│   ├── 模型推理: 4ms
│   └── 响应序列化: 1ms
├── 网络延迟 (应用服务器 → 缓存): 1ms
├── 缓存查询 (Redis): 2ms
├── 网络延迟 (应用服务器 → 数据库): 3ms
├── 数据库查询 (MySQL): 15ms
├── 网络延迟 (数据库 → 应用服务器): 3ms
├── 应用服务器后处理: 8ms
│   ├── 数据聚合: 3ms
│   ├── 异步日志写入: 4ms (非阻塞)
│   └── 响应编码: 1ms
├── 网络延迟 (应用服务器 → 负载均衡): 2ms
├── 负载均衡转发: 1ms
└── 网络延迟 (负载均衡 → 客户端): 7ms

2.5 延迟度量工具与最佳实践