Redis持久化总结

Redis持久化总结

Redis持久化总结快照持久化SAVEBGSAVE只追加持久化比较RDB优点缺点AOF优点缺点

因为Redis是内存型数据库，所以为了防止因为系统崩溃等原因导致数据丢失的问题，Redis提供了两种不同的持久化方法来将数据存储在硬盘里面，一种方法是快照（RDB），它可以将存在于某一个时刻的所有数据都写入到硬盘里面，另外一种方法是只追加文件（AOF），它会在执行写命令时，将被执行的写命令都写入到硬盘里面。

快照持久化

Redis可以通过创建快照来获得在内存里面的数据在某一个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其它服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。

有两个命令可以用于生成RDB文件，一个是SAVE，另外一个BGSAVE。

在只使用快照持久化来保存数据时，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序。

SAVE

特点：SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕，在服务器进程阻塞期间，服务器不能处理任何命令请求。

缺点：服务器持久化期间无法接受其它请求。

BGSAVE

特点：BGSAVE命令则会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程则继续处理命令请求。

缺点：创建子进程所耗费的时间会随着Redis占用的内存而增加。

只追加持久化

AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来纪录数据所发生的变化，因此，Redis只要从头到尾重新执行一次AOF文件所包含的所有写命令，就可以恢复AOF文件所记录的数据集。

在设置同步频率的时候，存在三个选项：

• always：每个Redis写命令都要同步写入硬盘，但是这样做会占用Redis所拥有的内存，严重降低Redis的速度

• everysec：每秒执行一次同步，显式地将多个写命令同步到硬盘

• no：让操作系统来决定应该何时进行同步

最好使用everysec，既能避免每次都写入所造成的性能影响，又能避免操作系统崩溃所导致的可能丢失不定量数据，其即使系统崩溃，用户最多只会丢失一秒之内产生的数据，当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

缺点：因为Redis会不断的将被执行的写命令纪录到AOF文件里面，所以随着Redis不断执行，AOF文件的体积也会不断增长，极端条件下，AOF甚至可能会用完硬盘的所有可用空间。

为了解决上面的缺点，Redis提供了两种重写方式，其原理是通过移除AOF文件中的冗余命令来重写AOF文件，使得AOF文件尽可能的小：

• REWRITEAOF命令：在主进程中重写AOF命令，会阻塞主进程，在生产环境中很少使用；

• BGREWRITEAOF命令：BGSAVE命令相似，Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写，因为AOF文件重写也需要用到子进程，所以同样存在快照持久化因为创建子进程所导致的性能问题和内存占用问题。

1）执行AOF重写请求。

如果当前进程正在执行AOF重写，请求不执行。

如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行。

2）父进程执行fork创建子进程，开销等同于bgsave过程。

3.1）主进程fork操作完成后，继续响应其它命令。

　　 所有修改命令依然写入AOF文件缓冲区并根据appendfsync策略同步到磁盘，保证原有AOF机制正确性。

3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据

　　 由于父进程依然响应命令，Redis使用“AOF”重写缓冲区保存这部分新数据，防止新的AOF文件生成期间丢失这部分数据。

4）子进程依据内存快照，按照命令合并规则写入到新的AOF文件。

　　 每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。

5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息。

5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。

5.3）使用新的AOF文件替换老的AOF文件，完成AOF重写。

比较

RDB

优点

• 灵活设置备份频率和周期。你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

• 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

• 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

• 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

缺点

• 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

• 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF

优点

• 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。

• 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

• 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的缓存用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

缺点

• 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

• 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

Redis · 特性分析 · AOF Rewrite 分析

深入学习Redis（2）：持久化