3. 需求分析：延迟要求（P99 < 50ms）、吞吐量（QPS）、可用性（99.99%）与数据一致性权衡

在欺诈评分API的设计初期，延迟、吞吐量、可用性与数据一致性构成了四个核心约束维度。它们相互制约，必须在架构层面做出明确权衡。本章将逐一拆解这些指标的技术含义，并给出可落地的量化决策依据。

3.1 延迟要求：P99 < 50ms

欺诈评分是典型的在线推理场景，用户等待时间直接影响转化率和用户体验。我们采用P99（第99百分位延迟）作为核心度量，而非平均值。

实现 P99 < 50ms 的技术手段包括：

• 特征预计算：将离线特征（如历史交易频次、设备指纹）提前写入 Redis/Tair，避免在线 Join。
• 模型轻量化：使用 ONNX Runtime 或 TensorRT 部署，避免 Python 原生推理的 GIL 瓶颈。
• 连接池与多路复用：gRPC 长连接 + HTTP/2 多路复用，减少 TCP 握手开销。
• 缓存策略：对重复查询（如同一设备号、同一 IP）设置本地 LRU 缓存，命中率目标 > 30%。

3.2 吞吐量（QPS）与容量规划

吞吐量需求通常由业务峰值流量决定。我们以每秒查询数（QPS）为计量单位，并考虑突发因子。

3.3 可用性：99.99% 的工程含义

99.99% 可用性意味着全年不可用时间不超过 52.56 分钟。对于欺诈评分API，这要求架构具备多活或主备自动切换能力。

• 计算层：无状态服务，通过 K8s HPA 自动扩缩容，Pod 分布在不同可用区。
• 缓存层：Redis 集群采用哨兵或 Redis Enterprise 的跨机房复制，RTO < 10s。
• 模型层：模型文件存储在对象存储（如 S3/MinIO），本地挂载只读副本，避免单点故障。
• 网关层：多入口 DNS 轮询 + 健康检查，故障时自动摘除节点。

3.4 数据一致性权衡：最终一致性 vs 强一致性

欺诈评分场景对一致性的要求是分层的。并非所有数据都需要强一致性，盲目追求强一致性会严重拖累延迟和可用性。

在架构层面，我们采用CQRS（命令查询职责分离）模式：写入路径走强一致存储，读取路径走最终一致缓存。评分请求优先读取缓存，缓存未命中时回源到强一致存储，并异步回填缓存。

3.5 四维权衡决策矩阵

将上述四个维度整合为一张决策矩阵，帮助架构师在具体场景中快速选择折中方案。

3.6 需求文档输出清单

完成上述分析后，需输出以下可量化的需求条目，作为后续架构设计的输入：

1. 延迟 SLO：P99 < 50ms，P50 < 15ms，超时阈值设为 100ms（含重试）。
2. 吞吐量目标：稳态 QPS = 业务峰值 × 1.5 冗余，单实例安全 QPS 通过压测确定。
3. 可用性目标：全年 99.99%，允许每月不超过 4.38 分钟不可用。
4. 一致性等级：在线特征最终一致（秒级），黑/白名单强一致（线性一致性），日志最终一致（可丢失）。
5. 降级策略：当依赖服务（如 Redis、模型推理）不可用时，返回默认风险分（如 0.5）并异步告警。