混合存储型 - 产品简介| 阿里云

简介

Redis企业版混合存储型（简称混合存储型）是阿里云自主研发的兼容Redis协议的混合存储产品，使用磁盘存储全量数据，将热数据保存到内存中供应用快速读写。在保证常用数据访问性能不下降的基础上，混合存储型能够大幅度降低用户成本，实现性能与成本的平衡，同时使单个Redis实例的数据量不再受内存大小的限制。

内存数据：内存中存放了热数据的Key和Value，同时为快速确认要操作的Key是否存在，内存中也会缓存所有的Key信息。
磁盘数据：磁盘中存放所有的Key和Value，Redis的数据结构（例如Hash）也会以一定的格式进行存储在磁盘。

适用场景


适用场景	说明
视频直播	视频直播类业务往往存在大量热点数据，大部分的请求都来自于热门的直播间。使用混合存储型，内存中保留热门直播间的数据，不活跃的直播间数据被自动存储到磁盘上，可以达到对有限内存的最佳利用效果。
电子商务	电商类应用往往有大量的商品数据。使用混合存储型可以轻松突破内存容量限制，将大量的商品数据都存储到混合存储型中。在正常业务请求中，活跃的商品数据会保留在内存，不活跃的商品数据会逐渐交换到磁盘上，从而解决内存不够的问题。
在线教育	在线教育类的场景有大量的课程、题库以及师生交流信息等数据，通常只有热门课程和最新题库会被频繁访问。使用混合存储型，将所有课程信息存储到磁盘，访问量大的课程和题库数据存储到内存并常驻内存，保证高频访问数据的读写性能，实现高性能与高性价比的有机结合。

典型业务场景的示例如下：

场景1：使用开源Redis集群存储了100GB的数据，但高峰期QPS不到2万，其中80%的数据的访问频率很低。
使用32GB内存加128GB磁盘的混合存储型实例后，节省了近70GB的内存空间，存储成本下降50%以上。
场景2：在IDC自建Pika实例来解决Redis存储成本高的问题。总数据量约400GB，其中访问频率高的数据仅占10%左右，并且集群的运维成本居高不下。
使用64GB内存加512GB磁盘的混合存储型实例后，既免除了繁重的运维工作，又保障了服务质量。

选型指南-场景

混合存储型实例和基于纯内存的社区版实例各有其适用的场景，下表从四个角度帮助您做出合理的选择。


场景分类	混合存储型实例	社区版实例
数据量与预算	数据量大，有降低成本需求。正在使用Pika、SSDB或者ARDB等。正在使用大容量的主备或者集群Redis。	数据量小，或者预算充足且暂时无需降低存储成本。
冷热数据分布	业务中冷热数据区分明显。说明冷数据即访问频率较低的数据。	业务中的数据访问完全随机。
冷热数据的性能和延迟要求	热数据访问场景对性能要求很高。冷数据访问场景对延迟的敏感度不高。	业务对性能的要求极高。业务对延迟的敏感度高。
大Key的访问规律	业务中没有大Key。业务中有大Key，且大Key的访问率高，需要常驻内存。业务中有大Key，但大Key的访问率低，对延迟不敏感。	业务中有大Key，访问无规律，对延迟敏感度高。

选型指南-规格

创建混合存储型实例时，您需要选择合适的内存配置与磁盘配置：内存决定能存储的热数据量，磁盘决定能存储的数据总量。云数据库Redis版将根据您选择的配置调配合适的CPU资源创建实例。例如，选择64G内存256G磁盘主从版，则实例最多能存储256 GB的数据，在这些数据中，有64 GB可以缓存到内存中。

混合存储型实例的详细规格请参见规格查询导航。

说明

CPU核心数暂不支持自定义。
内存和磁盘中会保存Key对应的元信息，其中包含Key的过期时间、LRU时钟、类型等，因此选型时需要留有一定的额外容量，请参见下方的详细说明。

内存选型

为了更好地兼容原生Redis协议，混合存储型实例中所有的Key都必须常驻内存，Key的Value会根据冷热度自动保存在内存或磁盘中。因此，创建实例时选择的内存容量需能储存所有的Key及其对应的元信息。下表是基于Key总数的选型建议。


Key总数	推荐的内存规格
<2千万	64 GB、32 GB、16 GB
2千万~5千万	64 GB、32 GB
5千万~1亿	128 GB、64 GB、32 GB
>1亿	128 GB、64 GB

说明内存容量决定创建实例时分配到的CPU资源，因此内存容量越大性能越高。

磁盘选型
磁盘中保存Redis的所有数据，每个Key都会产生元信息，占用额外的空间，因此选择的磁盘容量建议为实际需求的1.2~1.5倍。

购买方式

详细步骤请参见步骤1：创建实例。

实例性能

混合存储型实例的性能与实例规格以及业务中数据被访问的概率有很大的关系：实例规格越高，内存数据的访问比重越高，性能就越强。理想的场景中，所有的访问都命中内存，此时实例性能与Redis社区版实例基本一致；反之，在内存命中率较低，甚至所有访问都需要从磁盘读取数据的情况下，混合存储型实例的性能将达到低谷。

在如下的三个测试场景中，Redis实例储存了总数2千万的Key，Value大小均为1 KB。测试方式为使用GET命令获取Value，三个场景的访问目标不同。

表 1. 性能测试结果
测试场景	社区版实例QPS	混合存储型实例QPS
随机访问	12.3万	1.5万
高斯分布80%的概率访问20%的Key	12.0万	5.4万
高斯分布99%的概率访问1%的Key	13.5万	11.4万

功能特性问答

Q：混合存储型的命令是否有使用限制？
A：混合存储型兼容大多数的原生Redis命令，为了保证服务性能，部分命令的使用受到限制，详情请参见Redis企业版命令限制。
Q：内存中热数据的阈值是多少？超过阈值以后会发生什么？
A：内存中热数据的阈值为实例规格的90%。例如16G内存规格的混合存储型实例，当内存使用超过14.4G时Redis会将冷数据的Value从内存中逐出（该Value的数据还存储在磁盘）。
Q：当内存使用超过阈值后，数据的逐出粒度是什么？
A：数据逐出的最小粒度为Key，例如Hash数据结构，会将整个Hash表逐出。
Q：Key-Value在内存中是如何组织的？
A：相较于Redis社区版会多出一些元数据，主要用于记录Key对应的Value是否已缓存至内存、逐出时对数据冷热的判定。
Q：数据是如何写入磁盘的？
A：为避免直接访问磁盘，数据先在内存中完成修改（类似page cache），然后由后台线程不断地将相关修改同步到磁盘。

说明热数据可以直接在内存中修改；而冷数据需要先将其加载至内存再进行修改。
Q：如果访问到的数据没有缓存到内存会如何运行？
A：在命令执行前会检查需要访问的数据是否已缓存在内存，如果尚未缓存在内存Redis会先将对应的数据从磁盘缓存至内存再执行相关命令。

说明由于访问磁盘相对较慢，且越复杂的数据结构需要加载的时间越长，请合理评估访问模型和数据模型，避免大量地访问冷数据。
Q：为什么有时候会出现写入超时？
A：可能有如下原因：
- 访问到了冷数据，从磁盘缓存至内存耗时较长。
- 写入并发量较大，数据在内存中被修改后，需要后台线程将此次修改同步到磁盘中，而磁盘的写入速度远远没有内存快，当磁盘落后于内存太多就需要限速，防止磁盘中的数据落后太多。

其他常见问题

Q：磁盘还有剩余容量，但内存满了，写入时报错，提示OOM error，怎么解决？
A：内存规格较低引起，容量不足以储存所有Key及其元信息，需要提高内存容量，详情请参见变更配置。
Q：是否支持将混合存储型实例变配至社区版实例或企业版（性能增强型）？
A：不支持。
Q：如何将混合存储型实例迁移至社区版实例或企业版（性能增强型）？
A：您可以通过redis-shake工具实现全量数据迁移，详情请参见使用redis-shake在云数据库Redis版实例之间迁移。
说明
- 由于混合存储型的编码格式和复制协议不同于社区版，通过redis-shake工具执行迁移时仅支持使用rump或sync模式来迁移全量数据（无法获取增量数据）。
- 暂不支持通过数据传输服务DTS来实现该需求。
Q：如何将混合存储型实例的数据导出至本地？
A：您可以使用redis-shake工具的dump模式来导出RDB文件。当使用社区版复制协议连接混合存储型实例时，混合存储型实例会把数据转成RDB格式发送至redis-shake，详情请参见使用redis-shake备份Redis实例。
Q：是否支持将社区版实例或企业版实例（性能增强型）当做备库挂载到混合存储型实例下？
A：支持，由于仅支持全量数据同步，此方案仅适用于某些特定场景。