3. Redis的两种持久化策略

前言：Redis的数据都存放在内存中，若没有配置持久化，Redis重启后对丢失数据，所以需要开启Redis的持久化功能，将数据保存在磁盘，当Redis重启后，就能从磁盘中恢复数据

Redis的两种持久化方式

RDB持久化
AOF持久化
AOF（append only file）持久化记录每次对服务器的写操作，当服务器重启后会重新执行这些命令来恢复原始的数据

3.1 RDB持久化

RDB持久化：在指定的时间间隔对数据进行快照存储（以二进制进行存储，磁盘占用小，加载速度快）
客户端直接通过命令BGSAVE或者SAVE来创建一个内存快照

RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储。
客户端直接通过命令BGSAVE或者SAVE来创建一个内存快照

BGSAVE：BGSAVE调用fork创建一个子进程，子进程负责将快照写入磁盘，而父进程仍然能够继续处理命令（但是调用Fork函数时也会阻塞）
SAVE：Redis在执行SAVE指令的过程中，不会fork子进程，所以此时Redis不能响应其它指令

bgsave的写时复制机制
通过查看后台进程能查看到主进程fork出了名为redis-rdb-bgsave的子进程，bgsave子进程借助操作系统提供的写时复制（Copy-On-Write），在生成快照的同时，主进程依旧可以正常处理写入指令；
大概过程：**子进程共享父进程的所有内存数据，若持久化RDB过程中都是读操作，则父子进程互不影响；若有写操作，子进程是先将数据写入一个临时文件，待持久化结束再用临时文件替换掉持久化好的文件，整个过程中主进程不进行任何文件IO，确保主服务的性能

注意：Redis单线程，并不是说Redis服务端只会启动一个进程干活，实际上会有其它的后台进程进行其它操作
还有两种情况会触发RDB持久化
1）shutdown（在没开启AOF的情况下）
2）flushall

Redis持久化策略配置
默认情况下，RDB持久化将数据保存在名为dump.rdb的二进制文件中
在redis.conf中可调整RDB的持久化策略，当规定时间内，Redis发生了写操作的个数满足条件就会触发BGSAVE命令（上生产优化时，一般留一条即可）

# The filename where to dump the DB
dbfilename "dump.rdb"
# rdb文件保存在dir指定的目录
dir "./"
# 900秒内至少1次增删改操作
save 900 1
# 300秒内至少10次增删改操作
save 300 10
# 60秒内至少10000次增删改操作
save 60 10000
# 若想禁用RDB持久化，则将save全都注释掉，或者save “”也行，进行主从复制时无法关闭RDB持久化，因为主节点是通过发送RDB文件发给从节点进行主从复制的

数据丢失的情况是假设当前这样的配置，60秒只有几次数据的插入不超过10000次写操作，此时Redis被kill掉了，这时候数据就不会被记录下来。重新启动数据就已经丢失了。

RDB持久化的优缺点

优点	缺点
对性能影响最小	同步时丢失数据
RDB文件进行数据恢复比使用AOF要快很多	如果数据集非常大且CPU不够强（比如单核CPI），Redis在fork子进程的时候可能会消耗相对较长的时间，影响Redis对外提供服务的能力

3.2 AOF持久化

为什么有了RDB持久化还需要AOF持久化？
因为RDB持久化不可靠，没有达到RDB持久化的要求，所以丢失会较多

为了解决RDB持久化的不可靠问题，Redis官方提供了AOF持久化是将Redis的操作日志以日志追加的方式写入文件，读操作不需要进行记录，这样大大减少数据的丢失

bgrewriteaof
使用bgrewriteaof能够将一系列指令进行合并（如set count 10 set count 20直接合并为set count 20）

AOF核心配置

# 开启AOF持久化
appendonly yes
# AOF策略
# 只要有数据修改发生时都会写入AOF文件（缺点：影响性能，但丢失数据少）
appendfsync always
# 每秒钟同步一次，该策略为AOF的缺省策略（最多丢失1秒的数据）（推荐使用）
appendfsync everysec
# 等操作系统进行数据缓存同步到磁盘（快，但持久化没保障）（生产不建议用）
appendfsync no

AOF持久化的优缺点

优点	缺点
最安全	文件体积大
容灾	性能消耗比RDB大
文件内容易读，可修改	数据恢复速度比RDB慢

开启AOF持久化后实现效果

*2：表示接下来有两个元素（此处指的是select 和 0）
$6：表示命令的长度是6个char（此处指的select）

两种持久化机制是可以同时开启的，但是会优先加载AOF文件，加载过程如下

3.2 AOF的混合持久化机制

为了解决AOF文件重新加载慢的问题，Redis 4.0之后引入了混合持久化机制，对AOF持久化进行了增强。

# 开启混合持久化机制（Redis 4.0后混合持久化默认关闭，redis 5.0之后默认开启）
aof-use-rdb-preamble yes

混合持久化是通过bgrewriteaof完成，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量以RDB方式写入AOF文件中，然后将重写缓冲区的增量命令以AOF文件替换旧的AOF文件，简单说，即新的AOF文件前半段是以RDB格式的全量数据后半段则是AOF格式的增量数据（重写也会fork子进程）

何时进行bgrewriteaof？
当AOF文件增长到一定的程度时进行重写，有两个配置可以控制

# 当后面AOF文件大小增长比例大于以下配置时进行重写
auto-aof-rewrite-percentage 100
# 第一次，当AOF文件增长到以下大小（默认64mb，生产建议改为3gb）
auto-aof-rewrite-min-size 64mb

混合持久化模式的优缺点
优点：混合持久化结合了RDB持久化和AOF持久化的有点，由于大部分都是RDB格式，所以加载速度快，同时结合AOF，以增量的方式保存，数据丢失更少
缺点：兼容性差，一旦开启混合持久化，在4.0之前的版本不能识别该AOF文件，且前半部分的AOF文件的可读性差