持久化
概念：利用永久性存储介质保存数据，在特定的时间将保存的数据进行恢复的工作机制
作用：防止数据意外丢失，备份恢复；远程创建数据副本
1. 持久化方式
- RDB——数据快照：将内存中当前数据状态进行保存，快照形式，存储数据结果，存储格式简单。
- AOF——过程日志：将数据的操作过程进行保存。日志形式，存储操作过程，存储格式复杂。
2中持久化方式既可以同时使用，又可以单独使用，或都不使用。
2. 快照持久化
2.1 配置选项
dbfilename dump.rdb
- 设置磁盘上快照文件的名称，默认值为
dump.rdb - 通常设置为：dump-端口号.rdb
dir
- 设置存储.rdb文件的路径
- 通常设置成存储空间较大的目录，目录名称
data
rdbcompression yes
- 设置是否对快照文件进行压缩。默认yes，使用
LZF压缩 - 默认开启状态，如果设置为no，可节省CPU运行时间，但会使存储文件变大
2.2 启动方式
save
客户端向Redis发送 save 命令来创建一个快照。在快照创建完毕前不会再响应其他命令，有可能造成长时间阻塞，线上环境不建议使用。
bgsave
客户端向Redis发送 bgsave 命令来创建一个快照。Redis会调用fork来创建一个子进程，由子进程负责将快照写入磁盘，而父进程则继续处理命令请求。
配置项：
- stop-writes-on-bgsave-error yes（默认）——后台存储过程中如果出现错误情况是否停止保存操作。
save配置
在config文件中设置了save配置选项，限定时间范围内key的变化数量达到配置的数量即进行持久化。如果设置了多个save配置选项，那么任意一个save配置选项所设置的条件被满足时，都会触发一次 bgsave 指令。
save second changes
- second：监控时间范围
- changes：监控key的变化量
其他
- 全量复制
- 关闭服务器——接收到 shutdown/term 命令，自动执行 save 命令
3. AOF持久化
3.1 配置选项
appendonly yes|no
- 是否开启AOF持久化，默认不开启
dbfilename appendonly.aof
- 设置磁盘上快照文件的名称，默认值为`appendonly.aof
- 通常设置为：appendonly-端口号.rdb
dir
- 设置存储.aof文件的路径，与rdb持久化文件一致即可
3.2 写入策略
appendsync
- always——每个Redis写命令都要同步写入硬盘。会严重降低Redis的速度
- everysec——每秒执行一次同步，显示地将多个写命令同步到硬盘（宕机丢失1s内数据）
- no——让操作系统来决定何时进行同步，整个过程不可控
3.2 AOF重写
3.2.1 问题
- Redis不断记录写命令，导致AOF文件越来越大。甚至占满整个磁盘空间
- Redis重启通过重新执行AOF文件恢复数据，如果AOF文件非常大，还原时间就可能会非常长
3.2.2 重写方式
1. 手动重写
方式：用户向Redis发送 BGREWRITEAOF 命令，该命令通过移除AOF文件中的冗余命令来重写AOF文件。 原理：与 BGSAVE 创建快照原理相似，Redis会创建一个子进程，由子进程负责对AOF文件进行重写。
2. 自动重写
与快照持久化通过设置 save 选项自动执行 BGSAVE 一样，AOF持久化可以通过设置如下两个选项来自动执行 BGREWRITEAOF。
- auto-aof-rewrite-min-size size
- auto-aof-rewrite-percentage percentage
示例：
当AOF文件的体积大于64MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）时，Rdis将自动执行 BGREWRITEAOF 命令。
- auto-aof-rewrite-min-size 64mb
- auto-aof-rewrite-percentage 100
4. RDB vs AOF
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |