3、在线存储引擎选型：Redis、Memcached、RocksDB、内存网格的对比与选型策略
说到实时特征状态存储，选哪个引擎，其实是个老生常谈但又特别容易踩坑的问题。我见过不少团队，一上来就拍脑袋用 Redis，结果数据量大了以后，内存成本直接爆炸。也见过有人死磕 RocksDB，结果因为读写放大问题，延迟死活降不下来。
今天我就把这四个主流引擎——Redis、Memcached、RocksDB、内存网格（以 Hazelcast 为例）——掰开揉碎讲清楚。你想想看，选型本质上是在问三个问题：你的数据要多大？你的延迟要求多高？你的数据要不要持久化？
核心观点：没有最好的引擎，只有最合适的场景。选型的关键是理解每个引擎的「舒适区」。
3.1 四类引擎的定位与核心差异
先给个全景图。这四个引擎虽然都叫「在线存储」，但设计哲学完全不同。
- Redis：纯内存 + 丰富数据结构 + 可选持久化。适合需要复杂操作的中小规模特征存储。
- Memcached：纯内存 + 简单 KV + 无持久化。适合纯缓存场景，数据丢了不可惜。
- RocksDB：磁盘 LSM-Tree + 高压缩比 + 无网络层。适合单机大容量存储，但需要自己封装服务。
- 内存网格（Hazelcast）：分布式内存 + 计算迁移 + 强一致性。适合需要分布式计算和存储一体化的场景。
我个人的习惯是，先看数据量。如果单机内存能放下，优先考虑 Redis 或 Memcached。如果数据量超过单机内存，RocksDB 或内存网格才是正解。
3.2 详细对比：一张表说清楚
| 维度 | Redis | Memcached | RocksDB | Hazelcast |
|---|---|---|---|---|
| 存储介质 | 内存 + 可选磁盘 | 纯内存 | 磁盘（SSD 优先） | 内存 + 可选磁盘 |
| 数据结构 | 丰富（String/List/Hash/Set/Sorted Set/Stream） | 仅 KV（值最大 1MB） | 仅 KV（值无上限） | 丰富（Map/List/Set/Queue/Topic） |
| 持久化 | RDB/AOF 两种模式 | 无 | WAL + SST 文件（天然持久化） | WAL + 持久化 Map |
| 分布式 | 集群模式（分片 + 主从） | 客户端分片（无内置集群） | 单机引擎（需上层封装） | 原生分布式（P2P 架构） |
| 读写延迟 | 亚毫秒级（纯内存） | 亚毫秒级（纯内存） | 微秒级（读缓存命中），毫秒级（磁盘 IO） | 亚毫秒级（纯内存） |
| 内存效率 | 中等（有额外元数据开销） | 高（Slab 分配器，内存碎片少） | 极高（压缩比可达 3-5x） | 中等（Java 对象开销大） |
| 典型场景 | 实时特征、会话、排行榜、消息队列 | 纯缓存、Session 存储 | 大容量特征存储、时序数据、区块链 | 分布式计算、实时分析、状态共享 |
我的经验：如果你用 Redis 存超过 100GB 的数据，建议先算一笔账——内存成本 vs SSD 成本。很多时候，RocksDB 加一层缓存，性价比高得多。
3.3 选型策略：三步走
选型不是拍脑袋，我总结了一个三步法，你在项目里可以直接套用。
第一步：看数据量级
- 小于 50GB：Redis 或 Memcached。Redis 优先，因为数据结构丰富。
- 50GB ~ 500GB：RocksDB 或 Redis + 淘汰策略。如果业务允许冷热分离，Redis 做热数据，RocksDB 做冷数据。
- 大于 500GB：RocksDB 或 Hazelcast。单机内存放不下，必须上磁盘或分布式。
第二步：看延迟要求
- P99 < 1ms：纯内存方案（Redis / Memcached / Hazelcast）。RocksDB 在缓存命中时也能做到，但波动较大。
- P99 < 10ms：RocksDB 完全够用。我做过测试，SSD 上 RocksDB 随机读大约在 5-20μs（缓存命中）到 1-5ms（磁盘 IO）。
- P99 > 10ms：任何引擎都行，但这时候你应该先优化业务逻辑，而不是纠结存储选型。
第三步：看数据一致性
- 需要强一致性：Hazelcast（支持 CP 子系统）或 Redis（WAIT 命令）。Memcached 和 RocksDB 原生不支持。
- 最终一致性即可：Redis 主从异步复制、RocksDB 单机模式都行。
- 数据可丢失：Memcached 最合适，重启即清空，零成本运维。
我曾经踩过的坑：有一次用 Redis 存用户画像特征，数据量到了 200GB，内存成本一个月好几万。后来改成 Redis 做热缓存（存最近 7 天活跃用户），RocksDB 做全量存储，成本直接降了 60%。选型一定要考虑长期运维成本。
3.4 架构对比图
下面这张图展示了四个引擎在实时特征存储架构中的位置和关系。你可以看到，Redis 和 Memcached 离应用层最近，RocksDB 偏向底层存储，Hazelcast 则横跨计算和存储。
3.5 实战选型建议
最后，我结合自己的项目经验，给几个具体的建议。
- 如果你在做实时推荐系统：特征维度多、更新频繁、需要 TTL 过期。Redis 的 Hash 和 Sorted Set 是天然选择。我建议用 Redis Cluster，分片后单节点内存控制在 20GB 以内。
- 如果你在做风控系统：特征量巨大（百亿级），但大部分是冷数据。RocksDB 做全量存储，Redis 做热数据缓存。我曾经用这个方案支撑了每天 10 亿次特征查询，P99 延迟控制在 5ms 以内。
- 如果你在做分布式状态共享：多个服务需要实时读写同一个状态。Hazelcast 的分布式 Map 带监听器，比 Redis 的 Pub/Sub 更灵活。但要注意 Java 对象序列化开销，建议用 Protobuf 或 Kryo。
- 如果你只是做纯缓存：Memcached 就够了。别用 Redis 当缓存，浪费了它的数据结构能力。而且 Memcached 的多线程模型在纯 KV 场景下吞吐量更高。
一个小技巧：选型时别忘了考虑运维成本。Redis 和 Memcached 社区成熟，出问题容易搜到答案。RocksDB 调优参数多（几十个），需要专门的人维护。Hazelcast 的集群管理比 Redis 复杂，但胜在功能集成度高。
嗯，以上就是我对这四个引擎的对比和选型策略。说白了，选型就是 trade-off，没有银弹。你只要把数据量、延迟、一致性这三个维度想清楚，答案自然就出来了。