什么是持久化?

由于redis是基于内存操作的轻量型数据库,所以如果发生宕机重启这种事情,存储的数据就会直接丢失,如果在里面存储了没有备份的数据,那么确实会对我们的业务造成一定影响。 所以我们要通过持久化的手段,将数据存入磁盘中,只要进入了磁盘,就不怕主机宕机重启。这部分数据除非主动删除,是可以一直存在,这就是持久化。

什么场景需要持久化?

一般情况下来说,我们使用redis只是给数据库加一层防护,防止大量的流量直接打到数据库导致数据库宕机,进而引发系统整体瘫痪。
在真正的业务处理中,大量访问的数据其实都是一些热点数据,那么这些热点数据我们做一层缓存,就可以拦截大量的流量,不需要将请求再发送给数据库。 减少了与数据库的链接,也就是减少了大量的IO耗时。 那么也就做到了单次请求的耗时减少,自然而然的 QPS就能整体提升。
扯得远了,说回到redis,在上面的单纯做数据缓存的场景,其实是没有必要进行数据持久化。 因为就算系统宕机重启,查询不到数据的时候,无非是去数据库里面再捞一把,重新存入缓存中就可以了,这部分数据是天然就在数据库里面持久化过的。

那说了这么多,到底什么场景才需要? 我给的答案是,除非是真的将redis当成所有业务数据的最终存储位置,所有的业务流转都是基于redis来操作,没有其他任何天然持久化的数据库如:mysql、es等等。 这个时候才是一定需要持久化的。
只要是数据可以通过其他手段重新更新到redis中的话,就没有必要在redis进行持久化操作。

哦,有的朋友可能会说,那总有些业务数据是先更新到缓存中,然后再更新到数据库中的吧,如果这个时间差里面,数据丢失了怎么办? 对于这种,redis是可以做分布式多节点备份,主节点宕机了,副节点一样会有一份备用数据。

又有朋友说了,那如果所有节点都宕机了,怎么办? 这种场景,我们要想一下,到底是丢失了多久的数据? 从数据进入缓存,到数据异步落库,这个时间差真的会很久吗?如果这个过程中要保证数据100%不丢失的话,redis可以做到,但是! 这个过程的产生的耗时,与直接进入数据库还有区别吗? 我们使用redis不就是为了提升性能对吧。

可能还有朋友说了,那如果真的是比较重要的数据,又对性能要求比较高,比如最常见的秒杀系统,可以是基于reids来处理的,如果这个过程中数据丢失了,那不就会造成秒杀系统出问题么。 对于这种,我只想说,如果在推广秒杀的这么重要的时刻,还能发生redis宕机的问题,最好是转行吧,别做商家系统了,会赔死的。
这些问题确实是在面试中遇到过

言归正传,但是redis既然有这个持久化的功能,那一定就是有人会问的,我们就来剖析一下

持久化策略

持久化的策略简单来说分为两种,AOF 和 RDB
AOF是一种热备份,就是在我们不断的更新数据的时候,他会不断的将我们更新的数据持久化到磁盘中,这个基本上时间差就是ms级别的。 缺点就是可能会对我们更新reids产生一定性能上的影响。
RDB是一种定时冷备份,就是每隔一段时间,将数据整体备份一次,备份的间隔期间是不会对我们的请求造成影响。缺点就是在备份的过程中可能会影响我们的更新操作,并且会丢失一定时间内的数据。

RDB

全称是Redis Database Backup file,直译是redis数据备份,我们称之为数据快照。

自动备份:
在配置文件中配置,需要注意的是,这种快照备份,是会阻塞redis服务器,不能处理其他命令,直到备份完成

# 900秒内至少1个键被修改则进行快照
save 900 1
 
# 300秒内至少10个键被修改则进行快照
save 300 10
 
# 60秒内至少10000个键被修改则进行快照
save 60 10000

手动备份:
执行命令,bgsave 这个命令是手动开启一个子进程,过程中不会阻塞其他的reids命令

RDB备份的流程
备份数据的时有一个fork(创建)一个子进程的动作,将主进程中的所有内容全部复制,然后进行一个数据复制备份的操作,这个fork是什耗费时间的。 所以如果性能要求比较高的话,建议可以关闭默认的save,在服务器上用shell写一个定时器,每天的固定时间去执行bgsave命令,可以提高系统的性能。缺点就是可能会丢失一定的数据。
在这里插入图片描述

AOF

全称是Append Only File ,是一个命令追加保存的策略。
将每个命令都存储到aof文件中,恢复数据的时候是进行命令回放来。

AOF的配置参数:

  • appendonly:是否开启AOF持久化策略,默认为no。
  • appendfilename:AOF文件的名字,默认为"appendonly.aof"。
  • appendfsync:AOF文件的同步模式,有always、everysec、no三种模式。
  • no-appendfsync-on-rewrite:在AOF重写时,是否停止同步,默认为no。
  • auto-aof-rewrite-percentage:AOF文件长度增长的百分比,超过该百分比进行AOF文件重写。默认100
  • auto-aof-rewrite-min-size:AOF文件重写触发的最小文件体积。默认64mb

同时开启aof和rdb策略的话,优先使用aof

备份流程:

  • 客户端发送写操作命令给Redis服务器。
  • 服务器接收到命令,将其写入内存中,并将该命令添加到AOF缓冲区。
  • AOF缓冲区根据策略可能会被同步到硬盘上的AOF文件中。
  • Redis服务器定期检查AOF文件的大小,并进行AOF重写操作,即压缩AOF文件。
  • 如果Redis服务器异常,会从AOF文件中读取命令进行数据恢复。

AOF重写操作 aof rewrite
设置了auto-aof-rewrite-percentage或者auto-aof-rewrite-min-size会触发重写操作。
size配置很清晰,意思是超过多大就要重写。
percentage的意思是,本次的文件大小,和上次的文件大小对比,超过百分之多少就进行重写。

为什么要重写aof文件
因为命令是不断接收的,所以文件肯定也是不断的增大,如果过大的话一定会对cpu造成负担,IO性能下降,内存消耗过大。所以就要进行文件瘦身操,将命令梳理一遍。 比如已经del的数据,那所相关的命令肯定就没有存在的必要了。

重写的时候也是fork出来一个子进程,然后扫描当前reids所有的键值对,生成一份新的aof文件。
这个过程中redis是没有阻塞,还在不断的接收新的命令,这些新的命令会存在aof缓冲区,等到新的aof完成的话,再将这些新命令存入新的aof文件中

总结

最优的持久化手段就是,AOF和RDB配合使用,因为AOF文件命令恢复数据是比较慢的。

  • 定时的通过shell来进行定时的rdb快照备份。
  • 然后再通过aof文件来进行缺失数据的补充。

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部