缘由

Redis 是互联网产品开发中不可缺少的常备武器，它性能高、数据结构丰富、简单易用，但同时也是因为太容易用了，开发同学不管什么数据、不管这数据有多大、不管数据有多少，通通塞进去，最后导致的问题就是 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理。

为了更好地使用 Redis，除了对 Redis 做一些使用规范，还需要对线上使用的 Redis 有充分的了解。 那么问题来了：

• 一个 Redis 的实例用了那么大的内存，里边到底存了啥？
• 都有哪些 key？
• 每个 key 占用了多少空间？

思路

一、 先通过 keys * 命令，拿到所有的 key，然后根据 key 再获取所有的内容。

• 优点：可以不使用 Redis 机器的硬盘，直接网络传输。
• 缺点：如果 key 数量特别多，keys 命令可能会导致 Redis 卡住影响业务；需要对 Redis 请求非常多次，资源消耗多；遍历数据太慢。

二、开启 aof，通过 aof 文件获取到所有数据。

• 优点：无需影响 Redis 服务，完全离线操作，足够安全。
• 缺点：有一些 Redis 实例写入频繁，不适合开启 aof，普适性不强；aof 文件有可能特别大，传输、解析起来太慢，效率低。

三、使用 bgsave，获取 rdb 文件，解析后获取数据。

• 优点：机制成熟，可靠性好；文件相对小，传输、解析效率高。
• 缺点：bgsave 虽然会 fork 子进程，但还是有可能导致主进程卡住一段时间，对业务有产生影响的风险。

评估后，决定采用低峰期在从节点做 bgsave 获取 rdb 文件，相对安全可靠，也可以覆盖所有业务的 Redis 集群。也就是说每个实例每天在低峰期自动生成一个 rdb 文件，即使报表数据有一天的延迟也是可以接受的。

拿到了 rdb 文件就相当于拿到了 Redis 实例的所有数据，接下来就是生成报表的过程了：

• 解析 rdb 文件，获取到 Key 和 Value 的内容；
• 根据相对应的数据结构及内容，估算内存消耗等；
• 统计并生成报表；

Redis 实例 -> rdb 文件 -> 解析 rdb -> 估算内存消耗 -> 统计计数 -> 报表数据

参考地址

联想

1、制定开发团队的Redis Key使用规范，通过Key可以获得到：

• 属于什么域名（加域名标示）；
• 属于什么数据类型（加数据类型标识）；
• 是否设置过期时间；
• ...

2、统一平台进行redis key的申请，只有申请了才能进行使用。

• 申请人；
• 申请时间；
• ...