前言：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文件的可读性差
网友评论