3. 实时特征存储选型：Redis、HBase、TiKV、内存网格等存储引擎的对比与适用场景

实时特征存储是实时特征API的“数据基座”。选型错误会导致延迟飙升、一致性崩塌或运维成本失控。本章从数据模型、一致性模型、读写延迟、扩展性、持久化策略五个维度，对主流实时存储引擎进行系统性对比，并给出场景化选型建议。

3.1 核心对比维度与选型矩阵

实时特征存储需要同时满足低延迟（P99 < 10ms）、高并发（万级QPS）、数据一致性和可扩展性。下表从关键维度对比四种主流引擎：

3.2 各引擎深度解析与适用场景

3.2.1 Redis：极速缓存型特征存储

Redis是实时特征API中最常用的存储引擎，适合用户画像、会话状态、计数器等场景。其优势在于丰富的数据结构（Hash、Sorted Set、Bitmap）和亚毫秒级延迟。

• 适用场景：用户实时标签、在线实验分桶、限流计数器、短生命周期特征。
• 避坑点：大Key（> 10KB）会导致阻塞；集群模式下跨Slot的MGET性能下降；AOF持久化在极端故障下可能丢失1秒数据。
• 最佳实践：使用Hash结构存储多字段特征，避免序列化开销；开启lazy-free机制；使用读写分离架构降低主库压力。

// 使用Redis Hash存储用户特征示例
// Key: user:feature:{userId}
// Field: age, gender, city, ltv_level
// Value: 具体特征值

HSET user:feature:10001 age 28 gender female city beijing ltv_level 3
HGETALL user:feature:10001
// 返回: age, 28, gender, female, city, beijing, ltv_level, 3

3.2.2 HBase：宽表型海量特征存储

HBase适合用户行为序列、设备指纹、多版本特征等场景。其宽表模型天然支持按RowKey范围扫描，适合需要回溯历史特征的场景。

• 适用场景：用户行为日志特征、设备指纹库、多版本特征回溯、特征工程中间结果。
• 避坑点：RowKey设计不当会导致热点；Region分裂期间读写延迟抖动；依赖HDFS导致整体延迟较高。
• 最佳实践：RowKey设计采用“盐值+用户ID”避免热点；预分区减少分裂次数；使用BucketCache降低读延迟。

3.2.3 TiKV：强一致分布式Key-Value存储

TiKV是CNCF毕业项目，基于Raft协议实现强一致性和自动故障恢复。适合金融级特征、跨数据中心部署、需要事务支持的场景。

• 适用场景：用户资产特征、风控特征、需要分布式事务的特征更新、跨AZ高可用特征存储。
• 避坑点：Raft Log复制带来额外写放大；大事务（> 100MB）性能下降；RocksDB compaction影响读延迟。
• 最佳实践：使用RawKV模式避免事务开销；设置合理的Region大小（96MB）；开启Raft Engine减少写放大。

// TiKV RawKV API 示例（Java客户端）
// 存储用户实时特征
RawKVClient client = RawKVClient.create(pdAddrs);
ByteString key = ByteString.copyFromUtf8("feature:user:10001:age");
ByteString value = ByteString.copyFromUtf8("28");
client.put(key, value);

// 批量读取特征
List<ByteString> keys = Arrays.asList(
    ByteString.copyFromUtf8("feature:user:10001:age"),
    ByteString.copyFromUtf8("feature:user:10001:gender")
);
Map<ByteString, ByteString> result = client.batchGet(keys);

3.2.4 内存网格：计算与存储融合方案

内存网格（如Apache Ignite、Pivotal GemFire）将数据存储在JVM堆内/堆外内存中，支持SQL、事务和计算推送。适合需要实时计算的特征聚合、复杂事件处理场景。

• 适用场景：实时特征聚合（如滑动窗口计数）、特征SQL查询、需要ACID事务的特征更新、与微服务同进程部署。
• 避坑点：JVM GC导致延迟毛刺；堆内内存有限；持久化依赖WAL，宕机恢复时间长。
• 最佳实践：使用堆外内存减少GC影响；开启持久化并配置WAL；使用分区模式避免单点瓶颈。

3.3 存储引擎选型决策流程

下图展示了从业务需求到存储引擎的选型决策路径：

3.4 混合存储架构：取长补短

在实际生产环境中，单一存储引擎往往无法满足所有特征需求。推荐采用分层混合存储架构：

• L1层（热数据）：Redis / 内存网格，存储最近1小时的高频访问特征，延迟 < 1ms。
• L2层（温数据）：TiKV，存储最近7天的特征，延迟 < 5ms，支持强一致更新。
• L3层（冷数据）：HBase / 对象存储，存储历史特征，延迟 < 50ms，用于离线回溯。

3.5 选型避坑清单