3. 数据模型设计：反欺诈API请求与响应数据结构设计，如何最小化传输数据量以降低延迟

在反欺诈低延迟API中，数据模型直接决定了网络传输耗时与序列化/反序列化开销。每多传输1KB无效数据，在百万级QPS下将导致数十毫秒的额外延迟累积。本章聚焦于如何通过极简的请求与响应结构设计，在保证业务语义完整的前提下，将传输数据量压缩至最低。

3.1 请求数据结构设计原则

反欺诈API的请求数据应遵循“按需索取、最小必要”原则。客户端只应发送服务端无法推导或无法从上下文获取的字段。

3.2 响应数据结构设计策略

响应数据应聚焦于“决策结果”与“必要上下文”，避免返回冗余的规则命中详情或全量特征数据。

• 结果优先： 顶层字段直接返回决策结果（pass/review/block），客户端无需解析嵌套结构即可快速响应。
• 按需扩展： 使用可选的 ext_info 字段承载额外信息（如风险等级、建议动作），仅在需要时填充。
• 状态码与消息分离： 使用整型 code 表示业务状态，message 仅在有异常时提供可读描述。
• 避免列表全量返回： 若需返回命中规则列表，使用位掩码（bitmask）替代字符串数组，将多个规则状态压缩至一个整型字段。

// 优化前：响应体约 1.2KB
{
  "status": "block",
  "risk_score": 0.87,
  "hit_rules": ["rule_1001", "rule_2034", "rule_4012"],
  "rule_details": [
    {"id": "rule_1001", "name": "异地登录", "weight": 0.5},
    {"id": "rule_2034", "name": "大额交易", "weight": 0.3},
    {"id": "rule_4012", "name": "设备异常", "weight": 0.2}
  ],
  "suggested_action": "manual_review"
}

// 优化后：响应体约 180 字节
{
  "code": 2,          // 0=pass, 1=review, 2=block
  "risk": 87,         // 风险分 0-100
  "mask": 0b1011,     // 位掩码：规则命中状态
  "ext": "manual"     // 可选建议动作
}

3.3 序列化协议选择与压缩

序列化协议的选择对传输延迟有直接影响。在反欺诈场景中，推荐优先使用 Protobuf 或 MessagePack 替代标准JSON。

3.4 数据模型压缩的端到端流程

下图展示了从客户端请求到服务端响应的完整数据流，以及每个环节的压缩策略。

3.5 字段级优化清单

以下清单总结了反欺诈API中常见字段的优化方式，可直接用于数据模型评审。

• 用户标识： 使用整型 user_id（4字节）替代字符串（平均36字节），节省89%空间。
• 时间戳： 使用Unix毫秒级整型（8字节）替代ISO 8601字符串（24字节），节省67%空间。
• IP地址： 使用整型（4字节）或二进制（16字节 for IPv6）替代字符串（15~39字节）。
• 设备指纹： 使用哈希后的固定长度字符串（32字节）替代原始设备信息JSON（200+字节）。
• 金额： 使用分单位整型（8字节）替代浮点数字符串（平均12字节），同时避免精度问题。
• 操作类型： 使用枚举整型（1~2字节）替代操作名称字符串（10~30字节）。
• 地理位置： 使用GeoHash前缀（6字符）替代经纬度对（平均30字符），节省80%空间。

3.6 压缩效果量化对比

基于实际生产环境压测数据，以下表格展示了不同优化策略下的传输延迟对比（100万次请求，P99延迟）。