`
haoran_10
  • 浏览: 435350 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

redis(7)、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为一种单一的持久化模型(长远计划)。 

2
1
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics