简介
Redis 混合存储实例是阿里云自主研发的完全兼容 Redis 协议和特性的混合存储产品. 通过将部分冷数据存储到磁盘, 在保证绝大部分访问性能不下降的基础上, 大大降低了用户成本并突破了内存对 Redis 单实例数据量的限制.
目前阿里云 Redis 混合存储产品已开放公测, 详见 https://promotion.aliyun.com/ntms/act/hybridstore.html
与 Redis 高性能内存型实例差别
Redis 高性能内存型实例中, 所有的 Key 和 Value 都存储在内存中以达到极致性能.
Redis 混合存储型实例中, 所有的 Key 和经常访问的 Value 会被保存在内存中, 保证绝大部分请求的极致性能. 不常访问的 Value(冷数据)则会被存储到磁盘上, 以达到内存利用最高性价比.
产品优势
简单易用
完全兼容 Redis 协议, 用户无需修改任何代码.
低成本
相同数据量下, NVMe 盘成本仅为内存的 1/10.
大容量
突破内存容量限制, 单实例最高可支持 TB 级别的数据容量.
高性能
Redis 混合存储型实例的绝大部分热点请求直接从内存获取, 其性能与高性能内存型实例完全一致. 后台异步 IO, 冷数据访问不影响正常请求的响应. 在 90% 数据落在磁盘上的极端场景下, 正态访问的 QPS 仍可达纯内存性的 70%. 底层存储采用阿里自研下一代高性能全用户态存储引擎 Alibaba FusionEngine: 通过结合上层应用深入定制, 以及与底层硬件深度结合, 将新一代存储介质如 NVMe SSD 性能发挥到极致. 4KB 数据读取速度在 20us 左右, 相比业界同类引擎性能有 80% 提升.
整体架构
存储模型
在 Redis 混合存储实例中, 我们将所有的 Key 和经常访问的 Value 保留在内存中, 将不经常访问的 Value 保存在磁盘上. 之所以在内存中保留所有 Key 是处于以下两点考虑:
Key 的访问频度比 Value 要高很多.
作为 KV 数据库, 通常的访问请求都需要先查找 Key 确认 Key 是否存在, 而要确认一个 key 不存在, 就需要以某种形式检查所有 Key 的集合. 在内存中保留所有 Key, 可以保证 key 的查找速度与纯内存版完全一致.
Key 的大小占比很低.
在通常的业务模型里面, 即使是普通字符串类型, Value 比 Key 要大几倍. 而对于 Set,List,Hash 等集合对象, 所有成员加起来组成的 Value 更是比 Key 大了好几个数量级.
Redis 混合存储实例将所有的 Key 都认为是热数据, 以少量的内存为代价保证所有 Key 的访问请求的性能是高效且一致的. 而对于 Value 部分, Redis 混合存储实例会在必要时根据最近访问时间, 访问频度, Value 本身大小等维度选取出一部分 Value 作为冷数据后台异步存储到磁盘上.
因此, Redis 混合存储实例最适合以下使用场景:
数据访问不均匀, 存在热点数据;
内存不足以放下所有数据, 且 Value 较大(相对于 Key 而言)
线程模型
Redis 混合存储实例采用单工作线程的模式, 主线程为工作线程, 负责处理用户请求等主要逻辑. 此外, Redis 混合存储实例中根据需要会配置若干个独立的 IO 线程负责与磁盘进行交互读写数据, IO 线程读写数据时, 主线程仍可继续响应其它用户请求.
数据从内存到磁盘
在周期巡检函数 serverCron 中, 如果发现当前内存快满了, 大于设定的阈值 vm-max-memory(略小于 maxmemory)时, 会尝试挑选出一些 key, 将其 Value 保存到磁盘;
挑选的维度为最近访问时间和 value 大小, 公式为 swappability = age*log(估算内存大小).
主线程为挑选出的 value 生成 IO 任务, 加入到 IO 任务队列中;
IO 线程会从 IO 任务队列中取出任务, 将 Value 存储到底层存储引擎 (RocksDB) 中, 并通知主线程.
主线程收到通知后释放 Value 所占用内存并标记内存中该 Key 对应的 Value 已被存储到磁盘上.
数据从磁盘到内存
当 Redis 混合存储实例收到用户请求时, 会先判断请求是否需要读取对应 Key 的 Value;
如果请求不需要读取相关 value(比如 set foo bar 是不需要关心 foo 这个 key 原有的值是多少的)或者 value 已经在内存中, 则正常执行该命令;
如果有涉及到的 Value 不在内存中, 主线程会对应生成一个读取 Value 的 IO 任务, 加入到 IO 任务队列中;
主线程将需要等待 IO 任务完成的客户端加入到等待列表, 然后继续处理其余客户端的请求;
IO 线程获取到读取 Value 的 IO 任务时, 从底层存储引擎中读取数据, 并通知主线程;
主线程收到通知后, 依次处理等待该 Value 的所有客户端请求.
同步 IO
在以下情况下, Redis 混合存储的异步 IO 模型会退化成同步方式:
写入量太大导致后台线程不能及时将数据交换到磁盘, 内存不断增加到超出 maxmemory 时.
由于无法预知脚本会操作哪些 value 以及原子性的要求, lua 脚本中涉及到的 value 如果在磁盘上的话将会采用同步 IO 的方式从磁盘读取.
数据淘汰机制
在 Redis 中, 允许用户设置最大使用内存大小 server.maxmemory, 在内存限定的情况下是很有用的. Redis 内存数据集大小上升到一定大小的时候, 就会施行数据淘汰策略. Redis 提供 6 种数据淘汰策略:
volatile-lru: 从已设置过期时间的数据集 (server.db[i].expires) 中挑选最近最少使用的数据淘汰
volatile-ttl: 从已设置过期时间的数据集 (server.db[i].expires) 中挑选将要过期的数据淘汰
volatile-random: 从已设置过期时间的数据集 (server.db[i].expires) 中任意选择数据淘汰
allkeys-lru: 从数据集 (server.db[i].dict) 中挑选最近最少使用的数据淘汰
allkeys-random: 从数据集 (server.db[i].dict) 中任意选择数据淘汰
no-enviction(驱逐): 禁止驱逐数据
Redis 混合存储实例的淘汰策略与纯内存版完全一致, 唯一不同的是触发条件. 在混合存储实例中, 除了内存规格大小 server.maxmemory 外, 还有一个数据磁盘大小的限制 server.maxdisksize. 触发数据淘汰的条件响应的变为以下两者之一:
使用内存> server.maxmemory 且 磁盘数据> server.maxdisksize.
使用内存> server.maxmemory, 且当前内存中无 Value(全部为 Key).
持久化
Redis 有两种持久化的方式: 快照 (RDB 文件) 和追加式文件(AOF 文件):
RDB 持久化方式会在一个特定的间隔保存那个时间点的一个数据快照.
AOF 持久化方式则会记录每一个服务器收到的写操作. 在服务启动时, 这些记录的操作会逐条执行从而重建出原来的数据. 写操作命令记录的格式跟 Redis 协议一致, 以追加的方式进行保存.
Redis 混合存储实例在 RDB+AOF 基础之上, 采用了 RocksDB 的 Checkpoint 保存当前实例冷数据的部分. 在生成数据快照时, RDB 中仅存储 Key + 热数据部分, 而冷数据部分则保存在 RocksDB 的 Checkpoint 中. RocksDB checkpoint 生成过程如下:
禁止删除 SST 文件;
为 SST 文件创立硬链接;
备份 manifest 等文件;
允许删除 SST 文件;
由于冷数据在 RocksDB 中的大部分是以 SST 文件形式存在的, 使用硬链接的方式备份几乎不需要消耗额外的时间. 通过使用 RDB+CheckPoint 的方式存储快照, Redis 混合存储实例可以有效的降低数据快照生成和加载的时间, 避免了过程中冷数据数据在 RDB, 内存, RocksDB 之间的来回转换.
底层存储引擎
Redis 混合存储实例通过精心定义的编码转换层最小化 IO SIZE, 定制调优的 RocksDB 最大化读写性能, 阿里自研下一代高性能全用户态存储引擎压榨硬件性能以及搭配最新的硬件, 将 IO 速度提升到极致.
底层存储采用阿里自研下一代高性能全用户态存储引擎 Alibaba FusionEngine: 通过结合上层应用深入定制, 以及与底层硬件深度结合, 将新一代存储介质如 NVMe SSD 性能发挥到极致. 4KB 数据读取速度在 20us 左右, 相比业界同类引擎性能有 80% 提升.
性能数据
在线上机器上, 我们使用 memtier_benchmark 测试了 Redis 纯内存高性能实例和 Redis 混合存储实例的性能对比如下(Value 大小为 1024 字节):
当访问内存中数据时, Redis 混合存储实例的性能与 Redis 纯内存高性能实例几乎一致;
当内存仅能容纳 10% 的 value 数据时, 正态访问 (70% 的访问落在 33% 的数据范围内) 时, Redis 混合存储实例的性能为 Redis 纯内存高性能实例的 70% 左右.
硬广
点击以下链接, 申请免费试用 Redis 混合存储实例
来源: https://yq.aliyun.com/articles/582418