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文件恢复数据。