redis持久化

一.持久化的概述

持久化的功能:Redis是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永远丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘中;
当下次Redis重启时,利用持久化实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置,Redis持久化分为RDB持久化和AOF持久化,
前者将当前数据保存到硬盘,后者则是将每次执行的写命令保存到硬盘;

1.1->RDB

RDB是一种快照存储持久化方式,具体就是将Redis某一时刻的内存数据保存到硬盘的文件中,默认保存的文件名为dump.rdb,
而在Redis服务器启动时,会重新加载dump.rdb文件的数据到内存当中恢复数据,触发RDB持久化分为手动触发和自动触发;

1.2->触发机制

手动触发分别对应save和bgsave命令
save命令:阻塞当前Redis服务器,直到RDB过程完成为止,对于内存比较大的实例会造成长时间的阻塞,线上环境不建议使用;
bgsave命令:redis进程执行fork操作创建子程序,RDB持久化过程由子进程负责,完成自动结束,阻塞只发生在fork阶段,一般时间很短;
显然bgsave命令是针对save阻塞问题的优化,因此redis内部涉及RDB的操作都是采用bgsave的方式;
除了执行命令手动触发之外,redis内部还在自动触发RDB的持久化机制,例如一下场景:
1.使用save相关配置,如 save m n 表示m秒内数据集存在n次修改时,自动触发bgsave
2.如果从节点执行全量复制操作,主节点自动执行bgsave生产RDB文件并发送给从节点
3.执行debug relaod 命令重新加载Redis时,也会自动触发save操作
4.默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave

1.3->流程说明

bgsave是主流的触发RDB持久化,根据下图了解它的运作流程
流程解析:
1.执行bgsave命令,redis父进程判断当前是否存在正在执行的子进程,如RDB/AOF子进程,如果存在bgsave命令直接返回
2.父进程执行fork操作创建子进程fork操作过程中父进程会阻塞,用过info Stats命令查看latest_fork_usec选项,可以获取最近一个fork操作的耗时,单位为微妙
3.父进程fork完成后,bgsave命令会返回background saving started 信息并不再阻塞父进程,可以继续响应其他命令
4.子进程创建RDB文件,根据父进程内存生产临时快照文件,完成后对原有文件进行原子替换,执行lastsave命令可以获取最会一次生产RDB的时间,对应info统计的rdb_last_save_time选项
5.进程发送信号给父进程表示完成,父进程更新统计信息,具体见info Rersistence 下的rdb_*选项;

MyAnswer博客


1.4->服务器配置自动触发

除了通过客户端发送命令外,还有一种方式,就是在Redis配置文件中的save指定触发RDB持久化的条件。
比如: [多少秒内至少达到多少写操作]就开启RDB数据同步

例如我们可以在配置文件redis.con指定如下的选项:
#900S内至少达到一条写命令
save 900 1
#300s内至少达到10条写命令
save 300 10
#60s内至少达到10000条写命令
seve 60 10000

这种通过服务器配置文件触发的RDB的方式,与bgsave命令类似,达到触发条件时,会forks一个子进程进行数同步,不过最好不好通过这种方式
来触发RDB持久化,因为设置触发的时间太短,则容易频繁写入rdb文件,影响服务器性能,时间设置太长则会造成数据丢失


1.4->RDB方式的优缺点

优点
1.RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集,这种文件非常适合进行备份:比如说,你可以在最近的24小时内,每
个小时备份一次RDB文件,并且在每个月的每一天,也备份一个RDB文件,这样的会话,即便遇上问题,也可以随时将数据集还原到不同的版本
2.RDB可以最大化Redis的性能: 父进程在保存RDB文件时唯一要做的就是fork出一个子进程,然后这个字进程就会处理接下来的所有保存工作
父进程无须任何磁盘I/O操作
3.RDB在恢复大数据集时大速度比AOF的恢复速度要快

缺点
1.RDB方式数据没有办法做到实时持久化/秒级持久化,如果服务器宕机的话,采用RDB的方式会造成某个时间内数据的丢失
比如我们设置10分钟永不一次或者5分钟达到1000次写入就同步一次,那么如果还没有达到触发条件服务器就死机了,那么
这个时间段的数据会丢失
2.使用bgsave命令在forks子进程时,如果数据量太大,forks的过程也会发生阻塞,另外,forks子进程会耗费内存
针对RDB不适合持久化的问题,Reddis提供了AOF持久化的方式解决

二.AOF

AOF持久化:与RDB存储某个时刻的快照不同,AOF持久化方式汇集了客户端对服务器的每一次写操作命令道日志中,
并将这些操作以Redis协议追加保存到以后缀为aof文件末尾

2.1->使用AOF

开启AOF功能需要设置配置 appendonly yes , 默认不开启,AOF文件通过appendfilename配置设置,默认文件
是appendonly.aof保存路径用RDB持久化方式一致,通过dir配置指定

2.3->工作流程

MyAnswer博客


1.所有的命令会追加到aof_buf(缓冲区中)
2.AOF缓冲区根据对应的策略向硬盘做同步操作
3.随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的
4.当redis服务器重启时,可以加载AOF文件进行数据恢复   当AFO和RDB同时开启时,默认首先加载AOF文件数据

2.4->重写机制说明

AOF将客户端的每一个写操作都追加到aof文件末尾,随着命令不断写入aof,文件会越来越大,为了解决
这个问题,Redis,引入重写机制压缩文件体积,aof文件重写是把redis进程内的数据转化为写命令同步到aof文件的过程
比如:
     多条命令可以合并为一个, 如:lpsh list a , lpsh list b  , lpsh list c 可以转换为 lpsh list a b c
AOF重写降低了文件占用空间,除此之外,另外一个目的,更小的AOF文件可以更快地被redis加载

2.4->触发机制

手动触发: 直接调用命令 bgrewriteaof命令
自动触发:							
auto-aof-rewrite-percentage:100
auto-aof-rewrite-min-size:64mb
当AOF文件达到触发规则,自动触发重写机制	

2.5->AOF注意事项

AOF文件损坏
  在写入AOF日志文件时,如果Redis服务器宕机,则aof日志文件会出格式错误,在重启Redis时,Redis服务器会拒绝载入
  这个aof文件,可以通过命令修复aof并恢复数据
  redis-check-aof -fix file.aof

2.6->AOF优缺点

优点:

1.AOF可以设置,完全不同,每秒同步,每次操作同步,默认是每秒同步。因为AOF是操作指令的追加,所以可以频繁的大量同步
2.AOF文件是一个值追加日志的文件,即使服务器宕机未写入完整的命令,也可以通过redis-check-aof工具修复
3.如果AOF文件过大,Redis会在后台自动地重写AOF文件,重写后会使AOF文件压缩到最小所需的指令集
4.AOF文件是有序保存数据库的所有写操作,易读,易分析,即使如果不小心误操作数据库,也很容易找出错误指令,例如不小心
FLUSHALL 可以非常容易恢复到执行命令之前;

缺点:

1.相同数据量下,AOF的文件通常体积会比RDB大,因为AOF是存指令的,而RDB是所有指令的结果快照,但AOF在日志重写后会
压缩一些空间
2.在大量写入和载入的时候,AOF的效率会比RDB底,因为大量写入,AOF会执行更多的保存命令,载入的时候也需要大量的执行命令
来得到最后的结果
   对此RDB更有优势






2.7->重启加载的选择

AOF和RDB文件都可以用于服务器重启时数据的恢复






MyAnswer博客

2.8->持久化的选择

在实际生产环境中,根据数据量,应用对数据的安全要求,会有各种各样的持久化策略: 如完全不使用任何持久化,使用RDB或
AOF的一种,或同时开启RDB和AOF持久化等,此外持久化的选择必须与Redis的主从策略一起考虑,因为主从复制与持久化
同样具有数据备份的功能,而却主机master和从机slave可以独立选择持久化方案;
1.如果Redis中的数据完全丢弃也没关系(如Redis完全用作DB层数据的cache) 那无论是单机还是主从架构,都可以不进行任何持久化
2.在单机环境下,如果可以接受十几分钟或者更多的数据丢失,选择RDB对Redis的性能更有利:
  如果只能接受秒级的数据丢失,应该选择AOF
3.但在多数情况下,我们都会配置主从环境,salve的存在既可以实现数据的热备,也可以进行读写分离分担Redis读请求
以及Master宕机后继续提供服务

在这种情况下的做法是:
 Master:完全关闭持久化(包括RDB和AOF)这样可以让Master的性能达到最好
 slave:关闭RDB,开启AOF(如果对数据安全要求不高,开启RDB关闭AOF也可以),并定时对持久化文件进行备份->如备份到
 其他文件夹下,并标记好备份的时间;然后关闭AOF文件的自动重写,然后定时添加任务,在每天Redis闲时(如凌晨12)
 调用bgrewriteaof.....


MyAnswer博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论