Redis持久化

redis持久化
    顾名思义,就是把内存中的数据保存到硬盘上,以防redis发生意外造成数据丢失。
    目前有两种方案,RDB方式和AOF方式。
    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文件。
  1. save 60 100 #60秒内有100次修改,redis就会自动保存RDB文件  
  2. save 300 10 #300秒内有10次修改,redis就会自动保存RDB文件  
  3. ....  
    可以设置多个命令,只要触发一个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文件。
 如下图所示:
 
注意事项代码
  1. 注意事项:在执行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

  1. appendonly yes   
b)、配置AOF策略,有三种策略
注意事项
  1. appendfsync no  
  2. 当设置appendfsync为no的时候,Redis 不会主动调用 fsync去将AOF日志内容同步到磁盘,所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统,是每30秒进行一次fsync,将缓冲区中的数据写到磁盘上。  

  3. appendfsync everysec  
  4. 当设置appendfsync为everysec的时候,Redis会默认 每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略,再等一秒钟。也就是在两秒后再进行fsync,这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞,所以当前的写操作就会阻塞。  
  5. 所以,结论就是,在绝大多数情况下,Redis会每隔一秒进行一次fsync。在最坏的情况下,两秒钟会进行一次fsync操作。  
  6. 这一操作在大多数数据库系统中被称为group commit,就是组合多次写操作的数据,一次性将日志写到磁盘。  

  7. appednfsync always  
  8. 当设置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文件(合并记录),新的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为一种单一的持久化模型(长远计划)。 




总结

什么是持久化 
将数据从掉电易失的内存存放到能够永久存储的设备上
Redis为什么需要持久化
基于内存的
缓存服务器,需要吗? 可以不需要
内存数据库,需要吗? 需要
消息队列,需要吗? 需要
Redis持久化方式
RDB(Redis DB)
AOF(AppendOnlyFile)
RDB
在默认情况下,Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中
策略
自动:按照配置文件中的条件满足就执行 BGSAVE
    save 60 1000,Redis要满足在60秒内至少有1000个键被改动,会自动保存一次
手动:客户端发起 SAVE、BGSAVE  命令
SAVE命令
redis > save
阻塞Redis服务  ,无法响应客户端请求
创建新的dump.rdb替代旧文件
BGSAVE命令
redis > bgsave
非阻塞,Redis服务正常接收处理客户端请求
Redis会folk()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕
父进程用新的dump.rdb替代旧文件
BGSAVE是一个异步命令
                    是调用系统内核命令,因为写时复制,父修改数据时,子会复制一份原来的操作,这样BGSAVE保存的数据是   的不是最新的
默认配置  
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis/6379
只要上面三个条件满足一个,就自动执行备份。
创建RDB文件之后,时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的
SAVE 和 BGSAVE 命令比较
    SAVE不用创建新的进程,速度略快
    BGSAVE需要创建子进程,消耗额外的内存
    SAVE适合停机维护,服务低谷时段
    BGSAVE适合线上执行
        RDB优点
完全备份,不同时间的数据集备份可以做到多版本恢复
紧凑的单一文件,方便网络传输,适合灾难恢复
恢复大数据集速度较AOF快
RDB缺点
会丢失最近写入、修改的而未能持久化的数据
folk过程非常耗时,会造成毫秒级不能响应客户端请求
生产环境
创建一个定时任务cron job,每小时或者每天将dump.rdb复制到指定目录
确保备份文件名称带有日期时间信息,便于管理和还原对应的时间点的快照版本
定时任务删除过期的备份
如果有必要,跨物理主机、跨机架、异地备份
AOF
        说明
Append only file,采用追加的方式保存
默认文件appendonly.aof
记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库
        调整AOF持久化策略,可以在服务出现故障时,不丢失任何数据,也可以丢失一秒的数据。相对于RDB损失小得多
AOF写入机制
AOF方式 不能 保证绝对不丢失数据
目前常见的操作系统中,内存缓冲区(buffer),未写入磁盘之前,数据可能会丢失
写入磁盘的策略
appendfsync选项,这个选项的值可以是always、everysec或者no
Always
服务器每写入一个命令,就调用一次fdatasync
Everysec(默认)
服务器每一秒重调用一次fdatasync
No
服务器不主动调用fdatasync,由操作系统决定何时
服务器遭遇意外停机时,丢失命令的数量是不确定的
运行速度:always的速度慢,everysec和no都很快
AOF重写机制
AOF文件过大
                合并重复的操作,AOF会使用尽可能少的命令来记录
重写过程
folk一个子进程负责重写AOF文件
子进程会创建一个临时文件写入AOF信息
父进程会开辟一个内存缓冲区接收新的写命令
子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中
新文件替代旧文件
注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复
AOF重写触发
手动:客户端向服务器发送BGREWRITEAOF命令
自动:配置文件中的选项,自动执行BGREWRITEAOF命令
auto-aof-rewrite-min-size <size>
                                            触发AOF重写所需的最小体积,防止死循环,还需下面设置
auto-aof-rewrite-percentage  <percent>
                                            指定触发重写所需的AOF文件体积百分比 , 默认100%,即为文件大小达到重写后的两倍才会允许
AOF 优点
写入机制,默认fysnc每秒执行,性能很好不阻塞服务,最多丢失一秒 的数据
重写机制,优化AOF文件
如果误操作了(FLUSHALL等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到 FLUSHALL 执行之前的状态
缺点
相同数据集,AOF文件体积较RDB大了很多
恢复数据库速度叫RDB慢(文本,命令重演)

添加新评论