咱们晓得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优缺点
长处：
- 因为是快照模式，所以实用于全量备份。
- 复原速度快与AOF。
毛病：
- 无奈实时创立快照，有可能造成局部数据失落。
- 通过子过程创立快照时，如果数据文件太大，有可能导致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 100auto-aof-rewrite-min-size 64mb优缺点
长处：
- 最多失落一秒的数据。
- 把命令追加到文件开端，没有任何磁盘寻址的开销，写入的速度十分快。
毛病：
- 文件大，复原速度慢。
- 绝对于RDB，因为每秒须要追加日志，反对的写QPS较低。
复原
需复原的时候，只有把RDB或者AOF文件放在配置的门路上面，重启redis服务器就能够复原。如果同时存在两种长久化形式，并且有AOF文件，就会从AOF文件复原数据，否则从RDB文件复原数据。