2. 低延迟因子评分概念
2.1 因子评分的业务场景
因子评分（Factor Scoring）是金融风控、实时推荐、广告竞价等场景中的核心计算模式。其本质是在毫秒级时间内，根据用户、环境、标的物的多维特征，通过预定义的因子逻辑或轻量模型，输出一个或多个评分值，用于决策引擎的后续判断。
典型业务场景包括：
- 实时信贷审批：用户提交申请后，系统在 200ms 内完成身份核验、多头借贷查询、收入稳定性评估等因子计算，输出信用评分。
- 反欺诈实时拦截：支付交易发生时，基于设备指纹、地理位置、行为序列等因子，在 50ms 内给出欺诈概率评分。
- 个性化推荐排序：内容流或商品列表页，对每个候选 item 计算点击率预估、转化率预估等因子评分，用于排序。
- 实时竞价（RTB）：广告请求到达时，DSP 需要在 100ms 内对流量价值进行评分，决定出价策略。
关键洞察： 因子评分与通用模型推理的区别在于——因子评分通常由数十到数百个独立或半独立的计算单元组成，每个单元称为一个"因子"（Factor），系统需要对这些因子进行编排、缓存、并行或串行计算，最终聚合为评分结果。这种"因子编排 + 轻量计算"的模式对延迟的敏感度远高于批量推理。
2.2 低延迟的定义与量化指标
在因子评分场景中，"低延迟"并非一个绝对数值，而是相对于业务容忍度的相对概念。通常以百分位延迟（Percentile Latency）作为核心量化指标。
| 指标 | 定义 | 典型目标值（因子评分） | 说明 |
|---|---|---|---|
| P50 延迟 | 50% 的请求在多少毫秒内完成 | < 20ms | 反映系统典型性能，用户体验的"中位数"感受 |
| P99 延迟 | 99% 的请求在多少毫秒内完成 | < 100ms | 反映尾部延迟，决定系统是否满足 SLA 承诺 |
| P999 延迟 | 99.9% 的请求在多少毫秒内完成 | < 300ms | 极端尾部延迟，通常由 GC、网络抖动、资源争抢导致 |
| 平均延迟 | 所有请求延迟的算术平均值 | < 15ms | 容易被极端值拉偏，不单独作为 SLA 指标 |
实践建议： 在因子评分系统中，P99 延迟比平均延迟更重要。一个平均延迟 10ms 但 P99 延迟 500ms 的系统，在 1% 的请求上会导致业务超时或降级，对高价值交易场景可能是灾难性的。
延迟的测量需要关注"端到端延迟"与"计算延迟"的区别：
- 端到端延迟：从客户端发起请求到收到完整响应的时间，包含网络传输、序列化/反序列化、排队等待、因子计算等所有环节。
- 计算延迟：仅指服务端从接收到请求到完成因子计算并准备返回结果的时间。
在优化实践中，通常优先优化计算延迟，因为网络和序列化部分受外部因素影响较大，且优化空间相对有限。
2.3 延迟对业务的影响
延迟对因子评分业务的影响是多维度的，不仅影响用户体验，更直接关联到业务收益和风险控制能力。以下从三个核心维度分析：
| 影响维度 | 延迟增加 100ms 的典型后果 | 量化参考 |
|---|---|---|
| 用户转化率 | 用户等待时间增加，流失率上升 | 每增加 100ms，转化率下降 1%~3%（Amazon 研究数据） |
| 风险控制时效 | 欺诈交易在评分完成前已通过，造成资金损失 | 延迟每增加 50ms，欺诈漏过率上升 0.5%~1.2% |
| 系统吞吐量 | 单请求处理时间变长，单位时间处理能力下降 | 延迟翻倍，吞吐量减半（在固定线程池模型下） |
| 计算资源成本 | 为满足 SLA 需要更多机器或更高配置 | P99 从 50ms 优化到 20ms，可节省 30%~50% 服务器成本 |
风险提示： 在金融风控场景中，延迟问题可能导致"评分超时降级"——当因子评分无法在指定时间内完成时，系统会使用默认评分或历史评分。这种降级策略如果设计不当，会直接导致风险敞口扩大。例如，某支付平台因 P99 延迟从 80ms 恶化到 250ms，导致 2.3% 的交易使用了降级评分，欺诈损失增加 4 倍。
延迟对业务的影响还体现在"非线性效应"上：
- 阈值效应：当延迟超过业务设定的超时阈值（如 200ms）时，系统会触发超时降级或熔断，业务影响呈指数级增长。
- 连锁效应：单个因子的延迟抖动可能阻塞整个评分链路的后续计算，导致多个因子同时超时。
- 规模效应：在高峰期，延迟的微小增加会通过排队论中的"排队效应"被放大，导致 P99 延迟急剧恶化。
2.4 延迟优化的核心目标
基于上述分析，因子评分系统的延迟优化目标可以归纳为：
- 降低 P50 延迟：提升大多数请求的响应速度，改善用户体验和系统吞吐量。
- 压缩 P99 延迟：消除尾部延迟抖动，确保 SLA 合规，避免超时降级。
- 控制 P999 延迟：通过容错设计（超时、重试、降级）将极端延迟的影响降到最低。
- 保持延迟稳定性：在流量波动、数据倾斜、资源争抢等场景下，延迟的方差应尽可能小。
优化原则： "先测量，后优化；先架构，后代码；先缓存，后计算。" 在因子评分系统中，80% 的延迟问题可以通过合理的架构设计（因子编排、缓存策略、并行计算）解决，只有 20% 需要深入到代码级优化（JVM 调优、SIMD 指令、内存布局）。