redis - 持久化

我们知道redis很快是因为都是纯内存操作的，那如果数据仅仅在内存中，redis宕机了数据是不是就没了，此时大量的请求在redis中找不到缓存的数据，就会直接请求数据库，导致数据库挂掉。所以redis提供了RDB和AOF两种不同的持久化方法把数据存储到硬盘中。 RDB是以快照的形式，将某一时刻的数据都写入到硬盘。AOF(append-only file)是将每条执行的命令保存在硬盘，恢复的时候，可以从文件里读取命令在redis里重新执行，达到恢复的效果。这两种方式可以单独使用，也可以一起使用，取决于我们的实际应用场景需求。

RDB

在RDB中持久化的触发有两种：自动触发和手动触发。

手动触发

手动触发有save和bgsave命令。
当redis接收到save命令时，就会创建快照，并且在快照创建完毕之前，不会响应其他的命令。
当redis接收到bgsave命令时，redos会fork一个子进程来创建快照，然后父进程会继续处理其他的命令。虽然不会阻塞其他命令，但是创建子进程会导致redis停顿，并且由于子进程会争抢资源，导致创建快照的速度会比save慢。

自动触发

save配置如下：代表在N秒内，如果有了M次的变化，则触发bgsave命令，如果配置了多个，则任意一个生效都触发bgsave命令。

save <seconds> <changes>

redis默认的配置如下：

#900秒内有1次变化则创建快照
save 900 1
#300秒内有10次变化则创建快照
save 300 10
#60秒内有10000次变化则创建快照
save 60 10000

除了上面的规则被触发会执行bgsave外，redis接收到shutdown命令或者服务器关闭请求，又或者收到标准TERM信号时，会执行save命令，此时客户端的所有的请求将被阻塞，不在执行，并且在save命令执行完后关闭服务器。
redis的其他关于RDB配置

# bgsava失败后是否停止接收数据
stop-writes-on-bgsave-error yes
# 是否对快照进行压缩
rdbcompression yes
# 快照文件名
dbfilename dump.rdb

优缺点

优点：

1. 由于是快照形式，所以适用于全量备份。
2. 恢复速度快与AOF。

缺点：

1. 无法实时创建快照，有可能造成部分数据丢失。
2. 通过子进程创建快照时，如果数据文件太大，有可能导致redis短暂停止服务。

AOF

AOF会将redis执行过的命令追加到文件的末尾，也就是说如果从文件的开头开始执行到最后，就会得到之前一样的数据。redis默认是没有开启AOF的，需要appendonly设置为yes才开启。
除了appendonly配置，还有其他配置：

# 默认AOF文件名
appendfilename "appendonly.aof"
# 每个命令都要追加到文件，性能相对差
# appendfsync always
# 每秒同步，最多会丢失一秒的数据
appendfsync everysec
# 让操作系统决定何时同步，不可控，不推荐
# appendfsync no

由于AOF需要一直的写文件，会导致文件会一直增长，redis提供了AOF文件压缩的命令，BGREWRITEAOF。类似于bgsave，BGREWRITEAOF也会fork一个子进程，对AOF文件进行重写，所以一样会有因为创建子进行导致的资源争抢和内存占用的问题。对于重写，有以下配置：

# 比上一次重写后的体积大于100%并且大于64m的时候重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

优缺点

优点：

1. 最多丢失一秒的数据。
2. 把命令追加到文件末尾，没有任何磁盘寻址的开销，写入的速度非常快。

缺点：

1. 文件大，恢复速度慢。
2. 相对于RDB，由于每秒需要追加日志，支持的写QPS较低。

恢复

需恢复的时候，只要把RDB或者AOF文件放在配置的路径下面，重启redis服务器就可以恢复。如果同时存在两种持久化方式，并且有AOF文件，就会从AOF文件恢复数据，否则从RDB文件恢复数据。