Redis 是互联网产品开发中不可缺少的常备武器，它性能高、数据结构丰富、简单易用，但同时也是因为太容易用了，我们的开发同学不管什么数据、不管这数据有多大、不管数据有多少通通塞进去，最后导致的问题就是 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理。
为了更好地使用 Redis，除了对 Redis 做一些使用规范，还需要对线上使用的 Redis 有充分的了解。那么问题来了：一个 Redis 的实例用了那么大的内存，里边到底存了啥？都有哪些 key？每个 key 占用了多少空间？
雪球当前有几十个 Redis 集群，近千个 Redis 实例，5T 的内存数据，我们也想要分析业务是否有误用，以提高资源利用率。当然，曾经我们也深深地被这个问题所困扰，今天我就来和大家分享下我是如何解决这个问题的，希望能给各位一些启发。
那有没有什么办法让我们安全高效的看到 Redis 内存消耗的详细报表呢？办法总比问题多，有需求就有解决方案。雪球 SRE 团队针对这个问题实现了一个 Redis 数据可视化平台 RDR (Redis Data Reveal)。RDR 可以非常方便的对 Reids 的内存进行分析，了解一个 Redis 实例里都有哪些 key，哪类 key 占用的空间是多少，最耗内存的 key 有哪些，占比如何，非常直观。
设计思路
我们先梳理下，有什么办法可以拿到 Redis 的所有数据。从我的角度看，大概有以下几种方法，我们分析一下个字的优缺点：
1. 先通过 keys * 命令，拿到所有的 key，然后根据 key 再获取所有的内容。
- 优点：可以不使用 Redis 机器的硬盘，直接网络传输
- 缺点：如果 key 数量特别多，keys 命令可能会导致 Redis 卡住影响业务；需要对 Redis 请求非常多次，资源消耗多；遍历数据太慢
2. 开启 aof，通过 aof 文件获取到所有数据。
- 优点：无需影响 Redis 服务，完全离线操作，足够安全；
- 缺点：有一些 Redis 实例写入频繁，不适合开启 aof，普适性不强；aof 文件有可能特别大，传输、解析起来太慢，效率低。
3. 使用 bgsave，获取 rdb 文件，解析后获取数据。
- 优点：机制成熟，可靠性好；文件相对小，传输、解析效率高；
- 缺点：bgsave 虽然会 fork 子进程，但还是有可能导致主进程卡住一段时间，对业务有产生影响的风险；
以上几种方式我们评估之后，决定采用低峰期在从节点做 bgsave 获取 rdb 文件，相对安全可靠，也可以覆盖所有业务的 Redis 集群。也就是说每个实例每天在低峰期自动生成一个 rdb 文件，即使报表数据有一天的延迟也是可以接受的。
拿到了 rdb 文件就相当于拿到了 Redis 实例的所有数据，接下来就是生成报表的过程了：
- 解析 rdb 文件，获取到 Key 和 Value 的内容；
- 根据相对应的数据结构及内容，估算内存消耗等；
- 统计并生成报表；
逻辑很简单，所以设计思路很清晰。数据流图如下：
我们再看下具体该如何实现，首先是语言选型，雪球 SRE 自研的组件基本都是用 Go 语言做的后端，所以语言选型没什么纠结，直接用 Go。然后就是刚刚说的那几个流程。
1. 解析 RDB
按照 Redis 的协议来做就可以了，这个在 GitHub 上搜索 parse rdb 就可以找到许多解析 rdb 文件的库，拿过来使用即可。我们使用了 https://github.com/cupcake/rdb 。
2. 估算内存消耗
一条记录会有哪些内存使用呢？
我们知道 Redis 的实现里面有一些基础的数据结构，就是用这些结构来实现了对外暴露的各种数据类型：比如 sds、dict、intset、zipmap、adlist、ziplist、quicklist、skiplist 等等。只要根据这条记录的数据类型，找出使用了哪些数据结构，再计算出这些基础数据结构的内存消耗，再加上数据的内存使用，以及一些额外开销比如过期时间等，就可以估算出一条记录到底使用了多少内存。
但是由于 Redis 做了非常多的优化，同样的一种数据类型，在不同场景下使用的数据结构有可能是不同的。比如 List ，比较老版本的 Redis，会根据 list 元素的数量来决定来使用哪种结构，较短的时候使用 adlist，长之后使用 ziplist，数值可以通过 list-max-ziplist-entries 来配置。
3.2 版本以后全都使用了 quicklist。而不同结构对于内存的使用其实是有区别的，我们计算的时候也没办法拿到具体的配置，所以都按默认配置来计算，最后得出的值是一个估算的值，不过也基本可以反应使用情况了。如果大家对于 Redis 使用的各种数据结构感兴趣，想了解其设计及适用场景，可以多搜索一下相关的资料以及阅读 Redis 源码。
举个计算内存使用的例子：
假如我们通过解析 rdb，获取到了一个 key 为 hello，value 为 world，类型为 string ，ttl 为 1440 的一条记录，它的内存使用是这样的：
- 一个 dictEntry 的消耗，Redis db 就是一个大 dict，每对 kv 都是其中的一个 entry ；
- 一 个 robj 的消耗，robj 是为了在同一个 dict 内能够存储不同类型的 value，而使用的一个通用的数据结构，全名是 Redis Object；
- 存储 key 的 sds 消耗，sds 是 Redis 中存储字符串使用的数据结构；
- 存储过期时间消耗；
- 存储 value 的 sds 消耗；
前四项基本是存储任何一个 key 都需要消耗的，最后一项根据 value 的数据结构不同而不同。
- 一个 dictEntry 有 2 个指针，一个 int64 的内存消耗；
- 一个 robj 有 1 指针，一个 int，以及几个使用位域的字段共消耗 4 字节；
- 过期时间也是存储为一个 dictEntry，时间戳为 int64；
- 存储 sds 需要存储 header 以及字符串长度 +1 的空间，header 长度根据字符串长度不同也会有所不同；
我们根据以上信息可以算出，向操作系统申请这些内存，真正需要多少内存。由于 Redis 支持多种 malloc 算法，我们就按 jemalloc 的分配方式算，这里也是可能存在误差的点。
所以最后 key 为 hello 的这条记录在 64 位操作系统上一共会消耗 92 字节。
其他类型的计算也大致是同样的思路，只不过根据不同的数据结构需要计算不同的内存消耗，计算的时候要记得考虑内存对齐的情况。还有由于 zset 的算法涉及到了随机生成层数，我们也使用同样的算法来随机，但是算出来的值肯定不是精确的，也是一个误差点。
3. 统计计数
终于可以拿到任何一个 key 的内存使用了，哪些是最有意义最有价值的数据呢？
- top N，毫无疑问最大的前 N 个 key 一定是要关注的；
- 不同数据类型的 key 数量元素数量分布以及内存使用情况；
- 按照前缀分类，统一的前缀一般意味着某个特定的业务在使用，计算各个分类的 key 数量及内存使用情况；
这几个需求实现起来也都很容易：
- 维护一个小顶堆来存储前 N 个最大的即可，最后取出堆中的数据即可；
- 计数即可；
- 一般都会有特定的分隔符，比如 :|._ 等字符，按照这些字符切出公共前缀再统计，同时把所有的数字都替换为 0，便于分类；
4. 报表数据
可以每天打开个网页就可以看到某个 Redis 实例的内存使用的详细情况，是件非常幸福的事情，Redis 的内存使用再也不是黑盒。
这个系统上线一年以来对我们优化 Redis 资源使用、提高效率、节约成本提供了非常重要的数据支撑，而且在内部完全自动化，开发同学自己就可以看到当前 Redis 的使用情况是否符合预期，对于保障业务稳定也起到了非常重要的作用。这也是雪球的工程师团队一贯的做法，SRE 提供高效的工具，开发工程师可以自己运维自己的业务系统，可以极大的提高生产效率。
这个项目参考了 redis-rdb-tool 这个开源项目，但是性能上比它高效几倍，为了回馈社区，也希望有机会帮到大家，所以我们决定开源出来。
雪球的内部系统根据自己的特殊场景做了自动化获取 rdb 文件并备份的逻辑，开源出来的版本去除了定制化，只保留了获取到 rdb 之后的分析逻辑以及页面。
项目地址为 github.com/xueqiu/rdr。有任何问题可以提 issue，也可以直接邮件联系我：dongmx@xueqiu.com。
作者介绍
董明鑫，雪球 SRE 工程师，主要负责保障雪球稳定性、提升资源利用率及提高开发效率等方向。
感谢郭蕾对本文的审校。
