Redis有两种持久化方案： RDB (redis数据库)和AOF ) appendonlyfile。 如果想快速理解和使用RDB和AOF，可以直接跳到文章的底部查看总结。 本章通过性能分析、触发快照的方法、数据恢复操作、命令操作演示、优缺点来学习Redis重点知识的持久性。
RDB 详解
RDB是Redis的默认持久化方案。 在指定的时间间隔内，如果进行指定次数的写入，则内存中的数据将写入磁盘。 将在指定的目录下生成dump.rdb文件。 重新启动Redis将加载dump.rdb文件并恢复数据。打开
从配置文件了解RDB
redis.conf文件，找到支持快照定时的内容1 RDB核心规则配置(重点)第二次变更
# #保存'
save 900 1
save 300 10
save 60 10000解说： save指定时间间隔执行指定次数的更新操作，满足条件后将内存中的数据同步到硬盘。 出厂默认设置为，如果900秒内有一个更改，300秒内有10个更改，60秒内有10000个更改，则内存中的数据快照将写入磁盘。 如果不想使用RDB方案，请打开save“”的注释。 有以下三条评论。
2指定本地数据库的文件名。 通常使用默认的dump.rdb
dbfilename dump.rdb3指定本地数据库的存储目录，通常使用缺省配置
dir ./4缺省情况下打开数据压缩
rdbcompression yes解说：设置保存到本地数据库时是否压缩数据。 默认值为yes。 Redis采用LZF压缩方式，但CPU需要一点时间。 如果取消选中此选项，数据库文件将变得很大。 建议打开。
触发RDB快照
1在指定的时间间隔内，执行指定次数的写入的save (封锁，保存快照，其他等待)或bgsave )异步命令flushall，然后执行数据库的所有命令运行shutdown命令以确保服务正常关闭，并且不会丢失数据，这没有多大意义。将
通过RDB文件恢复数据
dump.RDB文件复制到redis安装目录的高叔叔目录中，重新启动redis服务就可以了。 在实际开发中，考虑到物理机硬盘的损坏，通常选择dump.rdb的备份。 从下面的操作演示中可以感受到。
RDB 的优缺点
好处： 1适合大规模数据恢复。 RDB适用于业务对数据完整性和一致性要求不高的情况。缺点： 1数据完整性和一致性不高，因为RDB在上次备份时可能会宕机。 2备份时消耗内存。 因为Redis在备份时会独立创建子进程，将数据写入临时文件，最后用以前的备份文件替换临时文件。 因此，Redis的持续化和数据恢复选择在深夜运行是合理的。
操作演示
[根@ it德拉根高个子大叔]# vim redis.confsave 900 1
save 120 5
save 60 10000
[root@itdragon高个子大叔]# ./redis-server redis.conf
[ root @ it龙大块头大叔]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379关键点*
(空列表或集)
127.0.0.1:6379设置1值1
好的
127.0.0.1:6379设置2值2
好的
127.0.0.1:6379设置密钥3值3
好的
127.0.0.1:6379设置4值4
好的
127.0.0.1:6379设置5值5
好的
127.0.0.1:6379设置6值6
好的
127.0.0.1:6379关闭
非连接的查询
[根@ it龙大块头大叔]# cp dump.rdb dump_bk.rdb
[root@itdragon高个子大叔]# ./redis-server redis.conf
[ root @ it龙大块头大叔]# ./redis-cli -h 127
.0.0.1 -p 6379 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon 高大的大叔]# cp dump_bk.rdb dump.rdb cp: overwrite `dump.rdb'? y [root@itdragon 高大的大叔]# ./redis-server redis.conf [root@itdragon 高大的大叔]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "key5" 2) "key1" 3) "key3" 4) "key4" 5) "key6" 6) "key2"第一步：vim 修改持久化配置时间，120秒内修改5次则持久化一次。第二步：重启服务使配置生效。第三步：分别set 5个key，过两分钟后，在高大的大叔的当前目录下会自动生产一个dump.rdb文件。（set key6 是为了验证shutdown有触发RDB快照的作用）第四步：将当前的dump.rdb 备份一份（模拟线上工作）。第五步：执行FLUSHALL命令清空数据库数据（模拟数据丢失）。第六步：重启Redis服务，恢复数据.....咦？？？？( ′◔ ‸◔`)。数据是空的？？？？这是因为FLUSHALL也有触发RDB快照的功能。第七步：将备份的 dump_bk.rdb 替换 dump.rdb 然后重新Redis。
注意点：SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照，这是一个坑，请大家注意。
其他命令：
keys * 匹配数据库中所有 keysave 阻塞触发RDB快照，使其备份数据FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)SHUTDOWN 关机走人（很少用）AOF 详解
AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
从配置文件了解AOF
打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容1 redis 默认关闭，开启需要手动把no改为yes
appendonly yes2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename "appendonly.aof"3 指定更新日志条件
# appendfsync always appendfsync everysec # appendfsync no解说：always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）everysec：出厂默认推荐，每秒异步记录一次（默认值）no：不同步
4 配置重写触发机制
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
触发AOF快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的高大的大叔目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
AOF的重写机制
前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
AOF 的优缺点
优点：数据的完整性和一致性更高缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
操作演示
[root@itdragon 高大的大叔]# vim appendonly.aof appendonly yes [root@itdragon 高大的大叔]# ./redis-server redis.conf [root@itdragon 高大的大叔]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set keyAOf valueAof OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon 高大的大叔]# ./redis-server redis.conf [root@itdragon 高大的大叔]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf" 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon 高大的大叔]# vim appendonly.aof fjewofjwojfoewifjowejfwf [root@itdragon 高大的大叔]# ./redis-server redis.conf [root@itdragon 高大的大叔]# ./redis-cli -h 127.0.0.1 -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> QUIT [root@itdragon 高大的大叔]# redis-check-aof --fix appendonly.aof 'x 3e: Expected prefix '*', got: ' AOF analyzed: size=92, ok_up_to=62, diff=30 This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes Continue? [y/N]: y Successfully truncated AOF [root@itdragon 高大的大叔]# ./redis-server redis.conf [root@itdragon 高大的大叔]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf"第一步：修改配置文件，开启AOF持久化配置。第二步：重启Redis服务，并进入Redis 自带的客户端中。第三步：保存值，然后模拟数据丢失，关闭Redis服务。第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。第五步：修改appendonly.aof，模拟文件异常情况。第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。第七步：校验appendonly.aof 文件。重启Redis 服务后正常。
补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？