Redis 持久化

作为跟memcached的主要区别 之一， Redis支持数据的持久化。 通过数据持久化，Redis可以把数据同步的磁盘， 如果Redis发生异常或是服务器发生故障，可以从磁盘的数据恢复到内存数据。Redis支持两种数据的持久化方式RDB 和 AOF接下来分别从数据格式，工作原理， 优缺点， 配置方式和恢复方式几个方面分别介绍RDB和AOF持久化方式。

可以关闭redis的持久化，这时redis像memcached一样作为一个纯缓存使用。 也可以同事启用RDB和AOP两种持久化的方式，如果redis故障重启，会优先选择AOF文件进行恢复。

１　RDB：RDB 文件本质是一份内存快照，保存了创建RDB文件 那一时间点的内存全量数据。RDB文件采用二进制格式。

RDB 保存快照流程：
系统触发RDB后， Redis会调用fork产生一个子进程， 子进程会把当前的的内存数据集，保存倒一个临时文件，dump完成之后，会用临时文件替换dump.rdb文件， 完成一次快照。 这里利用了子进程写时复制（copy-on-right)的原理，子进程和父进程共享一份数据，因为子进程只做快照，没有写操作，并不会引起重新分配内存。 但是在子进程做快照期间，如果客户端有大量的更新操作，会引起内存重新分配，导致性能下降。

RDB优点：
RDB文件是单个文件保存全量数据在某个时间点的快照，易于备份。
RDB方式下，Redis性能较高，因为快照是异步的方式由子进程完成， 主进程所做的只是fork()出子进程，剩余的工作由子进程完成。主进程不会涉及磁盘IO操作。
如果数据集较大，RDB恢复的时间更快， 因为RDB文件是内存文件的快照，可以直接写入内存。而AOF文件，是可执行的命令需要重放redis命令才能恢复。

RDB缺点：
如果发生故障，RDB方式丢失的数据较多。 由于平衡性能和保存快照的频率， 一般配置会5分钟或者更多时间保存一次快照。
RDB快照需要经常fork()系统调用生成子进程，如果数据集较大， fork()会花费比较多的时间，会导致redis不能相应客户端的请求几个毫秒甚至1秒。AOF也在rewritelog的时候也会fork(), 但是可以调整重写log的频率， 而不用影响持久性（durability)。

RDB配置：

save 900 1         #900秒后，如果至少1个key 变化
save 300 10        #300秒后，如果至少10个key变化
save 60 10000      #60秒后，如果至少10000个key变化

dbfilename dump.rdb  # dump文件的名字
dir        ./        # dump文件和AOF文件的存放目录

关闭RDB持久化有两种方式：
1，在配置文件comment out 所有的save配置， 重启redis
2，通过redis-cli命令， redis-cli config set save "" , 可以关闭RDB持久化的保存点，不用重启即可生效。但是这种方式不会影响倒配置文件， redis重启后按照配置文件启动

save 和 bgsave 可以触发RDB快照，及时没有到快照保存点：
save:   主线程保存dump.rdb文件，不用fork子进程
bgsave: fork()子进程，子进程负责dump 内存数据集到 dump.rdb文件

2 AOF： AOF持久化方式会记录每一次服务器接收到的写操作，这些log已以redis协议存储，是程序员可读的. AOF log其实就是redis的redo log. AOF log 以增量追加的方式写到appendonly.aof文件。redis 重启之后会读取AOF log, 并重放其中的命令，来回复之前的内存数据集。当redis AOF log文件太大之后，AOF会启用重写机制，例如inc val 1 到100， 会有100条指令， 在AOF log 中会有100条记录， 重写之后只保存最后的状态，减少AOF log文件大小。 AOF重写也是通过fork子进程的方式来完成。

AOF 工作流程：

redis Server收到客户端的请求之后，redis主进程更新内存数据集，然后返回客户端，之后会把收到的写请求写到AOF log文件。 AOF和RDB两种方式都是调用write()直接使用内核的文件系统，内核会对文件(page cache)和磁盘(buffer cache)进行缓存缓存。

AOF优点：
AOF更加耐久（即服务器出现故障，损失的的数据更少）。AOF可以配置，no fsync //redis不主动调用fsync刷盘   fsync every second //redis每秒调用fsync一次刷盘， fsync every request//一个写请求过来都会调用fsync刷盘。默认配置每秒钟fsync一次，性能非常不错。 fsync是用一个backgroud thread来处理的但是fsync会阻塞主线程的write. 只有fsync完成后， 主线程才能调用write写入AOF log文件。 见以下redis说明
./redis.conf
# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.

AOF是一个只能追加（append only file)的文件，没有seek操作，即使发生outage, 也没有文件corruption的风险。即使AOF log文件尾部由于某些原因，写入了不完整的命令， 也可以使用redis-check-aof容易的修复。
 AOF具有重写功能，而且重写是采用子进程的方式完成，不影响主进程处理客户端请求。而且在重写的过程中，会把新的写命令缓存起来，重写完成后，新的AOF文件替换老的AOF文件后，把缓存的命令写到新的AOF文件。
AOF缺点：
对于同样的内存数据集，通常AOF文件比RDB文件大。

使用同样的fsync策略， AOF会比RDB慢. 同样在故障恢复的过程中， RDB会比AOF模式恢复的更快。

AOF配置：
appendonly yes  #启用appendonly 持久化
appendfilename "appendonly.aof"  #AOF log文件名字
# appendfsync always        #每次写请求调用write之后，调用fsync
appendfsync everysec        #每秒种调用fsync一次
# appendfsync no            #不主动调用fsync， 依赖kernel行为， 大概30秒调用一次
no-appendfsync-on-rewrite no  #在rewrite期间，是否调用fsync.
auto-aof-rewrite-percentage 100 #AOF 重写的触发条件
auto-aof-rewrite-min-size 64mb

BGREWRITEAOF :redis命令，触发AOF log重写
 
恢复coruptted AOF文件
$ redis-check-aof --fix  ./appendonly.aof