导读：Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库。可用作数据库、缓存和消息中间件等。接下来本文将讨论当其作为缓存需存储大量数据导致占用很大内存时进行压缩的方法。

最初的存储

假设有一张设备表，由于业务需求需要将表内几亿条数据缓存到 Redis 中，表中有以下这些字段：

• id --bigint
• os --varchar
• imei --varchar
• muid --varchar
• target_object --json
• create_time --datetime
• update_time --datetime

首先这里我选择采用 hash 键的方式把设备数据存储进 reids 中，设计如下：

• key 是将库名与表名及对象 id 拼接的字符串（如：schema:table:id）
• value 则是一个 hash 对象，存放该设备对象的属性及对应属性的值

虽然这种存储方式可读性很高，每一个 Hash 键对应了关系型数据库中的一条设备数据。但是缺点也是很明显的，当数据量级很大时会占用很多的内存。

首次优化——节省字节

首次优化我选择先从节省所需存储的字节入手进行优化，大致可改进的地方如：

• 去除不必要的字段，如在后续业务中不会使用到，则可选择不存入 reids
• 优化存储，比如 os 字段存储 ios 或者 android等需占用比较多的字节，这时可以建立一个映射关系使用 1 代替 ios，2 代替 android 实现节省
• 缩短 redis key，如适当缩写库名和表名

进一步优化—— ziplist 数据结构 + Bucket + Snappy压缩

经历最初优化虽然节省了一定的内存，但是压缩效果还并不是特别理想。在一阵搜索资料后发现了一个有意思的压缩思路，原文地址如下：

https://www.cnblogs.com/luckcs/articles/6820494.html

1、大致思路：原先数据库中每一条设备记录在 redis 中存储为一个 Hash 键，现改为创建一定数量的 Bucket 桶（理解为也是创建 Hash 键，bucket_id 就是键的 key），每个 Bucket 的 value 值是 Hash 对象，Hash 对象中存储着多条设备记录，其中 key 为每一条设备记录的唯一标识，value 则存业务要用到的值（多个值可考虑 json 字符串形式）。

这里我们可以拿设备数据中的某一个值进行CRC32 之后取余计算得出该设备信息要存放到哪一个 bucket 中，在后面文章实践中会给出具体计算思路。

2、补充一下 ziplist 数据结构的知识点：Redis 中用到的主要数据结构有如简单动态字符串（SDS）、链表、字典（hashtable）、压缩列表（ziplist）等。Redis并没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，这个系统包含字符串对象、列表对象、Hash 对象、集合对象和有序集合对象这五种类型的对象。

其中 Hash 键的底层实现可以是 hashtable 或 ziplist，这里我们主要关注压缩列表（ziplist），压缩列表是Redis为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型（sequential）数据结构。关于 ziplist 具体实现细节这里不做细表，感兴趣的朋友可以查看相关资料。这里我们主要关注的是当满足以下两个条件时，Hash 对象就会使用 ziplist 编码

• Hash 对象保存的所有键值对的键和值的字符串长度都小于64字节
• Hash 对象保存的键值对数量小于512个

如果不能满足这两个条件的 Hash 对象则采用 hashtable编码。所以为了节省内存，这里我们要保证我们的 Hash 对象采用的是 ziplist 编码，需要符合上面的两个条件。这两个条件的上限值是可以修改的，可根据实际情况修改配置文件中的 hash-max-ziplist-value 选项和 hash-max-ziplist-entries 选项。

3、实践：首先我们进行预估计算，假设 redis 要存十亿的数据。如果想继续用 ziplist 进行压缩的话，我们需保证 Hash 对象保存的键值对数量小于512个，并且键值的长度小于64字节，这两个条件。

// 计算所需的大致 bucket 数，估Bucket数量需要多预估一点，以防触发临界值问题
bucket_count = 10亿 / 512 约等于 200W
// 这里我使用 muid 进行CRC32 之后取余来计算 bucket_id
bucket_id = CRC32(muid) % 200W

这样存储的 key 就变成了 schema:table:bucketId， value 存储的 Hash 对象中 key 这里我采用 os 拼接 muid 前 4 位再拼接 muid 经过 CRC32 得出的值来作为唯一标示（各位可根据自身实际情况定制），value 则存放 target_object 转为字符串形式，由于 target_object 值比较长，这里我采用的是Snappy 对其进行压缩。

Snappy 是由 C++ 实现的一个用来压缩和解压缩的开发包，其目标不是最大限度压缩或者兼容其他压缩格式，而是旨在提供高速压缩速度和合理的压缩率。

// maven 依赖
<dependency>
            <groupId>org.xerial.snappy</groupId>
            <artifactId>snappy-java</artifactId>
            <version>1.1.8</version>
</dependency>

经过上面的压缩方案改造后明显减少了很多的 Hash 键，且每个 Hash 键均是 ziplist 编码， 存储变为如下，经过测试后压缩了 30% 左右。

4、美中不足

虽然上面的压缩方案减少了 redis 的内存占用，但是存在着一些问题，如键过期，也就是如果设置键过期也只能是 Bucket 级过期，而不能精确到每一条设备信息过期。又如查询时，需要经过一系列计算得出 key 名后再去取值等，所以各位还需结合实际情况进行取舍。

最后

以上就是笔者对于 redis 内存压缩的思路，希望对各位有所帮助。

感谢您的阅读，如果喜欢本文欢迎关注和转发，转载需注明出处，本头条号将坚持持续分享IT技术知识。对于文章内容有其他想法或意见建议等，欢迎提出共同讨论共同进步。