3、解析回放机制：什么是解析回放、回放日志的采集与存储、回放触发条件
解析回放机制是金融实体解析质量保障体系的核心环节。它通过记录生产环境中的每一次解析请求与响应，形成可追溯的回放日志，并在特定条件下重新执行这些日志，以验证解析逻辑的正确性与一致性。本节将系统阐述解析回放的定义、日志采集与存储方案，以及触发回放的条件。
3.1 什么是解析回放
解析回放（Resolution Replay）是指将金融实体解析系统在生产环境中处理过的原始请求数据（包括输入参数、上下文信息、时间戳等）完整记录下来，并在测试或验证环境中按照相同的顺序和时间间隔重新发送给解析引擎，从而对比两次解析结果是否一致的过程。
其核心价值在于：
- 回归验证：当解析规则、数据源或算法发生变更时，通过回放确保历史请求仍能获得正确结果。
- 差异发现：精准定位因版本升级、数据漂移或配置修改导致的解析偏差。
- 审计追溯：为监管合规提供完整的解析过程证据链。
关键概念：解析回放 ≠ 压力测试。压力测试关注系统吞吐能力，而解析回放关注结果一致性与逻辑正确性。
金融场景示例：某支付机构升级了商户识别规则，通过回放过去30天的交易解析日志，发现3%的跨境交易因国家代码映射变更导致解析结果不同，及时修正了规则。
3.2 回放日志的采集与存储
回放日志的采集需要覆盖解析全链路的关键数据点，确保回放时能够完全复现原始环境。采集与存储架构如下图所示：
回放日志的采集内容必须包含以下字段，以确保回放的完整性与准确性：
| 字段类别 | 字段名称 | 说明 | 是否必填 |
|---|---|---|---|
| 请求标识 | request_id | 全局唯一请求ID，用于关联请求与响应 | 是 |
| 时间戳 | timestamp | 请求到达时间，精确到毫秒 | 是 |
| 输入参数 | input_params | 原始请求的JSON序列化数据 | 是 |
| 上下文信息 | context | 用户ID、渠道、环境标识等 | 否 |
| 解析结果 | response | 原始响应结果JSON | 是 |
| 版本号 | version | 解析引擎版本号 | 是 |
| 规则快照 | rule_snapshot | 当前生效的规则集哈希值 | 否 |
存储注意事项：回放日志数据量巨大（日均可达数亿条），必须设置合理的生命周期管理策略。建议热数据保留7天，温数据保留30天，冷数据归档至低成本存储至少保留180天以满足监管要求。
3.3 回放触发条件
解析回放的触发并非无差别执行，而是基于明确的业务与技术条件。合理的触发策略既能保障质量，又能避免资源浪费。回放触发条件分为以下三类：
各类触发条件的具体执行策略如下：
| 触发类型 | 触发时机 | 回放范围 | 执行频率 | 典型场景 |
|---|---|---|---|---|
| 定时触发 | 每日 02:00-05:00 | 前一日全量日志的 10% 抽样 | 每日 | 常规质量巡检 |
| 事件触发 | 规则/配置变更后 5 分钟 | 受影响实体类型的全量日志 | 按需 | 规则上线验证 |
| 异常触发 | 告警产生后立即执行 | 异常实体关联的最近 1 小时日志 | 即时 | 故障排查定位 |
最佳实践：建议在事件触发回放时，同时执行增量回放（仅回放变更影响范围内的日志）与全量回放（回放最近7天所有日志），前者快速验证，后者兜底发现潜在影响。
3.4 回放流程与结果对比
一次完整的解析回放流程包含以下步骤：
- 触发判定：根据定时/事件/异常条件判断是否需要启动回放。
- 日志加载：从存储层读取符合条件的回放日志，按时间顺序排列。
- 环境准备：在隔离的测试环境中部署当前版本的解析引擎。
- 请求重放：按照原始时间间隔（或加速模式）依次发送请求。
- 结果采集：记录每次重放后的解析结果。
- 差异对比：将新结果与原始结果进行逐字段比对。
- 报告生成：输出差异报告，标注不一致的字段与比例。
差异对比规则：对于数值型字段，允许 ±0.01% 的浮点误差；对于枚举型字段，必须完全一致；对于文本型字段，采用编辑距离算法，相似度低于 95% 即标记为差异。
通过上述机制，解析回放能够为金融实体解析系统提供持续的质量保障，确保每一次规则变更、版本升级或数据调整都不会对生产环境造成预期之外的解析偏差。