广州天与地网站建设,福州企业免费建站,做网站颜色如何搭配,营销qq多少钱一个月【Redis 高级】- 持久化 - RDB
#x1f451;什么是持久化呢#xff1f;
那当然是够持久呀#xff0c;这个持久如果在你不主动去删除的情况下#xff0c;它就一直存在的。
#x1f3b7;那么这有什么用呢#xff1f; 举个栗子#xff1a;我们在用 PowerPoint 在写价值 …【Redis 高级】- 持久化 - RDB
什么是持久化呢
那当然是够持久呀这个持久如果在你不主动去删除的情况下它就一直存在的。
那么这有什么用呢 举个栗子我们在用 PowerPoint 在写价值 2 个亿的 PPT 要求明天一大早就要去展示今天加班到凌晨都必须搞出来表面很开心内心在奔腾的你接受了这个老板的强行建议。 加班到了凌晨 2 点终于搞完了正准备休息一会突然不小心把电源线一脚踢掉了你颤抖的手点击了一下电源开机键当屏幕的 win 界面加载出来后整个人到傻了。桌面干净的只剩下了桌面这个时候你的内心已经完全奔溃了想着自己当时如果保存到文件夹中就不会出现这样的问题了。一时间你受不了自己的这种行为自己扇了自己一巴掌哎不疼~原来是在做梦呀。 赶紧从梦里醒来才发现原来自己的已经把文件保存到了文件夹了呀。
通过上面的例子可以看到 CtrlS 的重要性了吧其实哈对于我们的 Redis 也是可以进行 CtrlS 的只是方式有些许的不同而已。但目的都是一样 PPT 进行保存是将内存中的数据保存到磁盘中而对于 Redis 而言也是将内存中的数据保存到磁盘中。
这就是所谓的持久化其实目的就是为了提高数据的抗风险能力。
Redis 的持久化都是怎么进行处理的呢- 哎对于一个数据要将其中内存保存到磁盘中首先能想到的是那种方式呢 当然是最简单粗暴的直接将数据的本身进行保存呀就相当于从内存中复制一份一模一样的数据直接写到磁盘中呀。 是呢确实是这样我们的 Redis 中的一种持久化的策略中就用到了上述所猜想的一种理念直接暴力的保存数据即可。 这种方式有个名字叫做 RDB保存的是数据有点原汁原味的感觉赖 emmm那有没有其他的什么方式呢 哎这个还真有我们每一次操作的时候是不是后台都会生成一个操作的记录结果呀对咯这个操作的记录结果其实就是我们常常说的 日志 既然我们的日志中记录了我们每一次的操作的过程那我们可不可以想办法在 Redis 启动的时候将日志中的所有的操作都读取出来然后将所有的指令都执行一遍这样就可以保证我们的所有的数据都会刷新到我们的内存中呢 是的没错这样的方式其实就是 AOF (保存的操作的过程)
RDB 的启动方式
♈ save 手动执行一次保存
RDB 启动方式 – save 指令的相关配置
设置本地数据库的文件名默认为 dump.rdb 通常设置为 dump-端口号.rdb dbfilename filename 设置存储 .rdb 文件路径,通常设置为存储空间较大的目录目录名为 data dir path 设置存储至本地数据库时是否数据压缩默认为 yes 设置为 no 节省 CPU 的运行时间但存储文件变大 rdbcomperession yes|no 设置读写文件过程中是否进行 RDB 格式校验默认 yes 设置为 no节约读写 10% 时间消耗单存存在数据损坏的风险 rdbchecksum yes|no bind 192.168.10.101
port 6379
logfile 6379.log
dir /redis/data
dbfilename dump-6379.rdb在每一次执行完毕所有的命名之后执行 save 指令就会自动的将数据压缩存储到 dir 指定的目录下在每一次的开机之后会自动的加载数据到 Redis 当中。
RDB启动方式 – save 执行的工作原理 在上面的我们可以看到当我们执行 save 指令后Redis 有一个数据压缩并保存的时间。 有与 Redis 是一个单线程的数据库所以当我们执行 save 指令的时候如果说此时我们的数量量是比较大的那么在执行任务的队列中就会出现阻塞的状态导致后的获取数据的 get 执行一直处于等待知道 save 指令执行完毕。 那么对于如果数据库过大单线程执行的而效率会变低那么有没有解决的办法呢 手动启动后台保存操作但不是立即执行 bgsave
RDB启动方式 – bgsave 指令的相关配置 后台存储过程当中如果出现错误现象是否停止保存操作默认 yes stop-writes-on-bgsave-error yes|no 其他 dbfilename filename dir path rdbcopression yes rdbchecksum yes|no bgseve 的执行原理其实就是后台开启了一个子线程而子线程负责对我们的文件进行生成然后将保存成功的消息返回给我们的主进程并展示。
RDB启动方式 – 自动持久化
设置自动持久化的条件满足限定时间范围内 key 变化的次数当达到指定时进行持久化 save second changes 参数 second: 监控的时间范围 changes: 监控时间范围内 key 的变化量 示例 save 900 1 save 300 10 save 60 10000 自动持久化的原理 在我们执行每一条命令的时候首先会对执行的命令进行判断如果说一条命令满足了
1、操作会对数据产生影响 执行了 del 操作但执行失败
2、真正产生了影响 执行了 del 操作执行成功
3、是否进行数据上的对比 该数据删除没有什么影响但 set 的操作会有影响
只有满足了以上三点那么就会将影响的数量 1
注意save 配置要根据实际的业务情况而进行设置如果你设置的过高或者过低可能都会造成业务上性能的影响。 其实对于 save 的自动执行最终执行的也是 bgsave 的操作只是将原来的手动变为了自动。
RDB 三种启动方式的对比
方式save指令bgsave指令读写同步异步阻塞客户端指令是否额外内存消耗否是启动新进程否是
RDB 优缺点
优点
RDB是一个紧凑压缩的二进制文件存储效率较高RDB内部存储的是redis在某个时间点的数据快照非常适合用于数据备份全量复制等场景RDB恢复数据的速度要比AOF快很多应用:服务器中每X小时执行bgsave备份并将RDB文件拷贝到远程机器中用于灾难恢复。
缺点
RDB方式无论是执行指令还是利用配置无法做到实时持久化具有较大的可能性丢失数据bgsave指令每次运行要执行fork操作创建子进程要牺牲掉一些性能Redis的众多版本中未进行RDB文件格式的版本统一有可能出现各版本服务之间数据格式无法兼容现象
