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 value1OKredis> set key2 value2OKredis> set key1 value3OK 然后查看Redis路径下的文件：bingyue@ubuntu:/data/redis-3.0.3$ cat appendonly.aofset   $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 100auto-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$4key2$6value2*3$3SET$4key1$6value3

虽然每次执行更改，AOF文件都会记录，但实际上由于操作系统的缓存机制，

默认情况下系统会每30秒执行一次同步，将硬盘缓存中的数据真正写入到硬盘， 这中间如果应用发生异常则不能保存这部分数据。

Redis可以配置在写入AOF文件时执行同步操作的规则：

# appendfsync always 每次写入都会执行同步操作

appendfsync everysec 每秒进行一次同步# appendfsync no 不主动进行同步

一般来说每秒钟进行同步已经足够，这也是Redis默认的规则。