Redis的RDB和AOF-Memos

lichaoyue888

　　1.数据快照RDB
　　1.1原理
　　(1)RDB是将某一时刻的数据持久化到磁盘中，是一种快照的方式。
　　(2)redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，及时redis处于运行状态；
　　(3)对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
　　(4)如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
　　如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。
　　1.2生成快照的几种方法
　　手动触发：
　　(1)save命令用于创建当前数据库的备份，该命令将在 redis 安装目录dir下创建dump.rdb文件;
　　如果需要恢复数据，只需将备份文件dump.rdb移动到 redis 安装目录并启动服务即可。获取redis目录可以使用 config get dir命令
　　(2) bgsave在后台执行;
　　(3)shutdown save，关闭服务的时候，shutdown有两个选项，nosave|save，如果不加，默认是save;
　　自动触发：
　　(4)配置文件redis.conf中的设置:
　　save 900 1
　　save 300 10
　　save 60 10000
　　dbfilename  dump.rdb
　　1.3 使用rdb文件进行还原测试
　　注意：还原的时候需要关闭aof的功能，否则redis在启动的时候会加载appendonly.aof这个日志文件，这样恢复的就不是dump.rdb的内容了，而是应用的aof日志
　　#使用redis-benchmark加载测试数据,并关闭aof:
　　src/redis-benchmark -h 127.0.0.1 -p 6379  -n 200000 -c 20 -d 4 -k 1 --csv > redis_benchmart_$(date +%Y%m%d).log 2>&1
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-cli
　　127.0.0.1:6379> config get dir
　　1) "dir"
　　2) "/usr/local/redis"
　　127.0.0.1:6379> config get appendonly
　　1) "appendonly"
　　2) "no"
　　127.0.0.1:6379> keys *
　　1) "key1"
　　2) "key2"
　　3) "key:__rand_int__"
　　4) "mylist"
　　5) "counter:__rand_int__"
　　127.0.0.1:6379> shutdown save
　　[root@sht-sgmhadoopcm-01 redis]# mv dump.rdb dump.rdb.bak
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-server redis.conf
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-cli
　　127.0.0.1:6379> keys *
　　(empty list or set)
　　127.0.0.1:6379> shutdown nosave
　　把备份的rdb文件放在指定位置，并重启redis，这样数据又恢复了
　　[root@sht-sgmhadoopcm-01 redis]# mv dump.rdb.bak dump.rdb
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-server redis.conf
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-cli
　　127.0.0.1:6379> keys *
　　1) "key:__rand_int__"
　　2) "mylist"
　　3) "key2"
　　4) "key1"
　　5) "counter:__rand_int__"
　　2.AOF(append only file)
　　2.1 AOF
　　(1)即只允许追加，不允许更改的文件
　　开启方法：appendonly yes
　　AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍；
　　同样数据集的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。
　　我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。
　　默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。
　　(2)如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，redis提供了redis-check-aof工具，可以用来进行日志修复:

• 　　Make a backup copy of your AOF file.
  
• 　　Fix the original file using the redis-check-aof tool that ships with Redis: $ redis-check-aof --fix appendonly.aof
  
• 　　Optionally use diff -u to check what is the difference between two files.
  
• 　　Restart the server with the fixed file.
  
• 
  

　　(3)通过appendonly.aof文件进行还原测试
　　127.0.0.1:6379> config get appendonly
　　1) "appendonly"
　　2) "yes"
　　127.0.0.1:6379> mset key1 1 key2 2 key3 3
　　OK
　　127.0.0.1:6379> keys *
　　1) "key3"
　　2) "key1"
　　3) "key2"
　　[root@sht-sgmhadoopcm-01 redis]# cp appendonly.aof appendonly.aof.bak
　　127.0.0.1:6379> flushall
　　OK
　　127.0.0.1:6379> keys *
　　(empty list or set)
　　127.0.0.1:6379> shutdown
　　[root@sht-sgmhadoopcm-01 redis]# rm -rf appendonly.aof
　　[root@sht-sgmhadoopcm-01 redis]# mv appendonly.aof.bak appendonly.aof
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-server redis.conf
　　[root@sht-sgmhadoopcm-01 redis]# src/redis-cli
　　127.0.0.1:6379> keys *
　　1) "key1"
　　2) "key2"
　　3) "key3"
　　2.2 aof文件的rewrite
　　(1)rewrite原理
　　因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。
　　在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性。
　　AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了flushall，导致redis内存中的数据全部被清空了，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。
　　(2)触发rewrite的方法
　　第一种方法：使用bgrewriteaof命令手动触发;
　　第二种方法：由配置文件控制
　　auto-aof-rewrite-percentage 100
　　auto-aof-rewrite-min-size 64mb
　　比如上边的参数设置的含义：当appendonly.aof为小于64M时，不会触发rewrite，当文件大64M,增长率达到100%,即为128M时，触发一次rewrite,这个时候redis记住文件rewrite之后的大小，假如为80M,只有等到文件再次涨到160M后，才会触发下一次，依次类推
　　3 总结：
　　官方推荐同时开启这两种备份策略，确保数据更加安全；
　　如果你的业务可以接受一定数据的丢失，更注重性能，可以只开启RDB;
　　如果只把redis作为一个缓存来用，则不需要开启RDB和AOF;
　　参考链接
　　https://redis.io/topics/persistence