Redis混合存储产品与架构介绍( 二 ) _Redis

主线程收到通知后，依次处理等待该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字节）：