什么是持久化
Redis 对数据的操作都是基于内存的，当遇到了意外情况导致 Redis 服务关闭后，如果没有持久化机制，Redis 中的数据将会丢失，利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化
RDB（Redis DataBase）
简介
将内存中的所有数据进行快照保存，并以二进制文件的形式存储到硬盘上
手动触发
save 指令：触发一次 RDB 持久化，但 save 命令会阻塞 Redis 服务，直到RDB持久化完成，当 Redis 服务储存大量数据时，会造成较长时间的阻塞
bgsave 指令：触发一次 RDB 持久化，与 save 命令不同的是，一般不会造成 Redis 服务阻塞，Redis 进程会执行 fork 操作创建子进程，在子进程中执行 RDB 持久化，推荐使用
触发一次 RDB 持久化后，当前 Redis 中的数据快照会以二进制的形式被保存在 dump.rdb 文件中，当 Redis 服务重启时，数据会自动恢复
自动触发
在 redis.windows.conf（Linux 下为 redis.conf）中进行 RDB 配置
save second changes在限定时间范围内，key 的变化达到指定数量则进行持久化（进行 bgsave 操作）
second：监控时间范围
changes：监控 key 的变化量
其它 RDB 配置
| 参数名 | 默认值 | 说明 |
|---|---|---|
| dbfilename | dump.rdb | 快照文件的名称 |
| dir | ./ | 快照文件的存放路径 |
| rdbcompression | yes | 指定存储至本地时是否压缩，Redis 采用 LZF 压缩 |
| rdbchecksum | yes | 指定读写时是否进行数据校验 |
RDB 的优缺点
优点
- RDB 文件是一个紧凑的二进制文件压缩文件，非常适用于灾难恢复（disaster recovery），可以（在加密后）将它传送到别的数据中心
- RDB 恢复数据的速度要远高于 AOF
- RDB 执行过程只需要 fork 出一个子进程进行处理，不会导致 Redis 服务进程出现长时间阻塞，性能较高
缺点
- RDB 不能实现实时持久化，数据安全性较低，容易丢失数据
- RDB 文件涉及到 Redis 的新老版本兼容问题
- 当数据量较大时，效率较低
- fork 出子进程会产生额外的内存消耗
AOF(Append Only File)
简介
将 Redis 的写操作日志以追加的方式写入文件
写入磁盘的三种策略
当 Redis 进行持久化时，会先将客户端传来的写命令存放在 AOF 缓冲区，再根据具体的策略写入磁盘中的 AOF 文件
always：每次写入指令都同步到 AOF 文件中，不会丢失数据，但性能低下
everysec：每秒将缓冲区的指令同步到 AOF 文件中，最多只会丢失一秒内的数据
no：由操作系统控制写入指令同步到 AOF 文件的周期
AOF 配置
在 redis.windows.conf（Linux 下为 redis.conf）中进行 AOF 配置
| 参数名 |
默认值 |
说明 |
|---|---|---|
| appendonly |
no |
是否开启 AOF 持久化 |
| appendfsync |
everysec |
指定 AOF 写入策略 |
| appendfilename | "appendonly.aof" | AOF 持久化文件名 |
| dir | ./ | AOF 持久化文件的路径，与 RDB 文件路径一致 |
AOF 重写
简介
随着运行时间的推移，AOF 文件会越来越大，为了解决这个问题，Redis 创建一个新的 AOF 文件，用来代替原 AOF 文件，两个文件保存的数据库状态相同，但新的 AOF 文件中，将指令进行整理、合并，不再包含任何浪费空间的冗余指令，这一过程称作 AOF 重写
重写规则
- 已经超时的数据不再写入文件
- 无效指令不再写入文件，如某些数据被重复设值，或是数据设值后被删除
- 多条指令合并为一个
手动重写
bgrewriteaof 指令：与 bgsave 类似，Redis 进程会执行 fork 操作创建子进程，在子进程中执行 AOF 重写
自动重写
| 参数名 | 默认值 | 说明 |
|---|---|---|
| auto-aof-rewrite-percentage | 100 | 指定 AOF 文件重写时需要的增长比例 |
| auto-aof-rewrite-min-size | 64mb | 指定 AOF 文件重写时最小的文件大小 |
通过 info 指令可以查看如下两个参数
aof_current_size：当前 AOF 文件的大小
aof_base_size：上一次重写时 AOF 文件的大小，初始为 0
当 (aof_current_size - aof_base_size) / aof_base_size ≥ auto-aof-rewrite-percentage ，也就是上一次重写后，文件的增长比例超过设定范围（初始状态除外），且 aof_current_size > auto-aof-rewrite-min-size ，则自动调用 bgrewriteaof 指令进行重写
AOF 重写缓冲区
客户端传来写命令除了存放在 AOF 缓冲区，还会存放在 AOF 重写缓冲区，在重写时，将其中的数据重写后，合并替换原先的 AOF 文件
AOF 缓冲区为什么不能替代 AOF 重写缓冲区？
AOF 重写缓冲区记录的是从上次重写开始后的所有需要重写的指令，而 AOF 缓冲区不断的进行持久化，可能只记录了剩下来的部分指令
AOF 的优缺点
优点
- 通过配置合理的写入策略，能更好的保证数据不丢失
- AOF 文件以 append 的方式写入，没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损
缺点
- 对于相同的数据量，AOF 文件通常比 RDB 文件大
- 恢复大量数据时的速度慢于 RDB
- 更加脆弱，出现 bug 的可能性要大一些