redis（7）、redis持久化

redis技术目录

 

redis持久化，顾名思义，就是把内存中的数据保存到硬盘上，以防redis发生意外造成数据丢失。

目前有两种方案，RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。按照redis作者的想法，这两个方案最终会在以后的版本中合成一个。

一、快照 RDB

（1）、介绍

redis 持久化的RDB文件是经过压缩的二进制文件，保存了内存中的键值对数据，存在硬盘里，防止redis数据库出现故障时数据丢失。

当redis数据库出现故障时，可以使用RDB文件进行还原为原先的数据库状态。

在实际运用中，一定要设置好规则进行定期的备份redis服务器数据，保存在其他异地服务器，一旦redis数据库出现问题，想还原为原先的时间点，就可以使用备份RDB文件进行还原。

如果RDB文件有问题，还可以使用redis数据库自带的工具redis-check-dump进行检测。

 

（2）、怎样使用

有两个命令可以生成RDB文件，SAVE、BGSAVE。

a）、SAVE命令会阻塞服务器进程，是在主进程中创建RDB文件，会阻塞其他的客户端请求。

b）、BGSAVE命令会在主进程fork出的一个子进程创建RDB文件，不会阻塞客户端请求。

c）以上两个指令是在redis-cli客户端直接执行命令时保存RDB文件，还可以设置SAVE命令配置，redis进行自动保存RDB文件。

save 60 100 #60秒内有100次修改，redis就会自动保存RDB文件
save 300 10 #300秒内有10次修改，redis就会自动保存RDB文件
....

可以设置多个命令，只要触发一个save命令条件就会自动保存RDB文件。

这里设置的SAVE命令，redis其实内部是调用BGSAVE命令进行子进程创建RDB文件，确保redis主进程不会受到阻塞，可以继续处理客户端的读写请求。

 

在实际运用时，要根据场景来设定，但是一定要设置。

a）、如果本身redis数据库读大于写，则设置的保存时间长久一些，不妨设置为一个小时才触发一次创建RDB。

b）、如果redis数据库写比较多，而且数据比较敏感，可以设置时间短暂一些，5分钟或者2分钟就保存一次。

c）、数据本身比较敏感，需要进行主从备份，而主从备份依赖原理就是主redis数据库保存RDB时，才会触发同步从redis数据库，这时也响应的设置时间短暂一些。

 

 （3）、原理

 仅针对配置save命令时，redis数据库自动触发创建RDB文件，而在redis-cli中手动执行save ,bgsave命令，内部原理也是相同的。

1、客户端发起写请求

2、redis会记录写命令计数器，并且保存一个最后保存RDB的时间

3、当redis周期性循环时，触发设置的一个SAVE命令，redis会读取写命令计数器，最后保存时间

4、达到了保存RDB文件的条件，redis会fork一个子进程，其实开始执行BGSAVE命令流程

5、扫描redis数据库的所有数据，保存到一个随机的RDB文件

6、修改旧的RDB文件名

7、把新的随机的RDB文件命名为正常的RDB文件即dump.rdb，并且删除掉原先旧的RDB文件。

 如下图所示：

 

注意事项：在执行fork是时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻，父进程和子进程共享同一块内存数据，当父进程需要修改其中的某片数据（如执行写命令）时，操作系统会将该片数据复制一份以保证子进程不受影响，所以RDB文件存储的是执行fork操作那一刻的内存数据。所以RDB方式理论上是会存在丢数据的情况的(fork之后修改的的那些没有写进RDB文件)。

 

（4）、优点

a）、RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以      容灾。

b）、RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。
c）、RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
d）、RDB在重启保存了大数据集的实例时比AOF要快。

 （5）、缺点

 a）、当你需要在Redis停止工作(例如停电)时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如，至少5分钟和对数据集100次写之后，但是你可以有多个保存点)。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。 

b）、RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。 

 

 

二、追加日志文件AOF

（1）、介绍

redis除了提供RDB持久化功能，还提供了AOF（append only file）持久化功能。与RDB持久化通过保存redis数据库的键值对不同，AOF持久化是通过保存redis服务器所执行的写命令来记录数据库状态的。

当开启了AO

F持久化功能时，服务器会优先从AOF文件中还原数据；如果没有开启AOF时，才会从RDB中还原

数据。如果AOF文件出错了，Redis自带的redis-check-aof工具来修复原文件。

 （2）、怎样使用

a)、首先在配置文件中开启AOF

appendonly yes 

b）、配置AOF策略，有三种策略

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，所以其性能也会受到影响。
 

 

（3）、原理

1、客户端进行写请求

2、redis服务器收到写请求，放入到redis服务器内存AOF缓冲区中

3、redis周期性循环中，触发写日志策略，去AOF写命令缓冲区读取数据

4、如果是appednfsync always，会在主进程中进行重写日志，会阻塞其他的请求。如果是appendfsync everysec，会fork一个子进程进行重写日志。如果是appendfsync no，则依赖操作系统进行写日志，大部分linux操作系统默认是30秒一次。

5、服务端调用write(2) 这个系统调用，将数据往系统缓冲区上写。如果保存AOF过程到这一步时，redis数据库出现故障，日志依然会正确的保存下去。下面的流程就由操作系统来完成了。

6、操作系统将缓冲区中的数据转移到磁盘控制器上

7、磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）。只有完成这一步时，机器发生故障，比如断电，才能保证日志正确保存。

如下图所示：

 

 

 但是这里有个问题，当写命令越来越多，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。

从上面的流程我们能够看到，RDB和AOF操作都是顺序IO操作，性能都很高。而同时在通过RDB文件或者AOF日志进行数据库恢复的时候，也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读。

 

（4）、优点

1、使用AOF Redis会更具有可持久性(durable)：你可以有很多不同的fsync策略：没有fsync，每秒fsync，每次请求时fsync。使用默认的每秒fsync策略，写性能也仍然很不错(fsync是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。

2、AOF日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof工具也可以很轻易的修复。

当AOF文件变得很大时，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis就会切换这两个文件，并开始往新文件追加。

3、AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如，即使你不小心错误地使用FLUSHALL命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启Redis就可以。

 

（5）、缺点

 1、对同样的数据集，AOF文件通常要大于等价的RDB文件。AOF可能比RDB慢，这取决于准确的fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭fsync，即使在很高的负载下也和RDB一样的快。不过，即使在很大的写负载情况下，RDB还是能提供能好的最大延迟保证。

 

三、小结

通常来说，我们应该同时使用这两种持久化方法。在实际配置中，最好两者结合，AOF保证数据不会丢失，RDB进行备份数据以及提供少延迟的主从复制功能。
如果可以接受灾难时有几分钟的数据丢失，可以只单独使用RDB。 
单独使用AOF也并不好，因为时常进行RDB快照非常方便于数据库备份，启动速度也较之快，还避免了AOF引擎的bug。 
基于这些原因，redis可能会统一AOF和RDB为一种单一的持久化模型(长远计划)。