定义
Redis所有数据保存在内存中，把内存中的数据保存在磁盘中，称之为持久化
RDB持久化
-
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行了指定次数的写操作，则会将内存中的数据写入到磁盘中，即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。RDB生成的文件也可作为复制媒介使用。
-
触发方式
- save # 客户端发出命令后，redis会生成相应的dump.rdb文件（若存在老的RDB文件，则新替老）。该命令为同步命令，进行Save 命令时，其他命令不能执行，容易发生阻塞， O(n)
- bgsave #与Save 不同的是，该命令为异步命令，会开一个子进程进行处理， O(n)
- 利用配置文件进行触发 - 采用 bgsave方式
重要配置项：
dbfilename dump.rdb # 指定本地数据库名
dir ./ # 指定本地数据库存放目录
rdbcompression yes #默认开启数据压缩，redis采用LZF压缩方式，但占用了一点CPU的时间。
stop-writes-on-bgsave-error yes #出现错误是否停止写入
rdbchecksum yes #是否对RDB文件进行校验- 全量复制 - 主从复制时会自动生成RDB文件
- debug reload - 也会生成RDB文件
- shutdown - Redis也会RDB文件
-
优缺点
- 适合大规模的数据恢复。
- 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
- 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了 - 不可控，丢失数据。
- 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件 - 耗时，耗性能
AOF持久化
-
Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
-
配置文件
- appendonly yes # 开启AOF
- appendfilename “appendonly-6379.aof” # 指定本地数据库名
- appendfsysnc always/everysec/no # 指定更新日志条件
- always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差但是数据完整性比较好（慢，安全）
- everysec：出厂默认推荐，每秒异步记录一次（默认值）
- no ：不同步，由OS决定何时把命令写入到文件中
- 为了缩小AOF文件的大小，提供了AOP重写,目的减少磁盘占用量（减少冗余）,加速恢复速度
重写原理
Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中，并没有读取旧文件，最后替换旧的aof文件。
重写方式
a. bgrewriteaof #异步，会开启一个子进程来进行处理
b. 配置文件 - 执行bgrewriteaof
auto-aof-rewrite-min-size #AOF文件重写需要的尺寸
auto-aof-rewrite-percentage #AOF文件增加率
当AOF文件大小是上次rewrite后大小的一倍（增加率）且文件大于64M（尺寸）时触发- no-appendfsync-on-rewrite yes # 在重写时是否可以进行AOF持久化操作
- aof-load-truncated yes # 在AOF文件出现错误时，是否忽略错误，尽量加载更多的数据
- 在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复
-
优缺点
- 更高的数据完整性和一致性
- 随着时间的增加，AOF文件会越来越大，数据恢复速度会越来越慢，可以通过重写解决
持久化策略对比
参考资料
[1] https://www.cnblogs.com/itdragon/p/7906481.html
[2] https://coding.imooc.com/class/151.html