Redis持久化

两种方式:

RDB方式:通过快照完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照,并且存储到硬盘上。就像拍照一样,将这一瞬间的所有东西都保存下来。进行快照的条件在配置文件中指定。主要有两个参数构成:时间和改动的键值的个数,即当在指定时间内被更改的键的个数大于执行数值时,就会进行快照。RDB是Redis的默认持久化方式。

优势:

  • RDB 是一种表示某个即时点的 Redis 数据的紧凑文件。RDB 文件适合用于备份。例如,你可能想要每小时归档最近 24 小时的 RDB 文件,每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。
  • RDB 非常适合于灾难恢复,作为一个紧凑的单一文件,可以被传输到远程的数据中心,或者是 Amazon S3(可能得加密)。
  • RDB 最大化了 Redis 的性能,因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程,由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。
  • RDB 在重启保存了大数据集的实例时比 AOF 要快。

redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件。正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的。

对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能。

劣势:

  • 当你需要在 Redis 停止工作(例如停电)时最小化数据丢失,RDB 可能不太好。你可以配置不同的保存点。然而,你通常每隔 5 分钟或更久创建一个 RDB 快照,所以一旦 Redis 因为任何原因没有正确关闭而停止工作,你就得做好最近几分钟数据丢失的准备了。
  • RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话,fork()比较耗时,结果就是,当数据集非常大并且 CPU 性能不够强大的话,Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork(),但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

#配置

1.找到Redis的配置文件:redis.conf

2.设置rdb文件路径

Redis启动后会读取RDB快照文件,将数据从硬盘载入到内存,一般情况下1GB的快照文件载入到内存的时间大约20-30分钟。

RDB的快照过程:

1) Redis使用fork函数复制一份当前进程(父进程)的副本;

2) 父进程继续接受并处理客户端发来的命令,而子进程开始将内存中的数据写入到硬盘中的临时文件;

3) 当子进程写入完成所有数据后会用该临时文件替换旧的RDB文件。

手动快照:

如果没有触发自动快照,可以对redis进行手动快照操作,SAVE和BGSAVE都可以执行手动快照,两个命令的区别是前者是由主进程进行快照操作,会阻塞其他请求;而后者是通过fork子进程进行快照操作。

注意:

由于redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候必须保证有16G内存,要不然会启用虚拟内存,性能非常差。

RDB文件过大时,是可以压缩的,Redis默认开启压缩,当然也可以通过配置rdbcompression参数来禁用压缩。

压缩:优点:减少磁盘存储空间,缺点:消耗CPU资源

不压缩:优点:不消耗CPU资源,缺点:占用磁盘空间多

 

AOF方式:AppendOnly File的缩写,是Redis系统提供了一种记录Redis操作的持久化方案,在AOF生成的文件中,将忠实记录发生在Redis的操作(相当于日志文件),从而达到在Redis服务器重启或者当机之后,继续恢复之前数据状态的机制,在数据恢复时按照从前到后的顺序再将指令都执行一遍。

优势:

  • 使用 AOF Redis 会更具有可持久性(durable):你可以有很多不同的 fsync 策略:没有 fsync,每秒 fsync,每次请求时 fsync。使用默认的每秒 fsync 策略,写性能也仍然很不错(fsync 是由后台线程完成的,主线程继续努力地执行写请求),即便你也就仅仅只损失一秒钟的写数据。
  • AOF 日志是一个追加文件,所以不需要定位,在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof 工具也可以很轻易的修复。
  • AOF 文件里面包含一个接一个的操作,以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如,即使你不小心错误地使用 FLUSHALL 命令清空一切,如果此时并没有执行重写,你仍然可以保存你的数据集,你只要停止服务器,删除最后一条命令,然后重启 Redis 就可以。

默认的AOF持久化策略是每秒钟fsync一次(fsync是指把缓存中的写指令记录到磁盘中),因为在这种情况下,redis仍然可以保持很好的处理性能,即使redis故障,也只会丢失最近1秒钟的数据。如果在追加日志时,恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复,因为采用了追加方式,如果不做任何处理的话,AOF文件会变得越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。举个例子或许更形象,假如我们调用了100次INCR指令,在AOF文件中就要存储100条指令,但这明显是很低效的,完全可以把这100条指令合并成一条SET指令,这就是重写机制的原理。

 

劣势:

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

在同样数据规模的情况下,AOF文件要比RDB文件的体积大。而且,AOF方式的恢复速度也要慢于RDB方式。

#配置

1.找到Redis的配置文件:redis.conf

默认情况下没有打开,保存的文件是'appendonly.aof'

2.设置保存策略!

AOF文件重写

举个栗子:比如在redis客户端对key执行了一系列命令

set count 1 //初始值为1 

incr count // 加1 

incr count //加1 

decr count //减1

这个时候结果为

get count 

“2”

如果不进行AOF重写的话,进行AOF文件恢复的时候,Redis会执行AOF文件中的每一条命令,并最终得到 count 为2 。

进行AOF重写后,相当于把中间的计算过程略去。直接把计算得到的结果设置进redis,相当于仅执行了一条命令 set count 2。

可以使用BGREWRITEAOF命令来重写AOF文件。

重写策略的参数设置:

auto-aof-rewrite-percentage 100

当前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时,会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据。

auto-aof-rewrite-min-size 64mb

限制了允许重写的最小AOF文件大小,通常在AOF文件很小的时候,即使其中有些冗余的命令也是可以忽略的。

 

 

 

无持久化(缓存的机制)

同时使用RDB和AOF

感兴趣的朋友可以关注微信公众号(会定时推送新的知识):

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值