Redis 持久化

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。

Redis在实际使用中采用多种不同级别的持久化方式：

1. RDB持久化方式，它可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

2. AOF持久化方式，它会在执行写命令时，将被执行的写命令复制到硬盘里。AOF全称append-only file，记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF 文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。Redis还可以在后台对AOF文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

3. Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下，当Redis重启时，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

4. 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

Redis RDB持久化

快照（snapshotting），它可以将存在于某一时刻的所有数据都写入磁盘里面。 

RDB快照

在默认情况下， Redis将数据库快照保存在名字为dump.rdb的二进制文件中。

你可以对Redis进行设置，让它在“N秒内数据集至少有M个改动”这一条件被满足时，自动保存一次数据集。

你也可以通过调用SAVE或者BGSAVE，手动让Redis进行数据集保存操作。

RDB配置参数

save <seconds> <changes>  
stop-writes-on-bgsave-error yes  
rdbcompression yes  
dbfilename dump.rdb  
dir ./ 

• save：在X秒内如果key有至少X次改变就触发持久化，例如save 900 1的话就是在900秒如果key有至少1次改变就触发持久化。如果想关闭此功能的话，可以把全部save行都注释或删除或者使用save ""。

• stop-writes-on-bgsave-error：在bgsave遇到error的时候是否停止持久化，默认是yes代表是，no代表不是。

• rdbcompression：是否压缩，默认是yes代表是，no代表不是，如果想节省CPU的话就设为no，但是rdb文件会比较大。

• dbfilename：持久化的文件名字，默认是dump.rdb。

• dir：持久化的目录名字，默认是redis.conf所在的目录./。

RDB运作方式 

当Redis需要保存dump.rdb文件时，服务器执行以下操作：

1. Redis调用fork()，同时拥有父进程和子进程。

2. 子进程将数据集写入到一个临时RDB文件中。

3. 当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。

这种工作方式使得Redis可以从写时复制（copy-on-write）机制中获益。

Redis AOF持久化

快照功能并不是非常耐久（durable），如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

AOF追加文件

尽管对于某些程序来说，数据的耐久性并不是最重要的考虑因素，但是对于那些追求完全耐久能力（full durability）的程序来说，快照功能就不太适用了。从1.1版本开始，Redis增加了一种完全耐久的持久化方式， AOF 持久化。

AOF配置参数

appendonly no  
appendfilename "appendonly.aof"  
appendfsync everysec 
dir ./ 

• appendonly：是否启动aof，默认是no代表不启用，yes代表启用。

• appendfilename：aof的文件名，默认是appendonly.aof。

• appendfsync：配置Redis多久才将数据fsync到磁盘一次。该配置有3个选项，默认是everysec代表每秒，足够快（和使用RDB持久化差不多），并且在故障时只会丢失1秒钟的数据；另外还有always代表有改变都触发（每次有新命令追加到AOF文件时就执行一次fsync），性能最差但数据最安全；no代表让OS自己决定什么时候执行，性能最好但数据不安全。推荐（并且也是默认）的措施为每秒fsync一次，这种fsync策略可以兼顾速度和安全性

• dir：和上述是同一个参数（共用），持久化的目录名字，默认是redis.conf所在的目录./。

AOF重写/压缩

因为AOF的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加，AOF文件的体积也会变得越来越大。

举个例子，如果你对一个计数器调用了100次INCR，那么仅仅是为了保存这个计数器的当前值，AOF文件就需要使用100条记录（entry）。

然而在实际上，只使用一条SET命令已经足以保存计数器的当前值了，其余99条记录实际上都是多余的。

为了处理这种情况，Redis支持一种有趣的特性：可以在不打断服务客户端的情况下，对AOF文件进行重建（rebuild）。

执行BGREWRITEAOF命令，Redis将生成一个新的AOF文件，这个文件包含重建当前数据集所需的最少命令。Redis2.2需要自己手动执行BGREWRITEAOF命令； Redis 2.4则可以自动触发AOF重写。

AOF重写相关配置：

no-appendfsync-on-rewrite no  
auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb 

• no-appendfsync-on-rewrite：在aof rewrite的时候上述appendfsync是否暂时停止，默认是no代表不停止，yes代表停止，不会造成I/O资源竞争，性能较前者好。在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。

• auto-aof-rewrite-percentage：自动触发aof rewrite的百分比，默认是100%，就是比上次rewrite的1倍。

• auto-aof-rewrite-min-size：自动触发aof rewrite的最小size，默认是64mb，就是如果size超过64mb，而且是上次执行的1倍，就会自动触发。

AOF运作方式

AOF重写和RDB创建快照一样，都巧妙地利用了写时复制机制。

以下是AOF重写的执行步骤：

1. Redis执行fork()，现在同时拥有父进程和子进程。

2. 子进程开始将新AOF文件的内容写入到临时文件。

3. 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有AOF文件的末尾，这样即使在重写的中途发生停机，现有的AOF文件也还是安全的。

4. 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新AOF文件的末尾。

5. 搞定！现在Redis原子地用新文件替换旧文件，之后所有命令都会直接追加到新AOF文件的末尾。

如果AOF文件出错了，怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了AOF文件出错，那么Redis在重启时会拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏。

当发生这种情况时，可以用以下方法来修复出错的AOF文件：

1. 为现有的AOF文件创建一个备份。

2. 使用Redis附带的redis-check-aof程序，对原来的AOF文件进行修复。

   $ redis-check-aof --fix

3. （可选）使用diff -u对比修复后的AOF文件和原始AOF文件的备份，查看两个文件之间的不同之处。

4. 重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

RDB和AOF比较

Redis的RDB持久化方式和AOF持久化方式各自都有其优缺点。

RDB的优点

• RDB是一个非常紧凑（compact）的文件，它保存了Redis在某个时间点上的数据集。这种文件非常适合用于进行备份，比如说，你可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

• RDB非常适用于灾难恢复（disaster recovery），它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊S3中。

• RDB可以最大化Redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O操作。

• RDB在恢复大数据集时的速度比AOF的恢复速度要快。 

RDB的缺点

• 如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。

• 每次保存RDB的时候，Redis都要fork()出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。虽然AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久化都不会有任何损失。

AOF的优点

• 使用AOF持久化会让Redis变得非常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的缺点

• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。在一般情况下，每秒fsync的性能依然非常高，而关闭fsync可以让AOF的速度和RDB一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间（latency）。

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

RDB和AOF，应如何选择？

一般来说，如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化，但我们并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序的bug。

因为以上提到的种种原因，未来可能会将AOF和RDB整合成单个持久化模型（这是一个长期计划）。

如何从RDB持久化切换到AOF持久化？

在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF：

1. 为最新的dump.rdb文件创建一个备份。

2. 将备份放到一个安全的地方。

3. 执行以下两条命令：

   redis-cli> CONFIG SET appendonly yes
   
   redis-cli> CONFIG SET save ""

4. 确保命令执行之后，数据库的键的数量没有改变。

5. 确保写命令会被正确地追加到AOF文件的末尾。

步骤3执行的第一条命令开启了AOF功能，Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

步骤3执行的第二条命令用于关闭RDB功能。这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

别忘了在redis.conf中打开AOF功能！否则的话，服务器重启之后，之前通过CONFIG SET设置的配置就会被遗忘，程序会按原来的配置来启动服务器。

如何协调RDB和AOF的相互作用？

在版本号大于等于2.4的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行BGSAVE。

这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行，并且用户显示地调用BGREWRITEAOF命令，那么服务器将向用户回复一个OK状态，并告知用户，BGREWRITEAOF已经被预定执行，一旦BGSAVE执行完毕，BGREWRITEAOF就会正式开始。

当Redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据集，因为AOF文件所保存的数据通常是最完整的。