redis持久化RDB和AOF详解

简介：redis 是一个内存级别的缓存程序，使用内存进行数据的缓存，redis 可以将内存的数据按照一定策略保存在硬盘上，从而实现数据持久保存
redis 支持2种数据持久化保存机制 RDB和 AOF
一、RDB
RDB:基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。
RDB bgsave 实现快照的过程：
redis 从master主进程fork出一个子进程 ，子进程将内存的数据保存为一个临时文件，比如：tmp-.rdb,当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照保存的数据都是完整的。

RDB相关的配置项：

save 900 1 如果在900s内，有1个key内容更改，就执行快照
save 300 10 在300s内，有10个key更改，就执行快照
save 60 10000 60s内，有10000个key变化，就自动快照备份
dbfilename dump.rdb
dir 日志存放目录
stop-writes-on-bgsave-error yes  bgsave过程中出现故障时，无法完成持久化，则立刻禁止redis的写操作，只针对自动save有效。
rdbcompression yes
rdbchecksum yes  是否对备份开启rc64校验，默认开启

RDB实现方式：
save
bgsave
自动：制定规则，自动执行
RDB的优点：
1、rdb快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行）或者save(会阻塞写操作，不推荐）命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本，很适合备份，并且此文件格式有不少第三方工具可以进行后续的数据分析。
2、RDB可以最大化redis的性能，父进程再保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。
3、RDB再大量数据，比如几个G的数据，恢复的速度比AOF的快。
RDB的缺点
1、不能实时保存数据，可能丢失从上次快照至当前时间的内存数据。
2、当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或秒级别，取决于磁盘IO性能。
手动备份RDB文件的脚本：

 #!/bin/bash 
  . /etc/init.d/functions
  BACKUP=/backup/redis-rdb
  DIR=/data/redis
  FILE=dump_6379.rdb
  PASS=123
  DATE=`date +%F_%H-%M-%S`
  redis-cli -h 127.0.0.1 -a $PASS --no-auth-warning bgsave
  result=`redis-cli -a 123 --no-auth-warning info Persistence|grep rdb_bgsave_in_progress|sed -rn 's/.*:([0-9]+).*/\1/p'`
  until [ $result -eq 0 ];do
	sleep 1
	result=`redis-cli -a 123 --no-auth-warning info Persistence|grep rdb_bgsave_in_progress|sed -rn 's/.*:([0-9]+).*/\1/p'`
  done
  
  [ -e $BACKUP ] || { mkdir -p $BACKUP ; chown -R redis.redis $BACKUP; }
  mv $DIR/$FILE $BACKUP/dump_6379-${DATE}.rdb
  
  action "Backup Redis RDB"

二、AOF
AOF模式工作原理：
AOF APPEND ONLY FILE ,按照操作顺序一次将操作追加到指定的日志文件末尾。

AOF和RDB一样使用了写时复制，AOF 默认为秒钟fsync一次，即将执行的命令保存到AOF文件当种，这样即使redis服务器发生故障的话最多丢失1秒钟之内的数据，也可以设置不同的fsync策略，比如：always ，即设置每次执行命令的时候执行fsync，fsync会再后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响。

同时启用RDB和AOF，当进行恢复时，默认AOF文件优先级高于RDB文件，即会使用AOF文件进行恢复

注意：AOF模式默认是关闭的，第一次开启AOF后，并重启服务生效后，会因为AOF的优先级高于RDB,而AOF默认没有文件存在，从而导致所有数据丢失。

AOF rewrite 重写 ，重写是为了使AOF文件的体积保持最小，但是还可以保存最完整的数据。将一些重复的，可以合并的，过期的数据重新写入一个新的AOF文件，从而节约AOF备份占用的磁盘空间，也能加速恢复过程。

可以手动执行bgrewriteaof 触发rewriteAOF,或定义自动rewrite策略
AOF rewrite 过程

如何正确启动AOF日志记录功能？
1.交互式命令行登录redis,启动AOF功能，会立即生成AOF文件
127.0.0.1:6379>config set appendonly yes
2.修改redis.conf
appendonly no 改为 appendonly yes
注意：此时不需要重启redis服务了

手动执行AOF rewrite 使用 bgrewriteaof命令

AOF 相关配置

  appendonly yes  是否开启AOF日志记录，默认为no
  appendfilename "appendonly-${port}.aof"  aof文件名
  appendfsync everysec  aof持久化策略，no 表示有操作系统去同步数据到磁盘，Linux默认的fsync策略是30秒,最多丢失30s数据；
									   always 表示当每次有数据写入，都会执行fsync，以保证数据同步到磁盘，安全性高，性能较差
									   everysec 表示每秒执行一次fsync，可能会导致丢失这1s数据，此为默认值，推荐生产环境使用
  dir /PATH
  no-appendfsync-on-rewrite yes 在aof rewrite 期间，是否对AOF新记录的append暂缓使用文件同步策略，默认值为no,表示不暂缓同步策略，新的aof记录仍然会被立即同步到磁盘，这样能保证数据安全性，不会丢数据，但是会产生阻塞问题；当设为yes，要暂缓AOF写入，此时相当appendfsync=no，即不立即同步，而由操作系统自己决定，默认30s后才同步，这样的话，有可能最多丢失30s的数，但是可以避免出现阻塞
  auto-aof-rewrite-percentage 100 当aof log 增长超过指定百分比例时，触发aof rewrite ,若设置为0，表示不自动触发rewrite  
  auto-aof-rewrite-min-size 64mb  触发aof rewrite 的最小文件大小，即小于64m时，不会触发rewrite
  aof-load-truncated yes 是否加载由于某些原因导致的末尾异常的AOF文件（主进程被kill、断电等），建议yes
  aof-use-rdbb-preamble no  redis4.0新增RDB-AOF混合持久化格式，开启后AOF重写产生的文件将同时半酣RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样redis就可以可同时兼有RDB持久化和AOF持久化的优点，默认为no不启用此功能

AOF 模式优点
1、数据安全性相对较高，根据所使用的fsync策略（fsync是同步内存种所有已经修改的文件到存储设备），默认是appendfsync everysec ,即每秒执行一次fsync，在这种配置下，redis仍然会可以保持良好的性能，就算发生故障停机，也最多丢失1秒的数据，并且fsync会在后台线程执行，主线程可以继续努力的处理命令请求）。
2.由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek,即使出现了宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在redis下一次启动之前，可以通过redis-check-aof工具来解决数据一致性问题
3.redis可以在AOF文件体积变得过大时，自动的在后台对AOF进行重写，重写后的新AOF文件包含了恢复当前数据集所需最小命令集合。整个重写操作绝对安全，因为在redis创建新的AOF文件过程中，现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕，redis就会从旧的AOF文件切换到新的AOF文件，并开放式对新AOF 文件进行追加操作。
4、AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数的重建
注意： 如果执行了flushall ,在未rewrite之前，先停止redis，在通过修改AOF文件删掉flushall那行，启动redis,还可以恢复flushall以前的数据。但是rewrite之后，aof文件就会被清空，那就无法恢复了。
redis-check-aof --fix appendonly.aof
AOF模式缺点
1、即使有些操做是重复的也会全部记录，AOF的文件要大于RDB文件
2、AOF在恢复大数据集时的速度比RDB的恢复速度慢
3、根据fsync策略不同，AOF速度可能会慢于RDB
4、bug出现的可能性更多
选择RDB还是AOF ?
如果主要充当缓存功能，或者可以承受数分钟数据的丢失，通常生产环境一般只需启用RDB即可，这也是默认值
如果数据需要持久保存，一点也不能丢失，可以选择同时开启RDB和AOF,一般不建议只开启AOF.