Redis相比Memcached的很大一个优势是支持数据的持久化，
通常持久化的场景一个是做数据库使用，另一个是Redis在做缓存服务器时，防止缓存失效。
Redis的持久化主要有快照Snapshotting和AOF日志文件两种方式。
前者会根据配置的规则定时将内存中的数据持久化到硬盘上，
后者则是在每次执行写命令之后将命令记录下来。
>>RDB方式
Redis是会以快照的形式将数据持久化到磁盘上。
默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中，
可以通过配置文件中的dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。
如何执行快照保存
Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
父进程继续处理来自客户端的请求，子进程开始将内存中的数据写入硬盘中的临时文件；
当子进程写完所有的数据后，用该临时文件替换旧的RDB文件，至此，一次快照操作完成。
需要注意的是：
在执行fork是时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，
即fork函数发生的一刻，父进程和子进程共享同一块内存数据，当父进程需要修改其中的某片数据（如执行写命令）时，
操作系统会将该片数据复制一份以保证子进程不受影响，所以RDB文件存储的是执行fork操作那一刻的内存数据。
所以RDB方式理论上是会存在丢数据的情况的(fork之后修改的的那些没有写进RDB文件)。
RDB文件是经过压缩处理的二进制文件，所以占用的空间会小于内存中数据的大小，更有利于传输。
Redis启动时会自动读取RDB快照文件，将数据从硬盘载入到内存。
Redis执行快照的规则
1.根据配置规则进行自动快照
下面是默认的快照保存配置：
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内如果超过10个key被修改，则发起快照保存
save 60 10000 #60秒内如果超过10000个key被修改，则发起快照保存
每个快照条件是||的关系，满足一个系统就会执行。
2.用户执行SAVE, BGSAVE命令
执行SAVE命令时，Redis会同步进行快照操作，期间会阻塞所有来自客户端的请求；
执行BGSAVE命令时，这个命令是在后台异步进行的，进行快照操作的同时还能处理来自客户端的请求。
3.执行复制（replication）时
当使用多台服务器时，Redis提供了复制功能，可以实现自动同步。复制的原理同样是使用快照，
主数据库在后台保存快照，并且将快照期间的客户端请求命令缓存起来，快照完成后，将快照文件和缓存命令一起发送给从数据库，从而实现数据的同步。
>>AOF方式
默认情况下，Redis没有开启AOF方式的持久化，可以查看配置文件：
appendonly no
需要在配置文件中将appendonly参数开启：
appendonly yes
开启之后，Redis每执行一条写命令就会将该命令写入硬盘中的AOF文件。
AOF文件和RDB文件在同一路径下，可以通过appendonlyfilename参数修改配置：
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
AOF的实现
AOF以纯文本的形式记录了Redis执行的写命令，我修改上面的配置后，重启Redis，执行下面的命令：
redis> set key1 value1
OK
redis> set key2 value2
OK
redis> set key1 value3
OK
然后查看Redis路径下的文件：
[email protected]:/data/redis-3.0.3$ cat appendonly.aof
set
$4
key1
$6
value1
*3
$3
set
$4
key2
$6
value2
*3
$3
set
$4
key1
$6
value3
Redis重写
注意我上面做了一次覆盖的操作，并且被AOF文件记录下来了，
实际使用中遇到反复修改的数据，这么做是很浪费资源的，
Redis可以清除AOF文件中的无效的命令，即Redis的重写，并且可以在配置文件中配置重写规则：
# Automatic rewrite of the append only file.
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
配置文件中对这两项做了说明：
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
即当AOF文件大小超过最近一次重写时文件的百分之多少，并且AOF文件大于配置的最小值时，触发Redis重写操作。
同时可以执行BGREWRITEAOF命令，手动进行重写，
我做了一次这个操作，再查看AOF文件：
SET
$4
key2
$6
value2
*3
$3
SET
$4
key1
$6
value3
虽然每次执行更改，AOF文件都会记录，但实际上由于操作系统的缓存机制，
默认情况下系统会每30秒执行一次同步，将硬盘缓存中的数据真正写入到硬盘，
这中间如果应用发生异常则不能保存这部分数据。
Redis可以配置在写入AOF文件时执行同步操作的规则：
# appendfsync always 每次写入都会执行同步操作
appendfsync everysec 每秒进行一次同步
# appendfsync no 不主动进行同步
一般来说每秒钟进行同步已经足够，这也是Redis默认的规则。