Redis存储原理分析

前言

Redis是出了名的速度快,那是因为在内存中进行数据存储和操作;如果仅仅是在内存中进行数据存储,那就会导致以下问题:

  • 数据随进程退出而消失:当服务器断电或Redis Server进程退出时,内存肯定随之释放,最后数据也会丢失;可能有些小伙伴认为只是作为缓存,数据没有了,重新从数据库中读取放在里面即可,试想,如果是高并发场景,数据库岂不是压力很大;
  • 重要数据无法恢复:数据丢失之后无法进行恢复,对于一些重要的数据,只是存在Redis中,而没有存在关系型数据库,如果数据丢失便不可恢复;比如刷礼品排行榜,如果数据丢失,用户肯定不愿意的;

对于Redis持久化在工作中和面试过程中是一个很重要的技术点,必用必考,接下来详细说说Redis持久化;

正文

Redis针对数据持久化有两种方案,如下:

  • RDB(Redis DataBase):快照形式,即指定时间间隔将Redis内存中的快照数据保存在物理磁盘上,数据保存在*.rdb文件中,以二进制的形式进行存储,恢复数据直接加载即可;
  • AOF(Append Only File):日志形式,即将每条写命令以append-only模式记录在*.aof文件中,不能修改文件,只能进行追加;后续恢复数据自动执行日志文件中的命令即可恢复数据;
  • 混合就是RDB和AOF的结合;

两种方式都可以通过配置文件轻松搞定,来,咱们先从RDB开始;

fork:后续会频繁提到,简单解释一下,fork的作用是复制一个与当前进程一样的子进程,该子进程的所有数据都和原进程一致。

RDB持久化

理论放到后面再说,先来看看实际操作,再来做总结;上次对配置文件简单进行说明,这次就直接找到快照那配置就行啦,先看看默认配置:

1

通过 save <seconds> <changes>进行条件配置,如果触发条件就自动进行RDB持久化操作。默认配置中包含以下三种条件,满足其中一个就自动保存数据到磁盘:

  • save 900 1:900秒内(15分钟)至少有1个key的值进行修改;
  • save 300 10:300秒内(五分钟)至少有10个key的值进行修改;
  • save 60 10000:900秒内(1分钟)至少有10000个key的值进行修改;

测试验证

为了测试时间方便,将其中一个条件改为1分钟内有3个key的值修改了就进行持久化到磁盘,如下:

  1. 先将原有的dump.rdb文件删除掉,避免影响测试效果;

  2. 修改配置文件如下:

    image-20201202124046958

  3. 用修改之后,指定该配置文件重启redis-server,然后开始测试;

    image-20201202125318782

  4. 尝试打开dump.rdb看看,咋一看是看不懂,但其实是有对应关系的,这里就不深究了

    image-20201202181142589

Redis强大吧,不知不觉的就把数据备份,主要是还不影响正常操作,上图中第四步中就有体现,主进程fork了子进程进行备份,主进程不参与备份持久化操作。既然备份文件有了,如何进行恢复数据呢? redis-server在启动的时候自动将当前目录中的备份文件(dump.rdb)数据加载到内存中;如下图所示:

image-20201202140710879

RDB其他配置项

那为什么是dump.rdb文件?,为什么又是当前目录?,如果rdb备份文件写入失败了怎么办?这些通过配置文件中SNAPSHOTTING部分都有详细的说明,并提供相关配置项进行设置,如下:

  • stop-writes-on-bgsave-error:默认设置为yes,即当RDB备份数据失败时,Redis会停止接收数据,保证数据的一致性;如果对数据一致性要求不高的,可以将其进行关闭,设置为no,但推荐都开启;
  • rdbcompression:默认设置为yes,开启压缩之后会采用LZF算法对备份文件dump.rdb进行压缩,但会消耗点CPU性能进行处理,但影响并不大,推荐都开启;
  • rdbchecksum:默认设置为yes,即开启之后会对备份文件数据进行校验,但会消耗CPU性能,如果追求性能提高可以将其关闭,但影响也不大,推荐都开启;
  • dbfilename:默认为dump.rdb,即默认的备份文件名为dump.rdb,可以通过这个配置进行修改;
  • dir:默认为当前目录,即备份的文件存放的目录。

RDB手动触发备份

上面说到自动触发备份,其实在实际应用场景中,有些需求很急,如果要求等到满足条件备份完成之后才处理问题,间隔时间短还好点,如果间隔时间超过5分钟,估计等待处理问题的人要上房揭瓦啦;Redis同样为大家考虑到了,提供手动备份的方式,如下:

  • save:直接执行save命令,但会阻塞主进程操作,只能等待备份完成之后才能进行其他处理;
  • bgsave:直接执行bgsave命令,主进程会fork一个子进程进行备份操作,不阻塞主进程;当数据过大时,可能会在fork的时候有短暂的耗时,但影响不大; 上面的自动备份其实最后也是bgsave这种模式。
  • flushall:执行flushall命令会触发RBD备份,但是备份文件是空的,在本地测试一把就行了,没有任何意义,千万别在生产库上用

简单测试一下,删除dump.rdb文件,将配置文件恢复到默认值,然后指定配置文件重启redis-server,如下:

image-20201202150850388

如何停止或禁用RDB快照自动备份

可以通过配置文件的形式配置,也可以通过命令的形式进行关闭,但通过命令的方式,服务器重启之后就失效了,所以一般建议通过配置文件进行配置;

  • 配置文件方式:去除所有关于save的配置,或者配置一个save ""即可,重启redis-server;
  • 命令方式:在客户端中执行config set save ""即可,但redis-server重启时就恢复默认值了;

RDB备份流程

image-20201202164228149

简要说明:

  1. 当触发bgsave持久化时(满足配置条件或手动执行bgsave命令),主进程fork一个子进程进行持久化操作,主进程不参与任何持久化IO操作;

  2. 为了不影响原有rdb文件的使用,子进程会将快照数据先写入到临时文件;

  3. 当快照数据完全备份到临时文件时,就替换掉原有的rdb文件,从而得到最新数据的rdb文件;

    注:当执行sava命令的时候,会导致阻塞,只有等快照数据持久化完成之后,才能做其他事情;

RDB持久化优缺点

每一项技术在解决已有问题的时候,肯定也会带来新问题,RDB用来解决持久化问题,那它有什么优缺点呢?

优点

  • RDB保存的数据文件比较紧凑,对比AOF来说,相同数据的文件大小比较小;

  • 大量数据持久化时速度相对AOF比较快;

  • RDB中bgsave模式对主进程影响比较小,只有在主进程fork子进程的时候耗费资源,但影响不大;自动备份后台用的就是bgsave模式;

缺点

  • RDB可能会丢失最后一次没有备份的数据,如果在最后一次没开始备份之前,服务器挂了,那最后一次的数据就没了;
  • 当数据量巨大时,主进程在fork子进程的时候,可能会导致稍微的卡顿;

AOF持久化

既然已经有了RDB持久化了,那为什么还得出一个AOF呢?从RDB的缺点来看,很大程度上是因为可能会丢失最后一次备份之前的数据,对于一些重要数据来说,是不能接受的。而AOF的出现,将数据丢失风险极大的降低。先不说那么多,实操一把再慢慢聊。

AOF默认情况是没开启的,打开配置文件,为了不让RDB备份影响,这里暂时先将RDB备份禁用掉,如下:

  1. 禁用RDB备份:

image-20201202175142028

  1. 开启AOF备份:根据上一篇文章提到的,先找到APPEND ONLY MODE配置块,将AOF备份开启appendonly yes

    image-20201202175511758

  2. 配置好了,指定配置文件重启redis-server,先来看看效果:

    当一启动redis-server的时候,appendonly.aof文件就已经生成了;来,咱们接着敲点命令,如下↓↓↓

    image-20201202182017360

  3. 尝试打开appendonly.aof文件看看,和dump.rdp文件有什么不同;

    image-20201202182417350
    appendonly.aof只记录写命令,读命令不记录,而且记录方式是以追加的方式,所以速度相对比较快;

同RDB一样,在redis-server重启时,自动加载AOF文件命令依次执行,最终将数据进行恢复

AOF其他配置项

这就是Redis的强大,针对每一个功能都可以通过配置项进行完成,使用非常方便;

  • appendonly:默认no,不开启AOF持久化;可以通过设置为yes开启;
  • appendfilename:默认appendonly.aof,代表生成的AOF日志文件名,可以更改;
  • appendfsync:默认everysec,设置同步命令到磁盘的策略,即默认每秒通过fsync进行一次命令同步到磁盘;有三种命令同步策略可以选择,如下:
    1. always:只要有写入命令就通过fsync同步到磁盘,数据完整性好,但效率不好;
    2. everysec:每秒通过fsync进行一次命令同步到磁盘,可能会导致一秒中数据的丢失,因为可能在命令还没同步的时候,机器挂掉等操作,但可接受;综合考虑,推荐使用这种策略;
    3. no:不同步,由操作系统处理,这种数据不能保证安全;
  • auto-aof-rewrite-percentage:默认100,搭配auto-aof-rewrite-min-size一起触发AOF文件重写策略,即默认当当前AOF文件大小是上次重写的两倍时才重写,为了避免比率达到触发条件,但文件很小就触发重写的情况,所以搭配auto-aof-rewrite-min-size设置AOF文件的最小重写大小;即当前AOF文件大小达到比率的同时文件大小不低于auto-aof-rewrite-min-size设置的值才触发重写;
  • auto-aof-rewrite-min-size:默认64mb,搭配auto-aof-rewrite-percentage使用;

AOF触发重写

当执行的写命令过多时,就会导致AOF文件过度增大,而对于一些重复性的命令存在AOF文件中是没有必要的,如下图所示:

image-20201202233318616

上图中多次对a1这个Key进行多次写入,最终的值为10,可见如果AOF文件中只记录一条最终值的写命令岂不是最好,从而减少AOF文件的大小;这里文件大小肯定达不到自动触发重写的条件,这里就手动触发,然后再看看AOF文件内容,是否进行了优化,如下:

image-20201202234007490

如上图可见,重写之后的AOF文件的确是我们自己想要,是不是觉得Redis更加牛X了;触发重写有以下两种方式:

  • 自动触发:即当满足设置的auto-aof-rewrite-percentageauto-aof-rewrite-min-size值会自动触发重写;
  • 手动触发:在客户端中执行bgrewriteaof命令;

AOF重写流程

image-20201203000648231

简要说明:

  1. 当触发到重写AOF文件时,主进程fork一个子进程,子进程根据内存中的现有数据进行命令精简化,重写到新的AOF文件中;
  2. 在子进程正在重写AOF文件时,如果有新的写命令,将其存放到重写缓冲区,同时也同步到原来的AOF文件;
  3. 当子进程重写完成之后,通知主进程将重写缓冲区中的新命令写入到新AOF文件中,完成之后,用新的AOF文件将原来的AOF文件替换;
  4. 最后得到优化之后的AOF文件,减少文件大小;

AOF文件修复

对于AOF文件内容的合法性怎么解决呢,有可能由于突然事件,比如宕机,导致AOF文件写入不完整;也有可能有人恶意添加不规范数据,redis会怎么处理呢?这里就模拟手动修改AOF文件,如下:

image-20201203093037933

根据提示,使用redis-check-aof --fix <filename>进行修复,如下:

image-20201203110008592

启动图就不截了,小伙伴们试试去;还有redis也能对rdb文件修复,文中没有体现,但小伙伴记得去尝试一下,用redis-check-rdb这个工具即可,在windows版本中redis没有提供此工具,去linux用高点的版本实操一把。

AOF持久化优缺点

AOF的出现,是解决了RDB丢失最后一次没保存的数据,极大的降低了数据丢失的风险,但其也带来相关问题;

优点

  • 降低数据丢失风险,如果丢失,最多一秒数据;
  • 以追加方式记录日志,速度快;
  • 自动优化AOF文件,文件过大时进行重写,精简AOF文件;

缺点

  • 相同大数据,AOF文件比RDB文件大,占用磁盘空间;
  • 对于大数据的恢复,速度没有RDB快;

混合持久化

在redis4.0之后,提供了混合持久化配置开启功能; 混合持久化就是结合RDB和AOF各自优点进行整合的持久化方案,从而解决使用AOF恢复数据较慢的问题;

原理就是在AOF文件的前半段加入RDB快照数据,后面才是增量数据的命令记录;在配置文件中进行配置即可:aof-use-rdb-preamble yes,高版本redis都默认开启这种混合持久化模式;

优点:解决了单纯AOF恢复数据较慢的问题;

缺点:不能兼容低版本redis场景;

选择哪个持久化比较合适?

如果需求对数据完整性要求不是很高,可以接受短时间数据丢失,RDB快照持久化方式是最好不过的选择;

如果对数据完整性要求比较严格,使用AOF日志形式进行持久化比较合适;

如果redis版本在4.0以上,可以使用混合持久化的方式,降低纯AOF文件的恢复数据的时间;

如果仅仅是缓存,缓存数据也不重要,并发也不是很高,可以不用开启持久化;

注: 如果不是使用混合持久化,而是将RDB和AOF同时开启,redis-server恢复数据的时候会优先使用AOF文件进行数据恢复,因为AOF文件相对比较完整;

总结

暂时就到这吧,后续遇到相关问题再来记录分享;这个知识点比较重要,所以小伙伴们一定要自己尝试一下哦;使用真的很简单,进行简单的配置就完事了,如果能知道其简单的原理,遇到问题就没那么苦恼

申明转载

https://www.cnblogs.com/zoe-zyq/p/14083918.html

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 1024 设计师:白松林 返回首页