4. 特征缓存策略设计：本地缓存、分布式缓存（Redis）在特征服务中的应用与成本节省测算

在信用评分特征服务中，缓存是降低计算成本、减少数据库压力的核心手段。合理的缓存策略能够将高频重复的特征计算请求拦截在内存层，避免每次请求都触发昂贵的特征工程计算或数据库查询。本章将系统讲解本地缓存与分布式缓存（Redis）的应用场景、架构设计及成本节省测算方法。

4.1 缓存策略的核心目标与成本逻辑

特征服务的成本主要由三部分构成：计算资源（CPU/内存）、存储I/O（数据库查询）和网络带宽。缓存策略通过“空间换时间”的方式，用少量内存开销换取大幅降低的计算与I/O成本。

4.2 本地缓存（进程内缓存）

本地缓存将数据存储在应用进程的内存空间中，适用于单机部署或无状态服务场景。常见实现包括 Guava Cache、Caffeine、Ehcache 等。

4.2.1 适用场景

• 静态特征：用户基础画像（年龄、性别、学历）等几乎不变的数据。
• 短时间窗口聚合特征：如“近1小时交易次数”，在窗口内可复用。
• 模型参数/规则配置：评分卡权重、决策树节点等不频繁更新的元数据。

4.2.2 成本节省测算模型

假设特征服务每秒处理 1000 次请求，每次特征计算消耗 0.01 元（CPU+数据库）。本地缓存命中率 80%，则：

• 无缓存日成本：1000 × 0.01 × 86400 = 864,000 元/天
• 有缓存日成本：1000 × 0.01 × 86400 × (1 – 0.8) = 172,800 元/天
• 日节省：691,200 元

4.2.3 本地缓存代码示例（Caffeine）

// 构建本地缓存，最大容量10万，过期时间5分钟
Cache<String, FeatureResult> localCache = Caffeine.newBuilder()
    .maximumSize(100_000)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .recordStats()  // 开启命中率统计
    .build();

// 查询缓存，若未命中则执行特征计算
FeatureResult result = localCache.get(userId, key -> {
    return computeExpensiveFeature(userId);
});

// 输出命中率监控
System.out.println(localCache.stats().hitRate());

4.3 分布式缓存（Redis）

当特征服务需要多节点共享缓存数据，或需要跨服务复用特征结果时，必须引入分布式缓存。Redis 是目前最主流的方案，支持丰富的数据结构和持久化选项。

4.3.1 适用场景

• 跨服务共享特征：风控系统、推荐系统、客服系统共用同一份用户特征。
• 全局黑/白名单：需要实时同步到所有服务节点。
• 高频写入+低频读取：如实时更新的设备指纹特征。
• 特征结果聚合：多个特征服务节点写入，统一缓存供下游消费。

4.3.2 成本节省测算模型

Redis 集群成本包括内存占用和节点费用。假设部署 3 节点 Redis 集群（每节点 32GB 内存），月费用约 3000 元。若该集群支撑了日均 1 亿次特征查询，命中率 90%，则：

• 无缓存月计算成本：1亿 × 0.01 × 30 = 3,000,000 元
• 有缓存月计算成本：1亿 × 0.01 × 30 × (1 – 0.9) = 300,000 元
• Redis 集群月成本：3,000 元
• 月净节省：2,697,000 元

4.3.3 Redis 缓存代码示例（Jedis）

// 连接Redis集群
JedisCluster jedis = new JedisCluster(new HostAndPort("redis-node1", 6379));

// 设置特征缓存，过期时间300秒
String key = "feature:user:" + userId;
String value = computeFeature(userId);
jedis.setex(key, 300, value);

// 查询缓存
String cached = jedis.get(key);
if (cached != null) {
    return parseFeature(cached);
} else {
    // 重新计算并回填
    String freshValue = computeFeature(userId);
    jedis.setex(key, 300, freshValue);
    return freshValue;
}

4.4 本地缓存 vs 分布式缓存：选型对比

4.5 缓存策略架构设计

推荐采用两级缓存架构：本地缓存作为 L1 层，Redis 作为 L2 层。请求先查询本地缓存，未命中时查询 Redis，仍未命中才执行完整特征计算，并将结果回填两级缓存。

4.6 缓存策略成本节省测算总表

以下为某金融科技公司实际生产环境的缓存策略成本测算数据（日均请求量 5000 万次）：

4.7 缓存策略避坑指南

• 缓存穿透：大量请求查询不存在的数据，导致缓存永远不命中，直接打到数据库。解决方案：布隆过滤器或缓存空值（设置短 TTL）。
• 缓存雪崩：大量缓存同时过期，导致瞬时请求全部落到数据库。解决方案：TTL 增加随机偏移量，或使用本地缓存兜底。
• 缓存击穿：热点 key 过期瞬间，高并发请求直接穿透。解决方案：互斥锁（Mutex）或永不过期+异步刷新。
• 内存浪费：缓存了低频访问的大对象。解决方案：按特征访问频率排序，只缓存 Top 20% 的特征（二八原则）。

4.8 缓存策略实施步骤

1. 特征分级：按访问频率、数据稳定性、计算成本将特征分为 S/A/B/C 四级。
2. 容量规划：根据 S+A 级特征的总数据量估算缓存内存需求，预留 20% 余量。
3. 本地缓存先行：先部署 Caffeine 本地缓存，监控命中率至少 1 周。
4. 引入 Redis：当本地缓存命中率低于 80% 或需要跨服务共享时，部署 Redis 集群。
5. 持续调优：每周分析缓存命中率、内存利用率、成本节省曲线，动态调整 TTL 和最大条目数。