Redis 内存优化神技，小内存保存大数据

这次跟大家分享一些优化神技，当你工作中遇到如下问题，那就使出今天学到的绝招，一招定乾坤！

我们应该从 Redis 是如何保存数据的原理展开，分析键值对的存储结构和原理。

从而继续延展出每种数据类型底层的数据结构，针对不同场景使用更恰当的数据结构和编码实现更少的内存占用。

为了保存数据， Redis 需要先申请内存，数据过期或者内存淘汰需要回收内存，从而拓展出内存碎片优化。

最后，说下 key、value 使用规范和技巧、 Bitmap 等高阶数据类型，运用这些技巧巧妙解决有限内存去存储更多数据难题……

这一套组合拳下来直接封神。

具体详情，且看「码哥」一一道来。

主要优化神技如下：

在优化之前，我们先掌握 Redis 是如何存储数据的。

Redis 以 redisDb为中心存储，redis 7.0 源码在 https://github.com/redis/redis/blob/7.0/src/server.h：

redisDb

Redis 使用「dict」结构来保存所有的键值对（key-value）数据，这是一个全局哈希表，所以对 key 的查询能以 O(1) 时间得到。

所谓哈希表，我们可以类比 Java 中的 HashMap，其实就是一个数组，数组的每个元素叫做哈希桶。

dict 结构如下，源码在 https://github.com/redis/redis/blob/7.0/src/dict.h：

struct dict {// 特定类型的处理函数dictType *type;// 两个全局哈希表指针数组，与渐进式 rehash 有关dictEntry **ht_table[2];// 记录 dict 中现有的数据个数。unsigned long ht_used[2];// 记录渐进式 rehash 进度的标志， -1 表示当前没有执行 rehashlong rehashidx;// 小于 0 表示 rehash 暂停int16_t pauserehash;signed char ht_size_exp[2];};

key 的哈希值最终会映射到 ht_table 的一个位置，如果发生哈希冲突，则拉出一个哈希链表。

大家重点关注 dictEntry 类型的 ht_table，ht_table 数组每个位置我们也叫做哈希桶，就是这玩意保存了所有键值对。

哈希桶的每个元素的结构由 dictEntry 定义：

typedef struct dictEntry {// 指向 key 的指针void *key;union {// 指向实际 value 的指针void *val;uint64_t u64;int64_t s64;double d;} v;// 哈希冲突拉出的链表struct dictEntry *next;} dictEntry;

哈希桶并没有保存值本身，而是指向具体值的指针，从而实现了哈希桶能存不同数据类型的需求。

而哈希桶中，键值对的值都是由一个叫做 redisObject 的对象定义，源码地址：https://github.com/redis/redis/blob/7.0/src/server.h。

typedef struct redisObject {unsigned type:4;unsigned encoding:4;unsigned lru:LRU_BITS;int refcount;void *ptr;} robj;

如下图是由 redisDb、dict、dictEntry、redisObejct 关系图：

redis存储结构

「码哥」再唠叨几句，void *key 和 void *value 指针指向的是redisObject，Redis 中每个对象都是用 redisObject 表示。

知道了 Redis 存储原理以及不同数据类型的存储数据结构后，我们继续看如何做性能优化。

当我们执行 set key value 的命令，*key指针指向 SDS 字符串保存 key，而 value 的值保存在 *ptr 指针指向的数据结构，消耗的内存：key + value。

第一个优化神技：降低 Redis 内存使用的最粗暴的方式就是缩减键（key）与值（value）的长度。

在《Redis 很强，不懂使用规范就糟蹋了》中我说过关于键值对的使用规范，对于 key 的命名使用「业务模块名:表名:数据唯一id」这样的方式方便定位问题。

比如：users:firends:996 表示用户系统中，id = 996 的朋友信息。我们可以简写为：u:fs:996

对于 key 的优化：使用单词简写方式优化内存占用。

对于 value 的优化那就更多了：

过滤不必要的数据：不要大而全的一股脑将所有信息保存，想办法去掉一些不必要的属性，比如缓存登录用户的信息，通常只需要存储昵称、性别、账号等。

精简数据：比如用户的会员类型：0 表示「屌丝」、1 表示 「VIP」、2表示「VVIP」。而不是存储 VIP 这个字符串。

数据压缩：对数据的内容进行压缩，比如使用 GZIP、Snappy。

使用性能好，内存占用小的序列化方式。比如 Java 内置的序列化不管是速度还是压缩比都不行，我们可以选择 protostuff，kryo等方式。如下图 Java 常见的序列化工具空间压缩比：

json 格式的优点：方便调试和跨语言；缺点是：同样的数据相比字节数组占用的空间更大。

一定要 json 格式的话，那就先通过压缩算法压缩 json，再把压缩后的数据存入 Redis。比如 GZIP 压缩后的 json 可降低约 60% 的空间。

key 对象都是 string 类型，value 对象主要有五种基本数据类型：String、List、Set、Zset、Hash。

数据类型与底层数据结构的关系如下所示：

编码与数据结构

特别说明下在最新版（非稳定版本，时间 2022-7-3），ziplist 压缩列表由 quicklist 代替（3.2 版本引入），而双向链表由 listpack 代替。

另外，同一数据类型会根据键的数量和值的大小也有不同的底层编码类型实现。

在 Redis 2.2 版本之后，存储集合数据（Hash、List、Set、SortedSet）在满足某些情况下会采用内存压缩技术来实现使用更少的内存存储更多的数据。

当这些集合中的数据元素数量小于某个值且元素的值占用的字节大小小于某个值的时候，存储的数据会用非常节省内存的方式进行编码，理论上至少节省 10 倍以上内存（平均节省 5 倍以上）。

比如 Hash 类型里面的数据不是很多，虽然哈希表的时间复杂度是 O(1)，ziplist 的时间复杂度是 O(n)，但是使用 ziplist 保存数据的话会节省了内存，并且在少量数据情况下效率并不会降低很多。

所以我们需要尽可能地控制集合元素数量和每个元素的内存大小，这样能充分利用紧凑型编码减少内存占用。

并且，这些编码对用户和 api 是无感知的，当集合数据超过配置文件的配置的最大值， Redis 会自动转成正常编码。

ziplist：元素个数小于hash-max-ziplist-entries配置，同时所有的元素的值大小都小于 hash-max-ziplist-value配置。

linkedlist：3.0 版本之前当列表类型无法满足 ziplist 的条件时，Redis会使用 linkedlist 作为列表的内部实现。

quicklist：Redis 3.2 引入，并作为 List 数据类型的底层实现，不再使用双端链表 linkedlist 和 ziplist 实现。

以下是 Redis redis.conf 配置文件默认编码阈值配置：

hash-max-ziplist-entries 512hash-max-ziplist-value 64zset-max-ziplist-entries 128zset-max-ziplist-value 64set-max-intset-entries 512

下图是 reidsObject 对象的 type 和 encoding 对应关系图：

type 与编码

主要原因是想通过不同编码实现效率和空间的平衡。

比如当我们的存储只有100个元素的列表，当使用双向链表数据结构时，需要维护大量的内部字段。

比如每个元素需要：前置指针，后置指针，数据指针等，造成空间浪费。

如果采用连续内存结构的压缩列表(ziplist)，将会节省大量内存，而由于数据长度较小，存取操作时间复杂度即使为O(n) 性能也相差不大，因为 n 值小 与 O(1) 并明显差别。

ziplist 存储 list 时每个元素会作为一个 entry，存储 hash 时 key 和 value 会作为相邻的两个 entry。

存储 zset 时 member 和 score 会作为相邻的两个entry，当不满足上述条件时，ziplist 会升级为 linkedlist, hashtable 或 skiplist 编码。

由于目前大部分Redis运行的版本都是在3.2以上，所以 List 类型的编码都是quicklist。

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 来紧凑存储，多个 ziplist 之间使用双向指针串接起来。

考虑了综合平衡空间碎片和读写性能两个维度所以使用了新编码 quicklist。

每次修改都可能触发 realloc 和 memcopy, 可能导致连锁更新(数据可能需要挪动)。

因此修改操作的效率较低，在 ziplist 的元素很多时这个问题更加突出。

优化手段：

整数我们经常在工作中使用，Redis 在启动的时候默认生成一个0 ~9999 的整数对象共享池用于对象复用，减少内存占用。

比如执行set 码哥 18; set 吴彦祖 18; key 等于 「码哥」 和「吴彦祖」的 value 都指向同一个对象。

如果 value 可以使用整数表示的话尽可能使用整数，这样即使大量键值对的 value 大量保存了 0~9999 范围内的整数，在实例中，其实只有一份数据。

靓仔们，有两个大坑需要注意，它会导致对象共享池失效。

Redis 中设置了 maxmemory 限制最大内存占用大小且启用了 LRU 策略（allkeys-lru 或 volatile-lru 策略）。

因为 LRU 需要记录每个键值对的访问时间，都共享一个整数 对象，LRU 策略就无法进行统计了。

集合类型的编码采用 ziplist 编码，并且集合内容是整数，也不能共享一个整数对象。

使用了 ziplist 紧凑型内存结构存储数据，判断整数对象是否共享的效率很低。

比如在一些「二值状态统计」的场景下使用 Bitmap 实现，对于网页 UV 使用 HyperLogLog 来实现，大大减少内存占用。

也就是集合中的元素的值只有 0 和 1 两种，在签到打卡和用户是否登陆的场景中，只需记录签到(1)或 未签到(0)，已登录(1)或未登陆(0)。

假如我们在判断用户是否登陆的场景中使用 Redis 的 String 类型实现（key -> userId，value -> 0 表示下线，1 - 登陆），假如存储 100 万个用户的登陆状态，如果以字符串的形式存储，就需要存储 100 万个字符串，内存开销太大。

String 类型除了记录实际数据以外，还需要额外的内存记录数据长度、空间使用等信息。

Bitmap 的底层数据结构用的是 String 类型的 SDS 数据结构来保存位数组，Redis 把每个字节数组的 8 个 bit 位利用起来，每个 bit 位 表示一个元素的二值状态（不是 0 就是 1）。

可以将 Bitmap 看成是一个 bit 为单位的数组，数组的每个单元只能存储 0 或者 1，数组的下标在 Bitmap 中叫做 offset 偏移量。

为了直观展示，我们可以理解成 buf 数组的每个字节用一行表示，每一行有 8 个 bit 位，8 个格子分别表示这个字节中的 8 个 bit 位，如下图所示：

8 个 bit 组成一个 Byte，所以 Bitmap 会极大地节省存储空间。这就是 Bitmap 的优势。

关于 Bitmap 的详细解答，大家可移步 -> 《Redis 实战篇：巧用 Bitmap 实现亿级数据统计》。

尽可能把数据抽象到一个哈希表里。

比如说系统中有一个用户对象，我们不需要为一个用户的昵称、姓名、邮箱、地址等单独设置一个 key，而是将这个信息存放在一个哈希表里。

如下所示：

hset users:深圳:999 姓名 码哥hset users:深圳:999 年龄 18hset users:深圳:999 爱好 女

因为 Redis 的数据类型有很多，不同数据类型都有些相同的元数据要记录（比如最后一次访问的时间、被引用的次数等）。

所以，Redis 会用一个 RedisObject 结构体来统一记录这些元数据，用 *prt 指针指向实际数据。

当我们为每个属性都创建 key，就会创建大量的 redisObejct 对象占用内存。

如下所示 redisObject 内存占用：

redisObejct

用 Hash 类型的话，每个用户只需要设置一个 key。

Redis 释放的内存空间可能并不是连续的，这些不连续的内存空间很有可能处于一种闲置的状态。

虽然有空闲空间，Redis 却无法用来保存数据，不仅会减少 Redis 能够实际保存的数据量，还会降低 Redis 运行机器的成本回报率。

比如， Redis 存储一个整形数字集合需要一块占用 32 字节的连续内存空间，当前虽然有 64 字节的空闲，但是他们都是不连续的，导致无法保存。

两个层面原因导致：

碎片优化可以降低内存使用率，提高访问效率，在4.0以下版本，我们只能使用重启恢复：重启加载 RDB 或者通过高可用主从切换实现数据的重新加载减少碎片。

在4.0以上版本，Redis提供了自动和手动的碎片整理功能，原理大致是把数据拷贝到新的内存空间，然后把老的空间释放掉，这个是有一定的性能损耗的。

因为 Redis 是单线程，在数据拷贝时，Redis 只能等着，这就导致 Redis 无法处理请求，性能就会降低。

执行 memory purge命令即可。

使用 config set activedefrag yes 指令或者在 redis.conf 配置 activedefrag yes 将 activedefrag 配置成 yes 表示启动自动清理功能。

这个配置还不够，至于啥时候清理还需要看下面的两个配置：

只有满足这两个条件， Redis 才会执行内存碎片自动清理。

除此之外，Redis 为了防止清理碎片对 Redis 正常处理指令造成影响，有两个参数用于控制清理操作占用 CPU 的时间比例上下限。

使用32位的redis，对于每一个key,将使用更少的内存，因为32位程序，指针占用的字节数更少。

但是32的Redis整个实例使用的内存将被限制在4G以下。我们可以通过 cluster 模式将多个小内存节点构成一个集群，从而保存更多的数据。

另外小内存的节点 fork 生成 rdb 的速度也更快。

RDB和AOF文件是不区分32位和64位的（包括字节顺序）,所以你可以使用64位的Redis 恢复32位的RDB备份文件，相反亦然。

参考文献[1]https://redis.io/docs/reference/optimization/memory-optimization/[2]《Redis 核心技术与实战》[3] https://segmentfault.com/a/1190000041771534