4. 实时特征存储选型：Redis、HBase、TiKV的对比、特征存储的TTL策略、高并发读写下的性能优化
实时风控模型依赖毫秒级特征访问。特征存储层选型直接决定训练集构建的时效性与稳定性。本章从存储引擎对比、TTL策略、高并发优化三个维度展开，帮助你在不同业务规模下做出合理决策。
4.1 三大实时特征存储引擎对比
当前业界主流实时特征存储方案为 Redis、HBase 和 TiKV。三者在数据模型、一致性、扩展性上存在本质差异，适用于不同风控场景。
| 对比维度 | Redis | HBase | TiKV |
|---|---|---|---|
| 数据模型 | Key-Value / 多种数据结构 | 宽表（RowKey + 列族 + 时间戳） | 分布式 Key-Value（支持事务） |
| 一致性 | 最终一致（集群模式） | 强一致（单行） | 强一致（Raft） |
| 扩展性 | 主从 / 集群（分片） | 原生水平扩展（Region） | 原生水平扩展（Region + Raft Group） |
| 读写延迟 | < 1ms（内存） | 5-20ms（HDFS + 内存缓存） | 1-5ms（RocksDB + Raft） |
| TTL 支持 | 原生（EXPIRE / TTL） | 原生（列族 TTL） | 需应用层或 TiKV 4.0+ TTL 特性 |
| 适用场景 | 高频简单特征、计数器、布隆过滤器 | 海量历史特征、用户画像宽表 | 强一致要求、跨行事务、混合负载 |
选型建议： 若特征维度少且 QPS 极高（>10w/s），优先 Redis；若特征维度多且需存储大量历史行为，选 HBase；若业务要求跨特征强一致且未来扩展性要求高，选 TiKV。
4.2 特征存储的 TTL 策略
实时风控特征具有强时效性。过期的特征不仅占用存储资源，还会导致模型推理偏差。TTL（Time-To-Live）策略是特征存储设计的核心环节。
4.2.1 TTL 设置原则
- 短期特征（秒级）： 如设备指纹、IP 频次、验证码状态，TTL 设为 30s-300s。
- 中期特征（分钟级）： 如登录失败次数、交易频次，TTL 设为 10min-60min。
- 长期特征（天级）： 如用户画像标签、历史逾期标记，TTL 设为 7d-30d。
- 永久特征： 黑名单、白名单、设备指纹库，不设 TTL 或设为极大值。
4.2.2 各引擎 TTL 实现方式
| 引擎 | TTL 实现机制 | 精度 | 注意事项 |
|---|---|---|---|
| Redis | EXPIRE / PEXPIRE / 主动过期 + 惰性删除 | 毫秒级 | 大量同时过期可能导致 CPU 抖动 |
| HBase | 列族级 TTL（单位秒），基于时间戳自动删除 | 秒级 | Major Compaction 时才会物理删除 |
| TiKV | TiKV 4.0+ TTL 特性 / 应用层定时清理 | 秒级 | TTL 特性需开启 GC 并注意性能开销 |
避坑提示： 不要对所有特征使用统一 TTL。风控场景中，短期特征过期后若未及时清理，会导致模型读到“幽灵特征”（已过期但未删除），造成误判。建议按特征类型设置差异化 TTL，并配合主动删除策略。
4.3 高并发读写下的性能优化
实时风控训练集构建过程中，特征存储层需要承受 写入峰值 10w+ QPS 和 读取峰值 50w+ QPS 的压力。以下优化策略覆盖架构、连接、数据模型三个层面。
4.3.1 架构层优化
- 读写分离： Redis 主库写、从库读；HBase 利用 Region Replica；TiKV 利用 Follower Read。
- 连接池化： 使用 JedisPool / HTablePool / TiKV Client 连接池，避免频繁创建销毁连接。
- 批量操作： 使用 Pipeline（Redis）、Batch（HBase）、Batch Get（TiKV）减少网络 RTT。
4.3.2 数据模型层优化
- Key 设计： 避免热 Key。例如用户 ID 取模分桶：
feature:user:{userId % 100}:{userId}。 - Value 压缩： 使用 Snappy / LZ4 压缩特征值，减少网络传输与存储开销。
- 预分区： HBase 预创建 Region；TiKV 预分裂 Region；Redis Cluster 预分配 Slot。
4.3.3 读写路径优化
| 优化项 | Redis | HBase | TiKV |
|---|---|---|---|
| 读缓存 | 本身是缓存 | BlockCache + BucketCache | RocksDB Block Cache |
| 写缓冲 | AOF / RDB 异步 | MemStore 先写内存 | Raft Log + MemTable |
| 异步写 | 支持（AOF 每秒刷盘） | WAL 异步写 | Raft 异步写 |
| 限流 | Client 端限流 | RegionServer 限流 | TiKV 流控 + 背压 |
4.4 实战案例：高并发特征写入优化
某支付风控系统需要实时写入用户交易频次特征，峰值 QPS 15w。原始方案使用 Redis 单实例，出现连接超时和热 Key 问题。优化后方案如下：
// 优化前：单 Key 写入，无连接池
Jedis jedis = new Jedis("127.0.0.1", 6379);
jedis.incr("user:txn_count:" + userId);
jedis.expire("user:txn_count:" + userId, 60);
// 优化后：连接池 + Key 分桶 + Pipeline
JedisPool pool = new JedisPool("127.0.0.1", 6379);
try (Jedis jedis = pool.getResource()) {
Pipeline p = jedis.pipelined();
// 分桶：userId % 100 分散热 Key
String bucketKey = "txn:bucket:" + (userId % 100) + ":" + userId;
p.incr(bucketKey);
p.expire(bucketKey, 60);
p.sync();
}
优化效果： 连接超时率从 5% 降至 0.1%，P99 延迟从 50ms 降至 3ms。通过 Key 分桶 + Pipeline，单机 QPS 从 3w 提升至 12w。
4.5 本章小结
- Redis 适合高频简单特征，HBase 适合海量宽表特征，TiKV 适合强一致混合负载。
- TTL 策略必须按特征时效性差异化设置，避免“幽灵特征”影响模型效果。
- 高并发优化需从架构层（读写分离、连接池）、数据模型层（Key 设计、预分区）、读写路径层（缓存、异步写）三个层面综合实施。