简介
Redis混合存储实例是阿里云自主研发的完全兼容Redis协议和特性的混合存储产品。通过将部分冷数据存储到磁盘，在保证绝大部分访问性能不下降的基础上，大大降低了用户成本并突破了内存对Redis单实例数据量的限制。
目前阿里云Redis混合存储产品在华北2（北京）可用区D，华东1（杭州）可用区E，华南1（深圳）可用区C已开放售卖，相关产品介绍详见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%左右。
