Redis有两种长久化计划，RDB（Redis DataBase）和AOF（Append Only File）
一、RDB
redis的RDB计划是一种快照形式长久化，就是在某时刻把所有数据进行残缺备份。RDB是redis默认的长久化计划，它的作用是一旦在指定的工夫距离内，执行指定次数的写操作，redis服务会将内存中的数据写入磁盘中，默认是写入/var/lib/redis/dump.rdb 文件，redis重启会通过加载dump.rdb文件复原数据
1.从配置文件理解RDB
关上 /etc/redis.conf 文件，找到SNAPSHOTTING局部内容
1. ################################ SNAPSHOTTING ################################ 2. # save <seconds> <changes> 3. # 上面第一行的意思是如果900内至多有一个键被改变，主动进行数据保留，若不想应用RDB长久化能够把所有 4. #save配置正文掉，或者增加一行 save "" 5. save 900 1 6. save 300 10 7. save 60 10000 9. # 若redis最近一次长久化到dump文件出错，则默认不容许进行写操作，改成no则忽视长久化谬误容许写操作 10. stop-writes-on-bgsave-error yes 12. # 压缩dump长久化文件，改成no不压缩文件会变大很多，不过能节一点cpu，倡议应用默认值yes 13. rdbcompression yes 15. #长久化文件校验，会耗费一些性能，倡议应用默认值yes 16. rdbchecksum yes 18. # RDB长久化文件名 19. dbfilename dump.rdb 21. # 长久化文件存储目录，即dump文件所在目录，aof文件也会放在这个目录下 22. dir /var/lib/redis 2.触发RDB快照的几种形式
save 此命令是同步命令，在长久化时会阻塞所有客户端申请
bgsave 异步命令，会生成一个子过程将内存数据保留到dump文件，不影响主过程服务。通过配置文件save属性触发的长久化也是通过bgsave形式保留，新建过程会耗费内存
flushall 此命令在清空redis数据后会进行长久化操作
shutdown 应用shutdown命令会先进行长久化操作再敞开服务
3.优缺点
长处：
紧凑的繁多文件，实用于劫难复原
与aof相比，在复原大的数据集时，RDB形式会更快
毛病：
RDB须要常常生成子过程来进行数据长久化，耗时、耗性能
数据完整性不高，依据配置，一旦产生redis意外宕机可能会失落几分钟的数据
二、aof
redis的aof备份是一种写日志形式长久化，就是将用户所有的写指令备份到文件中，还原数据时会将所有指令从新执行一遍。redis默认不开启aof，redis中RDB和aof两种长久化形式能同时应用
1.aof重写
因为aof的运作形式是一直将命令追加至文件的开端，随着写入命令的一直减少，aof文件体积会变得越来越大。比方，对一个计数器调用了100此incr，那仅仅为了保留一个值aof文件就须要应用100条记录。这样不止会造成aof文件体积过大，还会导致数据恢复时速度太慢。而实际上只用一条set命令就足以保留计数器以后值了。
为了解决这种状况redis反对bgrewriteaof重写命令，用于异步执行aof文件重写操作，下面的100条记录变成1条。它会创立一个以后aof文件的优化版本，而即便bgrewriteaof执行失败，也不会有任何数据失落，因为旧的aof文件在bgrewriteaof胜利之前不会被批改。redis在肯定条件下会自发进行重写，也能够调用bgrewirteaof命令被动重写
2.从配置文件理解aof
关上/etc/redis.conf 文件，找到 APPEND ONLY FILE 局部
1. # 为了解决RDB一致性问题而生，默认不开启 2. appendonly no 4. #保留文件名 5. appendfilename "appendonly.aof" 7. # aof实际上是调用fsync()让零碎将内存中数据保留到磁盘上，有些零碎会立刻保留，有些零碎只能做到“尽可能快”保留 8. #redis反对三种模式来调用fsync(): 9. #no: 不调用，零碎按本人步调保留内存数据到磁盘 10. #always：每一次写操作都调用 11. #everysec： 每秒调用一次 12. # appendfsync always 13. appendfsync everysec 14. # appendfsync no 16. # aof的fsync尽管是一个独自线程，然而它还是会阻塞redis的同步写操作，而RDB的bgsave和aof的bgrewriteaof(重写，从前面理解） 17. # 会占用大量的I/O，是fsync阻塞住，那就意味着阻塞同步写操作。上面属性意思是不在bgsave或bgrewriteaof时 18. # 调用async，如果填yes最坏状况有可能导致失落30秒的日志。为了数据一致性默认填no 20. no-appendfsync-on-rewrite no 22. #上面两个用于配置主动重写的触发条件。只有两个条件都满足才触发 23. #第一个以后aof文件比上一次重写后aof文件减少的百分比，如果是0则aof不会主动重写，如果没有上一次 24. #重写则按redis服务启动时aof文件大小算 25. #第二个示意aof文件至多要达到这个大小才重写，次要为了避免aof文件很小的时候常常触发重写 26. auto-aof-rewrite-percentage 100 27. auto-aof-rewrite-min-size 64mb 29. # 在一些时候会产生aof文件最初面记录出问题，比方服务奔溃aof一行记录写到一半 30. #上面这个属性yes示意在复原数据时碰到最初一条问题记录会记录下来然而不影响后面数据恢复，no则间接复原失败 31. aof-load-truncated yes 3.优缺点
长处：
redis更持久，应用默认的每秒fsync策略，能保障最多失落1秒的数据，而性能仍旧很好
有序的保留了对数据库的操作，易读。比方不小心执行flushall命令，找到aof文件，移除开端的flushall命令，就能复原数据
毛病
雷同数据集下，aof文件体积通常要大于RDB文件体积
aof的数据恢复速度可能会低于RDB不过是能够承受的