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文件。

 如下图所示：






 

 但是这里有个问题，当写命令越来越多，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为一种单一的持久化模型(长远计划)。