热×冷
数据的温度
内存很快,但它很贵。磁盘很慢,但它很便宜。在两者之间,Redis 企业版铺设了一条精巧的通道 —— 让数据按使用频率自动流动,在性能与成本之间找到那个被低估的平衡点。
当内存成为账单上最显眼的那行数字
Redis 起家的故事很简单:把一切放进内存,换取微秒级响应。多年来,这个简单的承诺塑造了无数高并发应用 —— 直到数据集的体量开始膨胀。
当某个电商团队发现他们的 Redis 集群已经达到 3TB,而其中超过 70% 的键在过去 24 小时内从未被访问过 —— 他们才意识到一件事:用 DRAM 的价格,存放了大量本不需要 DRAM 速度的数据。
问题不在于 Redis 本身,而在于一个被忽视的假设:并非所有数据都同样"热"。一个用户的登录会话、一个商品的实时库存、一个排行榜的当前快照 —— 它们配得上 DRAM。但用户三年前的购物记录、过期的会话日志、归档的事件流呢?
关键不在于精确数字,而在于数量级差异。
所有数据生而平等,
但有些数据比另一些更平等。
Auto Tiering:让数据自己找到该去的地方
Redis 企业版的 Auto Tiering(早期称为 Redis on Flash, RoF)将单一存储介质拆分成多个温度层。键的元数据和热数据驻留在 DRAM,值的主体可以下沉到 SSD/NVMe。整个过程对应用透明 —— 你的代码仍然只在和 Redis 对话。
工作原理,三步看完
无论值存储在哪一层,所有键的元数据(key、过期时间、类型、指向值的指针)都常驻 DRAM。这保证了 GET / EXISTS / TTL 等操作的 O(1) 性能 —— 你不会因为某个值在 SSD 上而支付任何"查找"代价。
后台进程持续追踪每个值的访问频率与时间。冷数据被序列化、压缩,写入 SSD 上由 RocksDB 管理的 LSM 树。当冷值被访问时,它会被提升回 DRAM —— 整个过程对客户端完全透明。
管理员可配置 RAM 与 Flash 的目标比例(如 20:80),设置阈值与回写策略。Redis 企业版会在后台不断调整,确保热数据保持在内存中,而冷数据安静地住在 SSD 里。
配置 Auto Tiering,从一行命令开始
创建分层存储数据库
通过 rladmin CLI 创建启用 Auto Tiering 的数据库,指定 DRAM 与 Flash 的目标比例。
应用代码无需任何变化
对客户端而言,分层存储完全透明。同样的命令,同样的 API,只是底层多了一个智能调度层。
谁应该认真考虑这件事?
数据来源:行业典型案例区间,具体收益依工作负载、访问模式、硬件配置而异。
没有免费的午餐,但有划算的那种
Auto Tiering 不是银弹。在拥抱它之前,值得诚实地审视它给你带来什么、又夺走什么。
- 显著的 TCO 降低同样的数据集,基础设施成本通常能降到原来的 30–50%。规模越大,绝对收益越明显。
- 更大的有效容量单节点能承载的数据量从受 RAM 容量限制,变为受 SSD 容量限制 —— 通常意味着 5–10× 的提升。
- 对应用透明不需要重写代码,不需要引入新的客户端 SDK,不需要修改数据模型。你的应用甚至不知道分层在发生。
- 保留 Redis 的全部能力所有数据结构、所有命令、所有模块都继续工作 —— 包括 RedisJSON、RediSearch 等。
- 冷数据访问延迟上升当请求命中 Flash 上的值时,延迟会从微秒级升至毫秒级。需要评估你的 P99 容忍度。
- 对访问模式敏感如果工作负载没有明显的热点(均匀随机访问),分层带来的收益会大幅缩水甚至变成负担。
- 硬件要求更严需要高质量的 NVMe SSD,IOPS 与耐久性都很关键。普通 SATA SSD 通常无法胜任。
- 仅企业版可用开源 Redis 没有这个特性。预算决策需要权衡软件许可成本与硬件节省之间的关系。
把钱花在该花的地方
冷热分离不是关于"让 Redis 变得更便宜",而是关于让数据的存储位置匹配它的真实价值。
一个用户上次访问是五分钟前还是五个月前,这是有信息的。一个商品是首页推荐还是搜索深处的长尾,这也是有信息的。Redis 企业版的 Auto Tiering 做的事,就是把这些信息变成存储介质的选择 —— 自动地、持续地、对应用透明地。
如果你的 Redis 集群正在增长,如果你的内存账单正在攀升,如果你怀疑你的数据里藏着大量"占着 DRAM 不干活"的冷键 —— 那么这条通向 SSD 的路,值得你认真走一遍。
