3. 低延迟服务基础
在实时特征 API 的工程实践中，“低延迟”并不是一个单一指标，而是一组彼此制约、需要同时权衡的性能维度。很多团队在压测时看到平均延迟只有 8ms 就认为系统达标，上线后却频繁收到用户投诉，原因往往在于忽略了尾延迟、吞吐上限以及并发模型对稳定性的影响。本节将把这些基础概念串成一条完整的认知链路，为后续的特征服务优化打下共同语言。
一、核心原理：延迟、吞吐与尾延迟的真实含义
延迟（Latency）指单个请求从发出到收到完整响应所经历的时间，通常以毫秒为单位。它包含网络传输、排队、计算、序列化等多个阶段。延迟是一个分布，而不是一个固定值，因此必须用分位数来描述。
吞吐（Throughput）指单位时间内系统能够成功处理的请求数量，常用 QPS（每秒查询数）或 RPS 衡量。吞吐与延迟并非线性关系：在低负载区，增加并发可以提升吞吐且延迟基本不变；当接近系统容量拐点时，吞吐增长放缓，延迟开始陡升；超过拐点后，吞吐反而下降，延迟急剧恶化。
P99 与 P999 是延迟分布中的高分位指标。P99 表示 99% 的请求延迟低于该值，P999 表示 99.9% 的请求延迟低于该值。对于实时特征 API，P999 往往比平均值更能反映用户体验，因为一次超时可能直接导致推荐结果降级或风控误判。平均值会被大量快速请求“拉低”，掩盖少数慢请求的真实影响。
二、SLA、SLO 与错误预算：把承诺变成可管理的指标
SLA（Service Level Agreement）是服务提供方与使用方之间的正式协议，通常包含可用性、延迟、赔偿条款等，具有法律或商业约束力。SLO（Service Level Objective）是团队内部设定的、用于支撑 SLA 的目标值，例如“P99 延迟小于 50ms，月度可用性不低于 99.95%”。SLO 比 SLA 更严格，为故障留出缓冲空间。
由 SLO 可以推导出错误预算（Error Budget）：如果 SLO 是 99.95% 可用，那么每月允许的不可用时间约为 21.6 分钟。错误预算把“稳定性”从口号变成可消耗的资源，帮助团队在发布速度与稳定性之间做出量化决策。
| 指标 | 典型目标示例 | 关注对象 | 常见误区 |
|---|---|---|---|
| 平均延迟 | < 10ms | 整体趋势 | 被快请求稀释，掩盖慢请求 |
| P99 延迟 | < 50ms | 大多数用户体验 | 采样窗口过短导致抖动 |
| P999 延迟 | < 120ms | 极端慢请求、超时风险 | 忽略 GC、锁竞争等长尾来源 |
| 吞吐 | ≥ 50k QPS | 容量规划 | 只看峰值，不看持续能力 |
| 可用性 | ≥ 99.95% | SLA 履约 | 与延迟指标割裂管理 |
三、并发模型：决定延迟与吞吐形态的底层结构
并发模型决定了请求如何被调度、线程如何被复用、资源如何被竞争。常见的模型包括：
- 同步阻塞模型：每个请求占用一个线程，实现简单，但线程数受限于内存与上下文切换成本，高并发下延迟抖动明显。
- 异步非阻塞模型：基于事件循环或 Reactor 模式，少量线程处理大量连接，吞吐高、资源利用率好，但编程复杂度高，阻塞调用会拖垮整个事件循环。
- 协程/虚拟线程模型：兼顾同步写法与高并发能力，适合 I/O 密集型的特征查询场景，但需注意调度器与底层库的兼容性。
选择并发模型时，必须结合特征 API 的访问模式：如果单次请求需要聚合多个远程特征源，I/O 等待占比高，异步或协程模型通常更优；如果计算密集且可并行拆分，则需关注 CPU 核数与线程池隔离。
四、案例与场景：一次特征 API 尾延迟排查
某推荐系统的实时特征 API 在压测中平均延迟 9ms、P99 为 45ms，看似达标。但线上灰度后，P999 达到 380ms，部分请求触发 200ms 超时降级。排查发现：
- 特征聚合层使用同步阻塞调用，线程池大小为 200，高峰期排队严重。
- 部分特征源响应时间波动大，个别请求等待超过 150ms，拖高尾延迟。
- JVM 每分钟发生一次约 60ms 的 GC 停顿，恰好落在 P999 区间。
优化措施包括：将远程特征查询改为异步并行聚合，设置单源超时与降级策略，调整线程池隔离，并优化对象分配减少 GC 频率。调整后 P999 降至 110ms，错误预算消耗显著下降。
# 压测命令示例：观察不同并发下的延迟分位
wrk -t8 -c400 -d60s --latency http://feature-api/predict
# 输出片段
Latency Distribution
50% 8.21ms
75% 12.40ms
90% 21.77ms
99% 48.63ms
99.9% 312.45ms
五、误区与复盘：低延迟服务常见的五个认知陷阱
- 只看平均值：平均值达标不代表用户体验达标，尾延迟才是投诉的主要来源。
- 把吞吐当唯一目标：盲目提高并发会越过容量拐点，导致延迟雪崩。
- SLO 形同虚设：没有错误预算和告警联动，SLO 只是一张纸。
- 并发模型与业务不匹配：I/O 密集场景用同步阻塞，线程池再大也会排队。
- 忽略外部依赖：特征源、缓存、数据库的尾延迟会直接传导到 API 层。