Redis两种持久化方案RDB和AOF详解
本文主要针对Redis有两种持久化方案RDB和AOF做了详细的分析，希望我们整理的内容能够帮助大家对这个两种方案有更加深入的理解。
Redis有两种持久化方案，RDB（RedisDataBase）和AOF（AppendOnlyFile）。如果你想快速了解和使用RDB和AOF，可以直接跳到文章底部看总结。本章节通过配置文件，触发快照的方式，恢复数据的操作，命令操作演示，优缺点来学习Redis的重点知识持久化。
RDB详解
RDB是Redis默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis重启会通过加载dump.rdb文件恢复数据。
从配置文件了解RDB
打开redis.conf文件，找到SNAPSHOTTING对应内容
1RDB核心规则配置（重点）
save#save"" save9001 save30010 save6010000
解说：save<指定时间间隔><执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把save""的注释打开，下面三个注释。
2指定本地数据库文件名，一般采用默认的dump.rdb
dbfilenamedump.rdb
3指定本地数据库存放目录，一般也用默认配置
dir./
4默认开启数据压缩
rdbcompressionyes
解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
触发RDB快照
1在指定的时间间隔内，执行指定次数的写操作
2执行save（阻塞，只管保存快照，其他的等待）或者是bgsave（异步）命令
3执行flushall命令，清空数据库所有数据，意义不大。
4执行shutdown命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。
通过RDB文件恢复数据
将dump.rdb文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb。可以从下面的操作演示中可以体会到。
RDB的优缺点
优点：
1适合大规模的数据恢复。
2如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2备份时占用内存，因为Redis在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
操作演示
[root@itdragonbin]#vimredis.conf save9001 save1205 save6010000 [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 127.0.0.1:6379>keys* (emptylistorset) 127.0.0.1:6379>setkey1value1 OK 127.0.0.1:6379>setkey2value2 OK 127.0.0.1:6379>setkey3value3 OK 127.0.0.1:6379>setkey4value4 OK 127.0.0.1:6379>setkey5value5 OK 127.0.0.1:6379>setkey6value6 OK 127.0.0.1:6379>SHUTDOWN notconnected>QUIT [root@itdragonbin]#cpdump.rdbdump_bk.rdb [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 127.0.0.1:6379>FLUSHALL OK 127.0.0.1:6379>keys* (emptylistorset) 127.0.0.1:6379>SHUTDOWN notconnected>QUIT [root@itdragonbin]#cpdump_bk.rdbdump.rdb cp:overwrite`dump.rdb'?y [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 127.0.0.1:6379>keys* 1)"key5" 2)"key1" 3)"key3" 4)"key4" 5)"key6" 6)"key2"
第一步：vim修改持久化配置时间，120秒内修改5次则持久化一次。
第二步：重启服务使配置生效。
第三步：分别set5个key，过两分钟后，在bin的当前目录下会自动生产一个dump.rdb文件。（setkey6是为了验证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文件，找到APPENDONLYMODE对应内容
1redis默认关闭，开启需要手动把no改为yes
appendonlyyes
2指定本地数据库文件名，默认值为appendonly.aof
appendfilename"appendonly.aof"
3指定更新日志条件
#appendfsyncalways appendfsynceverysec #appendfsyncno
解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4配置重写触发机制
auto-aof-rewrite-percentage100 auto-aof-rewrite-min-size64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
触发AOF快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据
正常情况下，将appendonly.aof文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof--fixappendonly.aof进行修复。从下面的操作演示中体会。
AOF的重写机制
前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的Redis新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M”可以通过配置文件修改。
AOF的优缺点
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
操作演示
[root@itdragonbin]#vimappendonly.aof appendonlyyes [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 127.0.0.1:6379>keys* (emptylistorset) 127.0.0.1:6379>setkeyAOfvalueAof OK 127.0.0.1:6379>FLUSHALL OK 127.0.0.1:6379>SHUTDOWN notconnected>QUIT [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 127.0.0.1:6379>keys* 1)"keyAOf" 127.0.0.1:6379>SHUTDOWN notconnected>QUIT [root@itdragonbin]#vimappendonly.aof fjewofjwojfoewifjowejfwf [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 CouldnotconnecttoRedisat127.0.0.1:6379:Connectionrefused notconnected>QUIT [root@itdragonbin]#redis-check-aof--fixappendonly.aof 'x3e:Expectedprefix'*',got:' AOFanalyzed:size=92,ok_up_to=62,diff=30 ThiswillshrinktheAOFfrom92bytes,with30bytes,to62bytes Continue?[y/N]:y SuccessfullytruncatedAOF [root@itdragonbin]#./redis-serverredis.conf [root@itdragonbin]#./redis-cli-h127.0.0.1-p6379 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文件呢？？？
总结Redis默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。RDB持久化适合大规模的数据恢复但它的数据一致性和完整性较差。Redis需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。Redis针对AOF文件大的问题，提供重写的瘦身机制。若只打算用Redis做缓存，可以关闭持久化。若打算使用Redis的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
到这里Redis的持久化就介绍完了，有什么不对的地方可以指出。