Redis持久化persistence

一、前言

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。

Redis提供两种方式进行持久化，

一种是RDB（）持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），
另外一种是AOF（append-only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

二、Redis 持久化

Redis 提供了不同级别的持久化方式：

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:

RDB的优点

RDB是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集
由于RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者Amazon S3（可能加密），非常适用于灾难恢复
RDB在保存RDB文件时，父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些

RDB的缺点

如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据.
RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续1秒，AOF也需要fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。

AOF 优点

使用AOF会让你的Redis更加耐久，你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync。使用默认的每秒fsync策略，Redis的性能依然很好(fsync是由后台线程进行处理的，主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失1秒的数据。
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）。

三、如何选择使用哪种持久化方式？

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

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

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

Note: 因为以上提到的种种原因，未来我们可能会将AOF和RDB整合成单个持久化模型。

快照

在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。你可以对Redis进行设置，让它在“N秒内数据集至少有M个改动”这一条件被满足时，自动保存一次数据集。你也可以通过调用SAVE或者BGSAVE，手动让Redis进行数据集保存操作。

比如说，以下设置会让Redis在满足“60秒内有至少有1000个键被改动”这一条件时，自动保存一次数据集：

save 60 1000

这种持久化方式被称为快照 snapshotting.

工作方式

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

Redis调用fork()，同时拥有父进程和子进程。
子进程将数据集写入到一个临时RDB文件中。
当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。

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

只追加操作的文件（AOF）

快照功能并不是非常耐久（durable）：如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从1.1版本开始，Redis增加了一种完全耐久的持久化方式：AOF持久化。

你可以在配置文件中打开AOF方式:

appendonly yes

从现在开始，每当Redis执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。

日志重写

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

举个例子，如果你对一个计数器调用了100次INCR ，那么仅仅是为了保存这个计数器的当前值，AOF文件就需要使用100条记录（entry）。然而在实际上，只使用一条SET命令已经足以保存计数器的当前值了，其余99条记录实际上都是多余的。

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

执行BGREWRITEAOF命令，Redis将生成一个新的AOF文件，这个文件包含重建当前数据集所需的最少命令。

Redis 2.2需要自己手动执行 BGREWRITEAOF 命令；

Redis 2.4则可以自动触发AOF重写，具体信息请查看2.4的示例配置文件。

AOF有多耐久性?

你可以配置Redis多久才将数据fsync到磁盘一次。有三种方式：

每次有新命令追加到AOF文件时就执行一次fsync：非常慢，也非常安全。
每秒fsync一次：足够快（和使用RDB 持久化差不多），并且在故障时只会丢失1秒钟的数据。
从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒fsync 一次，这种fsync策略可以兼顾速度和安全性。

四、如果AOF文件损坏了怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了AOF文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏。当发生这种情况时，可以用以下方法来修复出错的AOF文件：

为现有的AOF文件创建一个备份。
使用Redis附带的redis-check-aof程序，对原来的AOF文件进行修复：$ redis-check-aof –fix
使用diff -u对比修复后的AOF文件和原始AOF文件的备份，查看两个文件之间的不同之处。（可选）
重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

工作原理

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

Redis执行fork()，现在同时拥有父进程和子进程。
子进程开始将新AOF文件的内容写入到临时文件。
对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有AOF文件的末尾，这样即使在重写的中途发生停机，现有的AOF文件也还是安全的。
当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新AOF文件的末尾。
现在Redis原子地用新文件替换旧文件，之后所有命令都会直接追加到新AOF文件的末尾。

五、怎样从RDB方式切换为AOF方式

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

为最新的dump.rdb文件创建一个备份。
将备份放到一个安全的地方。
执行以下两条命令:

redis-cli config set appendonly yes

redis-cli config set save “”

确保写命令会被正确地追加到AOF文件的末尾。
执行的第一条命令开启了AOF功能： Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。
执行的第二条命令用于关闭RDB功能。这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

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

六、AOF和RDB之间的相互作用

在2.4及以上版本的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行 BGSAVE。这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

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

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

七、备份redis数据

请牢记下面这句话：确保你的数据由完整的备份。磁盘故障、节点失效诸如此类的问题都可能让你的数据消失不见，不进行备份是非常危险的。

Redis对于数据备份是非常友好的，因为你可以在服务器运行的时候对RDB文件进行复制： RDB文件一旦被创建，就不会进行任何修改。当服务器要创建一个新的RDB文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用 rename(2) 原子地用临时文件替换原来的RDB文件。

这也就是说，无论何时，复制RDB文件都是绝对安全的。

创建一个定期任务（cron job），每小时将一个RDB文件备份到一个文件夹，并且每天将一个RDB文件备份到另一个文件夹。
确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用find命令来删除过期的快照。比如说，你可以保留最近48 小时内的每小时快照，还可以保留最近一两个月的每日快照。
至少每天一次，将RDB备份到你的数据中心之外，或者至少是备份到你运行Redis服务器的物理机器之外。

八、常用配置

1、RDB持久化配置

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、AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

总结

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

参考

Redis https://redis.io/topics/persistence

--EOF--

巴特西

Redis持久化persistence

最新文章

热门文章