Redis实战（11）高级特性（3）持久化

redis 是一个支持持久化的内存数据库，也就是说redis 需要经常将内存中的数据同步到磁盘

来保证持久化。redis 支持两种持久化方式，一种是Snapshotting（快照）也是默认方式，另

一种是Append-only file（缩写aof）的方式。下面分别介绍:

一、snapshotting 方式

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,

默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。

我们可以配置redis在n 秒内如果超过m 个key 被修改就自动做快照，

下面是默认的快照保存配置

1

2

3

<code>save 900 1 </code><code>#900 秒内如果超过1 个key 被修改，则发起快照保存</code>

<code>save 300 10 </code><code>#300 秒内容如超过10 个key 被修改，则发起快照保存</code>

<code>save 60 10000</code>

下面介绍详细的快照保存过程:

1、redis 调用fork,现在有了子进程和父进程。

2.、父进程继续处理client 请求，子进程负责将内存内容写入到临时文件。由于os 的实时复

制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os 会为父

进程要修改的页面创建副本，而不是写共享的页面。所以子进程地址空间内的数据是fork

时刻整个数据库的一个快照。

3、当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

client 也可以使用save 或者bgsave 命令通知redis 做一次快照持久化。save 操作是在主线程

中保存快照的，由于redis 是用一个主线程来处理所有client 的请求，这种方式会阻塞所有

client 请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整

写入到磁盘一次，并不是增量的只同步变更数据。如果数据量大的话，而且写操作比较多，

必然会引起大量的磁盘io 操作，可能会严重影响性能。

下面将演示各种场景的数据库持久化情况

首先在redis.conf配置文件中配置log日志

<a href="http://blog.51cto.com/attachment/201312/204253940.png" target="_blank"></a>

然后我们进行如下操作：

<a href="http://blog.51cto.com/attachment/201312/203032247.png" target="_blank"></a>

查看日志文件

<a href="http://blog.51cto.com/attachment/201312/204220110.png" target="_blank"></a>

 从日志可以看出，数据库做了一个存盘的操作，将内存的数据写入磁盘了。正常的话，磁盘

上会产生一个dump 文件，用于保存数据库快照，我们来验证一下:

 硬盘上已经产生了一个数据库快照了。这时侯我们再将redis 启动，看键值还是否真的持久

化到硬盘了。

<a href="http://blog.51cto.com/attachment/201312/204449573.png" target="_blank"></a>

二、aof方式

另外由于快照方式是在一定间隔时间做一次的，所以如果redis 意外down 掉的话，就会丢

失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof 持久化

方式。

下面介绍Append-only file:

aof 比快照方式有更好的持久化性，是由于在使用aof 持久化方式时,redis 会将每一个收到

的写命令都通过write 函数追加到文件中(默认是appendonly.aof)。当redis 重启时会通过重

新执行文件中保存的写命令来在内存中重建整个数据库的内容。

当然由于os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样aof 方式的持久化也还是有可能会丢失部分修改。

不过我们可以通过配置文件告诉redis 我们想要通过fsync 函数强制os 写入

到磁盘的时机。有三种方式如下（默认是：每秒fsync 一次）

4

<code>appendonly </code><code>yes</code> <code>#启用aof 持久化方式</code>

<code>appendfsync always </code><code>#收到写命令就立即写入磁盘，最慢，但是保证完全的持久化</code>

<code>appendfsync everysec </code><code>#每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中</code>

<code>appendfsync no </code><code>#完全依赖os，性能最好,持久化没保证</code>

接下来我们以实例说明用法:

修改配置文件：

<a href="http://blog.51cto.com/attachment/201312/205352695.png" target="_blank"></a>

进行一下操作：

<a href="http://blog.51cto.com/attachment/201312/205201138.png" target="_blank"></a>

我们先设置2 个键值对，然后我们看一下系统中有没有产生appendonly.aof 文件

<a href="http://blog.51cto.com/attachment/201312/205455156.png" target="_blank"></a>

结果证明产生了，接着我们将redis 再次启动后来看一下数据是否还在

<a href="http://blog.51cto.com/attachment/201312/205537863.png" target="_blank"></a>

数据还存在系统中，说明系统是在启动时执行了一下从磁盘到内存的load 数据的过程。

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test

命令100 次，文件中必须保存全部的100 条命令，其实有99 条都是多余的。因为要恢复数

据库的状态其实文件中保存一条set test 100 就够了。为了压缩aof 的持久化文件。redis 提

供了bgrewriteaof 命令。收到此命令redis 将使用与快照类似的方式将内存中的数据以命令

的方式保存到临时文件中，最后替换原来的文件。具体过程如下

1、redis 调用fork ，现在有父子两个进程

2、子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令

3、父进程继续处理client 请求，除了把写命令写入到原来的aof 文件中。同时把收到的写命

令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。

4、当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然

后父进程把缓存的写命令也写入到临时文件。

5、现在父进程可以使用临时文件替换老的aof 文件，并重命名，后面收到的写命令也开始

往新的aof 文件中追加。

需要注意到是重写aof 文件的操作，并没有读取旧的aof 文件，而是将整个内存中的数据库

内容用命令的方式重写了一个新的aof 文件,这点和快照有点类似。接来我们看一下实际的例

子:

我们先调用5 次incr age 命令:

<a href="http://blog.51cto.com/attachment/201312/210429407.png" target="_blank"></a>

接下来我们看一下日志文件的大小

<a href="http://blog.51cto.com/attachment/201312/210537573.png" target="_blank"></a>

大小为533 个字节，接下来我们调用一下bgrewriteaof 命令将内存中的数据重新刷到磁盘的

日志文件中

<a href="http://blog.51cto.com/attachment/201312/210706678.png" target="_blank"></a>

再看一下磁盘上的日志文件大小

<a href="http://blog.51cto.com/attachment/201312/210751278.png" target="_blank"></a>

日志文件大小变为84 个字节了，说明原来日志中的重复记录已被刷新掉了。

本文转自shayang8851CTO博客，原文链接：http://blog.51cto.com/janephp/1340039，如需转载请自行联系原作者