1. 课程导入
在金融推理系统中，模型效果不仅取决于算法本身，更取决于输入特征是否及时、准确、可复现。无论是实时反欺诈、信用评分、量化交易信号，还是智能投顾中的风险偏好判断，推理服务往往需要在毫秒级内读取大量特征。如果特征缓存与底层数据源之间出现不一致，模型可能基于过期余额、错误持仓或滞后行情做出判断，直接带来资金损失与合规风险。因此，特征缓存与数据一致性不是单纯的工程优化问题，而是金融推理系统能否可信运行的核心前提。
本课程围绕一条主线展开：让缓存中的特征在正确的时间、以正确的版本、被正确的推理请求使用。我们既关注性能，也关注一致性、可观测性与故障恢复。
一、核心原理：缓存加速与一致性约束的张力
特征缓存的基本原理，是把高频访问的特征值从慢速存储（如关系库、特征仓库、消息回填链路）复制到内存或近端存储中，从而降低推理延迟。但缓存一旦引入副本，就产生了“何时更新、以谁为准、读到旧值怎么办”的问题。金融场景对一致性的要求通常高于普通推荐系统，原因在于：
- 资金相关：账户余额、可用额度、持仓数量等特征若滞后，可能触发超额交易或错误授信。
- 时效敏感：行情、汇率、反欺诈名单更新频繁，秒级延迟都可能改变推理结论。
- 合规可审计：监管要求能够追溯某次推理使用了哪个版本的特征，缓存不能成为“黑盒”。
- 多源异构：特征可能来自交易库、行情总线、用户画像、第三方征信，更新节奏和一致性模型各不相同。
常见的一致性策略包括：旁路缓存（读时回填、写时失效）、写穿/写回、基于变更数据捕获的增量刷新、版本号或时间戳校验，以及短TTL加主动失效。选择哪种策略，取决于特征类型：余额类通常要求强一致或近强一致；画像类可接受分钟级最终一致；行情类则更强调低延迟与顺序性。
二、方法流程：从特征产生到推理消费的闭环
要保证一致性，不能只盯着缓存组件本身，而要把“特征产生—同步—缓存—消费—校验”看作闭环。一个可落地的流程通常包含以下步骤：
- 特征分级：按一致性要求将特征分为强一致、近实时、最终一致三类，并标注可容忍延迟与回源成本。
- 变更捕获：通过CDC、消息队列或定时任务捕获源数据变更，生成带版本号或事件时间的特征更新事件。
- 缓存写入与失效：根据分级选择写穿、写回或失效策略，避免“先删缓存再写库”引发的并发脏读。
- 推理读取：推理服务读取缓存时携带特征版本或时间戳，必要时触发回源校验。
- 一致性监控：对缓存命中率、回源率、版本偏差、过期告警进行持续观测，并保留审计日志。
一个实用原则：强一致特征不走普通缓存，或只走带版本校验的短TTL缓存；最终一致特征才适合大范围缓存加速。把一致性要求写进特征元数据，比事后排障更有效。
三、案例/场景：反欺诈推理中的缓存不一致
假设某支付反欺诈服务需要读取“近1小时交易次数”和“账户可用余额”两个特征。前者来自流式计算，允许秒级延迟；后者来自核心交易库，要求强一致。若两者都放入同一个TTL为5分钟的缓存，可能出现如下日志：
2025-03-18 10:22:31 INFO inference request_id=req_8842
feature=tx_count_1h value=3 version=ts_102230
feature=available_balance value=1200.00 version=ts_102015
model_score=0.12 decision=pass
2025-03-18 10:22:33 WARN consistency_check
available_balance actual=200.00 source_version=ts_102233
cache_version=ts_102015 stale_ms=138000
该请求基于13.8秒前的余额做出“通过”决策，而实际余额已不足以覆盖交易。若这是授信或支付场景，就会形成风险敞口。改进方式包括：对余额特征启用写穿加版本校验；在推理前对强一致特征执行轻量回源；或将余额判断下沉到交易核心的实时校验接口，缓存只用于非资金类特征。
| 特征类型 | 一致性要求 | 推荐缓存策略 | 典型风险 |
|---|---|---|---|
| 账户余额 | 强一致 | 写穿 + 版本校验，短TTL | 超额交易、错误授信 |
| 近1小时交易次数 | 近实时 | CDC增量刷新，TTL 10~30秒 | 欺诈漏判 |
| 用户画像标签 | 最终一致 | 旁路缓存，TTL分钟级 | 推荐偏差 |
| 行情价格 | 顺序一致 | 消息总线 + 本地缓存 | 错误报价、套利风险 |
四、误区与复盘：常见错误与学习路线图
初学者常陷入几个误区：一是把缓存命中率当作唯一指标，忽略版本偏差；二是所有特征统一TTL，导致强一致特征被“平均化”处理；三是只做失效不做校验，在并发写场景下仍可能读到旧值；四是缺少审计日志，出问题后无法复现某次推理的特征版本。复盘时应重点回答：这次推理用了哪个版本？缓存为何未更新？回源是否成功？告警是否及时？
金融推理系统的一致性故障往往不是“缓存挂了”，而是“缓存看起来正常，但版本已经落后”。因此，监控必须同时覆盖可用性与正确性。
本课程后续将沿着“特征分级—缓存策略—一致性校验—故障演练—性能调优”的路线展开。你将逐步掌握如何为不同金融特征设计缓存方案，如何用版本号、事件时间和审计日志构建可追溯链路，以及如何在延迟与一致性之间做出可解释的工程取舍。完成本课程后，你应能独立设计一套既快又可信的金融推理特征缓存体系，并在真实故障场景中快速定位与恢复。