Redis提供的持久化机制（RDB和AOF）

Redis提供的持久化机制　

　　Redis是一种面向“key-value”类型数据的分布式NoSQL数据库系统，具备高性能、持久存储、适应高并发应用场景等优点。它虽然起步较晚，但发展却十分迅速。 

近日，Redis的做者在博客中写到，他看到的全部针对Redis的讨论中，对Redis持久化的误解是最大的，因而他写了一篇长文来对Redis的持久化进行了系统性的论述。

文章主要包含三个方面：Redis持久化是如何工做的、这一性能是否可靠以及和其它类型的数据库比较。如下为文章内容： 

1、Redis持久化是如何工做的？ 

　　什么是持久化？简单来说就是将数据放到断电后数据不会丢失的设备中，也就是咱们一般理解的硬盘上。

首先咱们来看一下数据库在进行写操做时到底作了哪些事，主要有下面五个过程： 

 

• 客户端向服务端发送写操做（数据在客户端的内存中）。
• 数据库服务端接收到写请求的数据（数据在服务端的内存中）。
• 服务端调用write这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）。
• 操做系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）。
• 磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）。

 

故障分析 

写操做大体有上面5个流程，下面咱们结合上面的5个流程看一下各类级别的故障： 

 

• 当数据库系统故障时，这时候系统内核仍是无缺的。那么此时只要咱们执行完了第3步，那么数据就是安全的，由于后续操做系统会来完成后面几步，保证数据最终会落到磁盘上。
• 当系统断电时，这时候上面5项中提到的全部缓存都会失效，而且数据库和操做系统都会中止工做。因此只有当数据在完成第5步后，才能保证在断电后数据不丢失。

 

经过上面5步的了解，可能咱们会但愿搞清下面一些问题： 

• 数据库多长时间调用一次write，将数据写到内核缓冲区？
• 内核多长时间会将系统缓冲区中的数据写到磁盘控制器？
• 磁盘控制器又在何时把缓存中的数据写到物理介质上？

 

　　对于第一个问题，一般数据库层面会进行全面控制。

　　而对第二个问题，操做系统有其默认的策略，可是咱们也能够经过POSIX API提供的fsync系列命令强制操做系统将数据从内核区写到磁盘控制器上。

　　对于第三个问题，好像数据库已经没法触及，但实际上，大多数状况下磁盘缓存是被设置关闭的，或者是只开启为读缓存，也就是说写操做不会进行缓存，直接写到磁盘。

　　建议的作法是仅仅当你的磁盘设备有备用电池时才开启写缓存。 

数据损坏 

　　所谓数据损坏，就是数据没法恢复，上面咱们讲的都是如何保证数据是确实写到磁盘上去，可是写到磁盘上可能并不意味着数据不会损坏。好比咱们可能一次写请求会进行两次不一样的写操做，当意外发生时，可能会致使一次写操做安全完成，可是另外一次尚未进行。若是数据库的数据文件结构组织不合理，可能就会致使数据彻底不能恢复的情况出现。 

这里一般也有三种策略来组织数据，以防止数据文件损坏到没法恢复的状况： 

• 第一种是最粗糙的处理，就是不经过数据的组织形式保证数据的可恢复性。而是经过配置数据同步备份的方式，在数据文件损坏后经过数据备份来进行恢复。实际上MongoDB在不开启操做日志，经过配置Replica Sets时就是这种状况。
• 另外一种是在上面基础上添加一个操做日志，每次操做时记一下操做的行为，这样咱们能够经过操做日志来进行数据恢复。由于操做日志是顺序追加的方式写的，因此不会出现操做日志也没法恢复的状况。这也相似于MongoDB开启了操做日志的状况。
• 更保险的作法是数据库不进行旧数据的修改，只是以追加方式去完成写操做，这样数据自己就是一份日志，这样就永远不会出现数据没法恢复的状况了。实际上CouchDB就是此作法的优秀范例。

　

二 、Redis提供了RDB持久化和AOF持久化

RDB机制的优点和略施

　　RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

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

能够经过配置设置自动作快照持久化的方式。咱们能够配置redis在n秒内若是超过m个key被修改就自动作快照，下面是默认的快照保存配置

save 900 1 #900秒内若是超过1个key被修改，则发起快照保存 save 300 10 #300秒内容如超过10个key被修改，则发起快照保存 save 60 10000 

RDB文件保存过程

• redis调用fork,如今有了子进程和父进程。
• 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。因为os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面建立副本，而不是写共享的页面。因此子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。
• 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，而后子进程退出。

client 也可使用save或者bgsave命令通知redis作一次快照持久化。save操做是在主线程中保存快照的，因为redis是用一个主线程来处理全部 client的请求，这种方式会阻塞全部client请求。因此不推荐使用。

另外一点须要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。若是数据量大的话，并且写操做比较多，必然会引发大量的磁盘io操做，可能会严重影响性能。

优点

• 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样很是方便进行备份。好比你可能打算没1天归档一些数据。
• 方便备份，咱们能够很容易的将一个一个RDB文件移动到其余的存储介质上
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• RDB 能够最大化 Redis 的性能：父进程在保存 RDB 文件时惟一要作的就是 fork 出一个子进程，而后这个子进程就会处理接下来的全部保存工做，父进程无须执行任何磁盘 I/O 操做。

劣势

• 若是你须要尽可能避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 容许你设置不一样的保存点（save point）来控制保存 RDB 文件的频率， 可是， 由于RDB 文件须要保存整个数据集的状态， 因此它并非一个轻松的操做。 所以你可能会至少 5 分钟才保存一次 RDB 文件。 在这种状况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
• 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工做。 在数据集比较庞大时， fork() 可能会很是耗时，形成服务器在某某毫秒内中止处理客户端； 若是数据集很是巨大，而且 CPU 时间很是紧张的话，那么这种中止时间甚至可能会长达整整一秒。 虽然 AOF 重写也须要进行 fork() ，但不管 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF文件保存过程

redis会将每个收到的写命令都经过write函数追加到文件中(默认是 appendonly.aof)。

当redis重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。固然因为os会在内核中缓存 write作的修改，因此可能不是当即写到磁盘上。这样aof方式的持久化也仍是有可能会丢失部分修改。不过咱们能够经过配置文件告诉redis咱们想要 经过fsync函数强制os写入到磁盘的时机。有三种方式以下（默认是：每秒fsync一次）

appendonly yes              //启用aof持久化方式 # appendfsync always //每次收到写命令就当即强制写入磁盘，最慢的，可是保证彻底的持久化，不推荐使用 appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面作了很好的折中，推荐 # appendfsync no //彻底依赖os，性能最好,持久化没保证

aof 的方式也同时带来了另外一个问题。持久化文件会变的愈来愈大。例如咱们调用incr test命令100次，文件中必须保存所有的100条命令，其实有99条都是多余的。由于要恢复数据库的状态其实文件中保存一条set test 100就够了。

为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照相似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。具体过程以下

• redis调用fork ，如今有父子两个进程
• 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
• 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证若是子进程重写失败的话并不会出问题。
• 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。而后父进程把缓存的写命令也写入到临时文件。
• 如今父进程可使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

须要注意到是重写aof文件的操做，并无读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点相似。

优点

• 使用 AOF 持久化会让 Redis 变得很是耐久（much more durable）：你能够设置不一样的 fsync 策略，好比无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然能够保持良好的性能，而且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，因此主线程能够继续努力地处理命令请求）。

• AOF 文件是一个只进行追加操做的日志文件（append only log）， 所以对 AOF 文件的写入不须要进行 seek ， 即便日志由于某些缘由而包含了未写入完整的命令（好比写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也能够轻易地修复这种问题。
  Redis 能够在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操做是绝对安全的，由于 Redis 在建立新 AOF 文件的过程当中，会继续将命令追加到现有的 AOF 文件里面，即便重写过程当中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件建立完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操做。

• AOF 文件有序地保存了对数据库执行的全部写入操做， 这些写入操做以 Redis 协议的格式保存， 所以 AOF 文件的内容很是容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也很是简单： 举个例子， 若是你不当心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要中止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就能够将数据集恢复到 FLUSHALL 执行以前的状态。

劣势

• 对于相同的数据集来讲，AOF 文件的体积一般要大于 RDB 文件的体积。

• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在通常状况下， 每秒 fsync 的性能依然很是高， 而关闭 fsync 可让 AOF 的速度和 RDB 同样快， 即便在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 能够提供更有保证的最大延迟时间（latency）。

• AOF 在过去曾经发生过这样的 bug ： 由于个别命令的缘由，致使 AOF 文件在从新载入时，没法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引发过这样的 bug 。） 测试套件里为这种状况添加了测试： 它们会自动生成随机的、复杂的数据集， 并经过从新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 可是对比来讲， RDB 几乎是不可能出现这种 bug 的。

抉择

通常来讲， 若是想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

若是你很是关心你的数据， 但仍然能够承受数分钟之内的数据丢失， 那么你能够只使用 RDB 持久化。

其他状况我我的喜爱选择AOF

 

三

1. Snapshotting:
缺省状况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，咱们也能够经过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件以后，咱们搜索save，能够看到下面的配置信息：
save 900 1 #在900秒(15分钟)以后，若是至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)以后，若是至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)以后，若是至少有10000个key发生变化，则dump内存快照。

2. Dump快照的机制：
1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操做后，再用临时文件替换老的文件。

5.4.3. AOF文件：
上面已经屡次讲过，RDB的快照定时dump机制没法保证很好的数据持久性。若是咱们的应用确实很是关注此点，咱们能够考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，若是须要使用AOF，则须要修改配置文件中的如下条目：
将appendonly no改成appendonly yes
从如今起，Redis在每一次接收到数据修改的命令以后，都会将其追加到AOF文件中。在Redis下一次从新启动时，须要加载AOF文件中的信息来构建最新的数据到内存中。

5.4.5. AOF的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不一样步。高效可是数据不会被持久化。

5.4.6. 如何修复坏损的AOF文件：
1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
3). 用修复后的AOF文件从新启动Redis服务器。

5.4.7. Redis的数据备份：
在Redis中咱们能够经过copy的方式在线备份正在运行的Redis数据文件。这是由于RDB文件一旦被生成以后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，以后在利用rename函数原子性的将临时文件更名为原有的数据文件名。所以咱们能够说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，咱们就能够经过建立cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。

5.五、当即写入

//当即保存，同步保存
    public static void syncSave() throws Exception{
        Jedis jedis=new Jedis("127.0.0.1",6379);
        for (int i = 0; i <1000; i++) {
            jedis.set("key"+i, "Hello"+i);
            System.out.println("设置key"+i+"的数据到redis");
            Thread.sleep(2);
        }
        //执行保存，会在服务器下生成一个dump.rdb数据库文件
        jedis.save();
        jedis.close();
        System.out.println("写入完成");
    }

运行结果：

这里的save方法是同步的，没有写入完成前不执行后面的代码。

5.六、异步写入

    //异步保存
    public static void asyncSave() throws Exception{
        Jedis jedis=new Jedis("127.0.0.1",6379);
        for (int i = 0; i <1000; i++) {
            jedis.set("key"+i, "Hello"+i);
            System.out.println("设置key"+i+"的数据到redis");
            Thread.sleep(2);
        }
        //执行异步保存，会在服务器下生成一个dump.rdb数据库文件
        jedis.bgsave();
        jedis.close();
        System.out.println("写入完成");
    }

若是数据量很是大，要保存的内容不少，建议使用bgsave，若是内容少则可使用save方法。关于各方式的比较源自网友的博客。

 

一、Redis的第一个持久化策略：RDB快照 

Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，而后在子进程中循环全部的数据，将数据写成为RDB文件。 

咱们能够经过Redis的save指令来配置RDB快照生成的时机，好比你能够配置当10分钟之内有100次写入就生成快照，也能够配置当1小时内有1000次写入就生成快照，也能够多个规则一块儿实施。这些规则的定义就在Redis的配置文件中，你也能够经过Redis的CONFIG SET命令在Redis运行时设置规则，不须要重启Redis。 

Redis的RDB文件不会坏掉，由于其写操做是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，而后经过原子性rename系统调用将临时文件重命名为RDB文件，这样在任什么时候候出现故障，Redis的RDB文件都老是可用的。 

同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。 

可是，咱们能够很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么咱们的RDB文件中保存的数据并非全新的，从上次RDB文件生成到 Redis停机这段时间的数据所有丢掉了。在某些业务下，这是能够忍受的，咱们也推荐这些业务使用RDB的方式进行持久化，由于开启RDB的代价并不高。 可是对于另一些对数据安全性要求极高的应用，没法容忍数据丢失的应用，RDB就无能为力了，因此Redis引入了另外一个重要的持久化机制：AOF日志。 

二、Redis的第二个持久化策略：AOF日志 

AOF日志的全称是Append Only File，从名字上咱们就能看出来，它是一个追加写入的日志文件。与通常数据库不一样的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。好比咱们进行以下实验，使用Redis2.6 版本，在启动命令参数中设置开启AOF功能：

./redis-server --appendonly yes

　　而后咱们执行以下的命令：

redis 127.0.0.1:6379> set  key1 Hello OK redis 127.0.0.1:6379> append key1 " World!" (integer) 12 redis 127.0.0.1:6379> del key1 (integer) 1 redis 127.0.0.1:6379> del non_existing_key (integer) 0

　　这时咱们查看AOF日志文件，就会获得以下内容：

$ cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $4 key1 $5 Hello *3 $6 append $4 key1 $7   World! *2 $3 del $4 key1

　　能够看到，写操做都生成了一条相应的命令做为日志。其中值得注意的是最后一个del命令，它并无被记录在AOF日志中，这是由于Redis判断出 这个命令不会对当前数据集作出修改。因此不须要记录这个无用的写命令。另外AOF日志也不是彻底按客户端的请求来生成日志的，好比命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，由于浮点数操做可能在不一样的系统上会不一样，因此为了不同一份日志在不一样的系统上生成不一样的数据集，因此这里只将操做后的结果经过SET来记录。 

AOF重写 

你能够会想，每一条写命令都生成一条日志，那么AOF文件是否是会很大？答案是确定的，AOF文件会愈来愈大，因此Redis又提供了一个功能，叫作AOF rewrite。其功能就是从新生成一份AOF文件，新的AOF文件中一条记录的操做只会有一次，而不像一份老文件那样，可能记录了对同一个值的屡次操做。其生成过程和RDB相似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程当中，全部的写操做日志仍是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操做完成后，会将全部缓冲区中的日志一次性写入到临时文件中。而后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。 

2、Redis持久化性能是否可靠？ 

从上面的流程咱们可以看到，RDB是顺序IO操做，性能很高。而同时在经过RDB文件进行数据库恢复的时候，也是顺序的读取数据加载到内存中。因此也不会形成磁盘的随机读取错误。 

而AOF是一个写文件操做，其目的是将操做日志写到磁盘上，因此它也一样会遇到咱们上面说的写操做的5个流程。那么写AOF的操做安全性又有多高呢？实际上这是能够设置的，在Redis中对AOF调用write写入后，什么时候再调用fsync将其写到磁盘上，经过appendfsync选项来控制，下面appendfsync的三个设置项，安全强度逐渐变强。 

一、appendfsync no 

当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，因此这一切就彻底依赖于操做系统的调试了。对大多数Linux操做系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。 

二、appendfsync everysec 

当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。可是当这一 次的fsync调用时长超过1秒时。Redis会采起延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就无论会执行多长时间都会进行。这时候因为在fsync时文件描述符会被阻塞，因此当前的写操做就会阻塞。 

因此，结论就是：在绝大多数状况下，Redis会每隔一秒进行一次fsync。在最坏的状况下，两秒钟会进行一次fsync操做。 

这一操做在大多数数据库系统中被称为group commit，就是组合屡次写操做的数据，一次性将日志写到磁盘。 

三、appednfsync always 

当设置appendfsync为always时，每一次写操做都会调用一次fsync，这时数据是最安全的，固然，因为每次都会执行fsync，因此其性能也会受到影响。 

对于pipelining有什么不一样？ 

对于pipelining的操做，其具体过程是客户端一次性发送N个命令，而后等待这N个命令的返回结果被一块儿返回。经过采用pipilining 就意味着放弃了对每个命令的返回值确认。因为在这种状况下，N个命令是在同一个执行过程当中执行的。因此当设置appendfsync为everysec 时，可能会有一些误差，由于这N个命令可能执行时间超过1秒甚至2秒。可是能够保证的是，最长时间不会超过这N个命令的执行时间和。 

3、和其它数据库的比较 

上面操做系统层面的数据安全咱们已经讲了不少，其实，不一样的数据库在实现上都大同小异。总之，最后的结论就是，在Redis开启AOF的状况下，其单机数据安全性并不比这些成熟的SQL数据库弱。 

在数据导入方面的比较 

这些持久化的数据有什么用，固然是用于重启后的数据恢复。Redis是一个内存数据库，不管是RDB仍是AOF，都只是其保证数据恢复的措施。因此 Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，从新加载到内存中。相对于MySQL等数据库的启动时间来讲，会长不少，由于MySQL原本是不须要将数据加载到内存中的。 

可是相对来讲，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，一般咱们称之为预热，而在预热完成前，其性能都不会过高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是很是快的。 而在利用RDB和利用AOF启动上，其启动时间有一些差异。RDB的启动时间会更短，缘由有两个，一是RDB文件中每一条数据只有一条记录，不会像 AOF日志那样可能有一条数据的屡次操做记录。因此每条数据只须要写一次就好了。另外一个缘由是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不须要再进行数据编码工做。在CPU消耗上要远小于AOF日志的加载。