文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Redis持久化基石RDB与AOF

2024-12-03 01:36

关注

Redis持久化

为什么需要持久化

其实在我们工作中也有多持久化场景,比如word。它的持久化形式是以~$论文.docx的形式来持久化。

那么在Redis中为了防止数据意外丢失,确保数据安全,也会进行持久化。

利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化。

在Redis中有两种持久化方式:RDB(Redis DataBase)、AOF(Append Only File)。

RDB(Redis DataBase)将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据。

AOF(Append Only File)将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在命令。

RDB持久化

在Redis中可以使用save命令来执行一次RDB持久化操作.

save指令相关配置:

  1. dbfilename.dump.rdb 
  2.  说明:设置本地数据库文件名,默认值为dump.rdb 
  3.  
  4. dir 
  5.  说明:设置存储.rdb文件的路径 
  6.  
  7. rdbcompression yes 
  8.  说明:设置存储至本地数据库时是否压缩数据,默认为yes,采用LZF压缩 
  9.   
  10. rdbchecksum yes 
  11.  说明:设置是否进行RDB文件格式校验,该校验在写文件和读文件过程均进行 

我们知道早期Redis版本是单线程的。当我们执行save命令时会阻塞当前Redis服务器,直到RDB过程完成为止,有可能会造成长时间阻塞,线上环境不建议使用。

那么问题来了,既然使用save会对线上服务器造成影响,那么有没有一种更好的持久化方式呢?答案是有的,那就是bgsave.

通过名称可以看出这个持久化操作是后台执行的,不会导致Redis发生阻塞。

下面看一下bgsave的工作原理:

可以看出,当执行bgsave命令后Redis会fork出一个子进程,用于创建RDB文件进行持久化,这样一来就不会阻塞Redis了。但是bgsave不会立即执行,且会消耗额外的CPU资源。

bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式,save命令可以放弃使用。

bgsave指令相关配置:

  1. dbfilename.dump.rdb 
  2.  说明:设置本地数据库文件名,默认值为dump.rdb 
  3.  
  4. dir 
  5.  说明:设置存储.rdb文件的路径 
  6.  
  7. rdbcompression yes 
  8.  说明:设置存储至本地数据库时是否压缩数据,默认为yes,采用LZF压缩 
  9.   
  10. rdbchecksum yes 
  11.  说明:设置是否进行RDB文件格式校验,该校验在写文件和读文件过程均进行 
  12.   
  13. stop-writes-on-bgsave-error yes 
  14.  说明:后台存储如果出现错误,是否停止保存操作 

那么问题又来了,我们不可能一直手动去执行或者bgsave指令,这时Redis为我们提供了自动执行bgsave的功能。

在Redis的配置文件中有这么一个配置save [secone] [changes]可以帮助我们自动进行持久化。

  1. 配置: 
  2.  save second changes 
  3.   
  4. 作用: 
  5.  满足限定时间范围内key的变化数量达到指定数量即进行持久化 
  6.   
  7. 参数: 
  8.  second:监控时间范围 
  9.  changes:监控key的变化量 
  10.   
  11. 位置: 
  12.  在conf文件中进行配置 
  13.   
  14. 范例: 
  15.  save 900 1 
  16.  save 300 10 
  17.  save 60 10000 

注意: save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的 save配置中对于second与changes设置通常具有互补对应关系,尽量不要设置成包含性关系 save配置启动后执行的是bgsave操作

RDB三种持久化方式对比:

RDB的优点:

RDB的缺点:

AOF持久化

AOF(Append Only File)持久化,以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。与RDB相比可以简单描述为数据产生的过程。

AOF主要作用是解决了持久化的实时性,目前已经是Redis持久化的主流方式。

AOF持久化过程

在把AOF命令缓冲区同步到文件时有三种写数据策略(appendfsync):

  1. always(每次) 
  2.  每次写入操作均同步到AOF文件中,数据零误差,但性能较低 
  3.   
  4. everysec(每秒) 
  5.  每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能也较高 
  6.  在系统突然宕机是会丢失1秒内的数据 
  7.   
  8. no(系统控制) 
  9.  由操作系统每次同步到AOF文件的周期,整体过程不可控 

Redis开启AOF功能持久化

配置:

  1. appendonly yes|no 
  2.  作用:是否开启AOF持久化,默认为不开启状态 
  3.   
  4. appendfsync always|everysec|no 
  5.  作用:AOF同步命令数据策略 
  6.   
  7. appendfilename filename 
  8.  AOF持久化文件名,默认文件名为appendonly.aof,建议配置成appendonly-端口号.aof 

AOF在遇到相同命令是如何处理呢

假如同步策略是 appendfsync everysec每秒同步一次,执行如下命令:

  1. set name zhangsan 
  2. set name lisi 
  3. set name wangwu 

最终AOF文件里将只有一条:

  1. set name wangwu 

AOF重写

随着AOF文件不断写入,AOF文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。

AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将若干条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF 重写的作用

AOF重写的规则

  1. del key1 
  2. hdel key2 
  1. 如下命令: 
  2. lpush list1 a、lpush list1 b、 lpush list1 c 
  3. 可以转化为: 
  4. lpush list1 a b c。 
  5.  
  6. 为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素 

AOF重写规则

  1. bgrewriteaof 
  1. auto-aof-rewrite-min-size size 
  2. auto-aof-rewrite-percentage percentage 

AOF重写流程

AOF持久化+重写:

RDB与AOF的区别

RDB与AOF如何选择

对数据敏感,建议使用默认的AOF持久化方案

数据呈现阶段有效性,建议使用RDB持久化方案

综合对比

持久化应用场景

 

来源:Java养基场内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯