Redis 作为互联网产品开发中不可缺少的常备武器，它性能高、数据结构丰富、简单易用，但同时也是因为太容易用了，不管什么数据、不管这数据有多大、不管数据有多少，通通塞进去，最后导致的问题就是 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理，最可怕的是服务器发生宕机后，Redis 数据库里的所有数据将会全部丢失。
比如当内存上升，性能慢时，我们进行性能调优的时候，我们想知道：
哪些Key占用了大量的内存？
想知道每个Key的占用空间？
想知道占用空间大的Key都存了啥？
想知道占用空间大的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 的持久化。
Redis 支持两种方式的持久化，一种是RDB方式，一种是AOF方式。
RDB 是 Redis 用来进行持久化的一种方式，是把当前内存中的数据集，快照写入磁盘。
RDB - 自动