本文主要介绍了 Redis 持久化的两种机制：RDB 和 AOF，以及键过期的策略：惰性删除和定期删除，还有 RDB、AOF 和复制功能对过期键的处理。
RDBRDB 是 Redis 持久化的第一种方式。有两个 Redis 命令可以用于生成 RDB 文件，一个是 SAVE，另一个是 BGSAVE。
SAVE 会阻塞 Redis 服务器进程，执行时 Redis 服务器会阻塞所有客户端发送的命令。
BGSAVE 会派生出一个子进程执行，执行时仍可继续处理客户端的命令，但会拒绝客户端 SAVE 和 BGSAVE 的命令，延迟 BGREWRITEAOF 命令。
redis> BGSAVE Background saving started 执行条件SAVE 命令会阻塞服务器，所以只能手动执行。BGSAVE 可以在不阻塞的情况下执行，所以可以配置 save 选项让服务器每隔一段时间自动执行一次。
比如我们可以向服务器提供以下配置：
save 900 1 save 300 10 save 60 10000那么只要满足以下三个条件中的任意一个即可被执行：
服务器在 900 秒之内对数据库进行了至少 1 次修改。
服务器在 300 秒之内对数据库进行了至少 10 次修改。
服务器在 60 秒之内对数据库进行了至少 10000 次修改。
为了实现这一功能，服务器会维持一个记录距离上次保存之后修改的次数的 dirty 计数器和一个记录上次保存时间的 lastsave 属性。
周期操作函数 serverCron 默认每个 100 毫秒就会执行一次，它的其中一项工作就是检查 save 选项设置的条件是否满足，如果满足的话就会执行 BGSAVE 命令。
文件内容RDB 文件有多个部分，包括握手字段 ‘REDIS’ 字符串，版本号，数据库，’EOF’ 和校验字段。
核心部分是数据库字段，数据库字段包括了握手字段 ‘SELECTDB’，数据库编号和键值对，数据库编号指示了这是第几个数据库，而键值对则保存了各项数据。
键值对中除了类型和数据，还可能会有过期时间。对于不同类型的键值对，RDB 文件会用不同的方式来保存它们。
RDB 文件本身是一个经过压缩的二进制文件，每次 SAVE 或者 BGSAVE 都会创建一个新的 RDB 文件，不支持追加操作。
AOFAOF 是 Redis 持久化的第二种方式，在 AOF 和 RDB 同时开启时，服务器会优先考虑从 AOF 恢复数据，因为 AOF 每次记录间隔的时间更短。
和 RDB 直接记录键值对不同，AOF 记录的是命令。服务器在执行完一个写命令以后，会把这条命令追加到服务器 aof_buf 缓冲区的末尾，并在一个适当的时候写入文件。重建时服务器会创建一个伪客户端，依次执行文件中的命令即可完成数据的载入。
文件的写入与同步AOF 的持久化发生在每次事件循环结束之前，会阻塞服务器。在持久化时会调用操作系统的 write 函数，但通常该函数会把数据保存在一个内存缓冲区里面而不是立刻刷入磁盘。这就带来一个安全问题。为了避免这个问题操作系统又提供了 fsync 和 fdatasync 两个强制刷盘的同步函数。我们把 write 称为写入，把 fsync 和 fdatasync 称为同步。
服务器会在每次事件循环结束之前根据 appendfsync 选项写入和同步 aof_buf 中的数据：
always：写入并同步
everysec：写入，如果距离上次同步超过 1 秒，则同步
no：只写入，何时同步由操作系统决定
AOF 重写随着服务器运行时间的流逝，AOF 文件中的内容会越来越多，文件的体积也会越来越大，不仅会对宿主计算机造成影响，也拖慢了数据恢复所需要的时间。
AOF 重写是指重新生成一个 AOF 文件替换原来的 AOF 文件。但这里的重写不会对原有的文件进行读取、分析或者写入，而是把数据库中的键值对折算成命令，重新写入新的文件。
重写是一个耗时的操作，因此 Redis 把它放到后台去操作，对应的指令是 BGREWRITEAOF。在重写过程中服务器还可能接收新的指令，因此 Redis 会维护一个 AOF 重写缓冲区，记录重写期间的写命令，在重写完成后追加到 AOF 文件末尾。
RDB 和 AOF 对比RDB 的优点：
RDB 是一个非常紧凑的文件，它的体积更小，且可以选择持久化的时间，适合做备份的文件。比如每天的备份，每月的备份。
RDB 对主进程更友好，父进程只需要 fork 出一个子进程，无须执行任何磁盘 I/O 操作。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB 的缺点：
因为 RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件，间隔时间比较长。