原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。
http://harisxiong.blog.51cto.com/7513022/1584795
Redis是一个开源的高性能键值存储数据库。之所以性能优异，是因为Redis是把所有的数据都存在内存中的。这样会有一个问题：当服务器重启或程序异常崩溃时，Redis的数据就会全部丢失。虽然生产环境中，Redis仅被用于缓存，但是如果能够对其数据做持久化的操作，还是一个不错的选择。
Redis默认支持两种持久话的方式，分别是基于快照形成的RDB文件和基于命令操作存储的AOF文件，接下来笔者就对两种持久化方式做简单的介绍。
RDB（默认开启）
RDB实际上是通过快照来完成持久化操作的，当符合一定条件后，Redis会自动的把内存中的数据写入磁盘。可以通过配置文件中的save选项来设置同步策略。
save 300 10 #代表300s内有10个键值改动就触发数据落地操作。多行save是或的策略。
save "" #设置不进行数据持久化（只写入这一行save）
同样，也可以手动执行SAVE和BGSAVE命令就行持久化。不同之处在于，前者是Redis主进程进行快照，后者是fock子进程进行快照。Redis默认写入RDB文件名为dump.rdb，会存在当前目录。可以通过配置文件的dir和dbfilename执行目录和文件名。
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /data/redis/8001/data
Redis RDB方式的快照过程如下：
redis父进程利用fock函数生成一个子进程
父进程继续接收并处理客户端发来的命令，子进程则将内存中的数据写入硬盘，暂时先写入临时文件。对于正在写入的数据，操作系统会使用写时复制的策略，即复制一份该片数据保证子进程的落地数据不被修改。
当数据写完时，子进程会用临时文件替代现有的RDB文件，这样一次快照就顺利的完成了。
缺点：
使用RDB方式进行持久化有个缺点，就是一旦程序异常退出而不再最后一次触发快照的那一刻，Redis最后一次快照之后的数据会丢失。
AOF（默认未开启）
AOF实际上存储的是纯文本文件，其内容是Redis客户端和服务器通信的原始数据记录。具体文件大家可以编辑appendonly.aof文件查看。
AOF文件重写
使用AOF方式进行数据落地会有一个问题，因为保存的是每次操作命令的过程，可能存在数据冗余。Redis也提供了相关的机制可以对落地文件行进重写，比如对一个变量进行多次赋值操作，重写之后只会保存最后一次的键值。重写过程也有一定的触发条件，默认设置如下：
appendonly yes #打开AOF存储方式（当文件很小时，可能数据会有较多冗余）
appendfilename appendonly.aof #设置AOF存储文件名字
auto-aof-rewrite-percentage 100 #当AOF文件超过上一次重写时大小的百分之多少时开始重写
auto-aof-rewrite-min-size 64mb #限制允许重写的最小AOF文件大小
重写操作也可以在客户端手动执行命令BGREWRITEAOF触发。重写的过程先在内存中完成，之后再写入磁盘文件。过程类似于RDB文件落地方式。
由于操作系统由于操作系统的缓存机制，实际上每次文件落地并没有真正的写入硬盘，而是写入磁盘的缓存文件。默认操作系统每隔30s会写一次数据。但是当系统异常退出还是会有数据丢失，所以开启AOF的redis需要设置操作系统缓存落地时间，默认/s。详细设置选项如下：
#appendfsync always #always表示每个命令都执行落地
appendfsync everysec #everysec表示每s执行一次
#appendfsync no #no不主动同步，交给操作系统执行，默认30s
备注：当同时开启RDB和AOF方式的持久化，Redis会选择AOF方式。因为该方式可能丢失的数据更少。但是时间较RDB恢复方式慢！
