风控特征缓存怎么做才不拖主链路热点特征、批量查询、失效与一致性取舍这篇直接按风控特征缓存来拆不只讲“Redis 缓一下”而是把缓存分层、失效、一致性和降级边界讲清楚。目标是你看完后能把风控缓存从一层 Redis升级成真正服务主链路的缓存体系。个人主页GitHub主页文章目录风控特征缓存怎么做才不拖主链路热点特征、批量查询、失效与一致性取舍先看真实问题这块能力到底是为了解决什么放到真实风控链路里它通常长什么样举个具体例子放到项目里会怎么跑代码示例批量读取特征缓存并回源核心数据和配置建议怎么落系统设计时我会优先拆哪几层本地短缓存分布式缓存层回源服务层失效和刷新层真正上线时最容易卡住的点监控和指标建议盯哪些高频坑位复盘1. 把所有特征都长期缓存2. 缓存 miss 就直接串行回源如果面试官问我这块怎么设计我会这样答结语先看真实问题这块能力到底是为了解决什么风控特征查询往往在 RT 主链路上如果缓存设计不好不是查太慢就是查错数据。热点特征重复查询会拖慢主链路实时特征和离线特征更新频率完全不同缓存一旦失效或回源异常可能导致规则大面积裸奔所以特征缓存真正要解决的是哪些值缓存、缓存多久、如何批量取、更新后怎么失效、失败时怎么兜底。放到真实风控链路里它通常长什么样同一次决策里多条规则会反复读同一特征某些用户和设备在活动期会成为热点主体部分离线画像通过服务接口回源成本高于 Redis规则平台先列出本次依赖的特征缓存层按本地缓存 - Redis - 回源服务逐级获取获取成功后统一写入上下文回源或更新事件驱动缓存刷新举个具体例子放到项目里会怎么跑比如一次支付风控要同时查账号近 1 小时支付次数、设备近 1 天拒绝次数、IP 近 10 分钟请求数如果每个特征都实时查库主链路 RT 很快就炸了。先把高频热点特征放在 Redis 里统一按 scene entity featureCode 做 key。请求进来后先批量 mget未命中的再异步回源。回源成功后要带过期时间写回缓存避免脏数据长期存在。如果缓存雪崩要允许部分非关键特征降级。代码示例批量读取特征缓存并回源publicMapString,FeatureValueloadFeatures(StringentityId,ListStringcodes){ListStringkeyscodes.stream().map(code-risk:feature:entityId:code).toList();ListFeatureValuecachedredisTemplate.opsForValue().multiGet(keys);MapString,FeatureValueresultnewHashMap();ListStringmissCodesnewArrayList();for(inti0;icodes.size();i){FeatureValuevaluecached.get(i);if(valuenull)missCodes.add(codes.get(i));elseresult.put(codes.get(i),value);}result.putAll(featureStore.batchLoad(entityId,missCodes));returnresult;}核心数据和配置建议怎么落建议区分实时计数缓存、离线画像缓存、规则内临时缓存缓存记录要保留特征版本和更新时间热点缓存最好支持批量查询和批量填充系统设计时我会优先拆哪几层本地短缓存适合几十毫秒到几百毫秒的热点抖动消峰不能缓存过久避免错误放大分布式缓存层承接大部分实时和准实时特征查询支持批量读取和 pipeline回源服务层离线画像或大对象特征通过服务化接口回源回源要限流和超时控制失效和刷新层实时事件触发主动刷新或淘汰离线画像按版本和更新时间刷新真正上线时最容易卡住的点缓存策略先按特征类型分类不要所有特征共用 TTL回源服务一定要做超时和降级重点验证热点 Key 场景和批量查询效果监控和指标建议盯哪些本地缓存命中率、Redis 命中率、回源率回源接口 RT、失败率热点 Key 数量、缓存击穿次数默认值兜底命中率高频坑位复盘1. 把所有特征都长期缓存实时值很容易过期或不准不同特征必须按时效分层2. 缓存 miss 就直接串行回源主链路 RT 会明显拉长回源要批量、并发、可降级如果面试官问我这块怎么设计我会这样答如果面试官问风控特征缓存怎么设计我会先按实时、准实时、离线特征分层再讲本地缓存、Redis、回源服务三级结构最后补充失效刷新和兜底策略。因为风控缓存最怕的不是没命中而是错把不该缓存太久的数据当成稳定值。结语风控缓存的关键不是“有没有缓存”而是“缓存的值是否适合缓存、是否批量可取、失效后是否有兜底”。想继续看哪块评论区留个 1 或 2 就行1 热点 Key 治理2 回源服务降级