app网站设计,建设专业网站网络,网站建设源文件,农产品品牌建设目录
引子
RDB
RDB的优缺点
小节一下 引子
不论把Redis作为数据库还是缓存来使用#xff0c;他肯定有数据需要持久化#xff0c;这里我们就来聊聊两种持久化机制。这两种机制#xff0c;其实是 快照 与 日志 的形式。快照:就是当前数据的备份#xff0c;我可以拷贝到磁…目录
引子
RDB
RDB的优缺点
小节一下 引子
不论把Redis作为数据库还是缓存来使用他肯定有数据需要持久化这里我们就来聊聊两种持久化机制。这两种机制其实是 快照 与 日志 的形式。快照:就是当前数据的备份我可以拷贝到磁盘也可以拷贝到别的服务器如此一来万一现有redis的计算机节点被恶意攻击或者被人删库跑路那么你的原有数据还是可以恢复的。像你的云服务器也有快照功能被人攻击以后直接拿来恢复就行。日志:其实就类似于我们开发系统的时候用户的操作日志这里指的是用户的每次写操作日志比如增加key修改key以及删除key这些命令都会记录下来形成一个日志文件。那么在需要恢复的时候只需要执行这个日志文件里的所有命令就能达到恢复数据的目的。
RDB
RDB就相当于上面的快照形式是全量备份这个备份数据里都是二进制文件也是Redis的默认备份方案。当redis恢复的时候会全量的恢复此时redis处于阻塞状态。 如上图这个 dump.rdb 就是当前redis的备份快照数据。你可以尝试把他复制到一个新的redis下然后启动观察数据是否一致。这个RDB就是在redis启动的时候他发现有这个rdb就会载入到内存也就是恢复数据。需要注意redis启动的时候如果rdb文件很大那么会阻塞直到数据全部 恢复到内存里。 RDB是每隔一段时间做备份的机制。如果因为服务器宕机死机重启那么内存中的数据就没了但是redis他会随着linux启动而启动会从rdb中进行回复。 RDB是每隔一段时间进行备份的那么我们来看如下图思考一下: 上图中Redis会备份RDB到磁盘那么备份到磁盘的过程是会耗时的内存中redis的数据越多越大比如8g内存中有4g都是redis数据那么在备份到磁盘的时候会有传输过程有一定的时间损耗可能几十秒也有可能1分钟多这个RDB快照并不是瞬间产生的。那么这个时候就有问题了假设现在是凌晨1点开始备份由于有时间损耗01点钟05分产生了RDB文件保存到磁盘那么会如下问题到底是哪种: 1.这个RDB文件的内容是凌晨1点的数据? 2.这个RDB文件内容是01点钟01分的数据? 3.这个RDB文件内容是凌晨1点的数据并且记录了开始备份到结束(1点到1点01分之间)的数据? 其实是这样redis有两种方式一个是 save 命令一个是 bgsave 命令。 save:备份rdb到磁盘阻塞当前进程redis不接受任何写操作. bgsave:fork(创建)一个新的子进程子进程把rdb数据写入磁盘写操作由父进程去处理两个进程之间数据隔离所以rdb的数据不会因为有新的写操作而发生变化。父进程相当于是老板子进程相当于是手下员工职能不一样相互隔离fork:新的子进程指向的缓存数据和redis父进程一致所以速度很快。(redis是C语言开发的本质是指针指向地址而不是复制一个新的数据所以父进程有新的写操作是写到新的内存地址而子进程指向的地址不变) 所以最终的数据其实就是凌晨一点的数据. 提问:既然bgsave这么好用为啥还设计一个save命令呢? 不论是开发游戏还是普通的项目肯定会有维护期那么在维护期的时候就会用到save直接阻塞不让新的数据写入游戏项目是最常见的直接停服了所有玩家等着新版本上线后才能重新进RDB 自动保存机制 如上图redis的核心配置有这么一段内容这个是触发bgsave的条件他是自动的满足条件就会执行rdb的备份。(要注意它是 bsave) 如果900秒内发生1次更新则备份rdb 如果300秒内发生10次更新则备份rdb 如果60秒内发生10000次更新则备份rdbRDB的其他配置 stop-writes-on-bgsave-error yes:如果save过程出错则停止写操作 no:可能造成数据不一致 rdbcompression yes:开启rdb压缩模式 no:关闭会节约cpu性能开支 rdbchecksum yes:使用CRC64算法校验对rdb进行数据校验有10%性能损耗 no:不校验 dbfilename:rdb的默认名称可以自定 dump.rdb
RDB的优缺点
优点: *每隔一段时间备份全量备份比较适合做冷备。 *灾备简单可以远程传输到其他服务器,再做恢复 *子进程备份的时候主(父)进程的写操作可以和子进程隔离数据互不影响保证备份数据的的完整性 *相对AOF来说当有更大文件的时候可以快速重启恢复恢复速度比较快
缺点 *发生故障时有可能会丢失最后一次的备份数据 *子进程会有一定的内存消耗尤其是当有大量新的写操作涌入的时候那些都会有额外的内存开支 *由于定时全量备份是重量级操作所以对于实时备份的业务场景就不适用了
附:关于父子进程对内存的消耗(基于Linux的Fork:copy-on-write) redis在fork一个子进程的时候会消耗内存父子进程在内存上的占用量的表现是一致的注意这里是表现并不是说完全的拷贝一份新的内存数据进行备份如果有10g数据他也不会完全再复制10g总共20g那得多大开销?实际上linux有一个写时复制的技术copyon write 就是父子进程共同指向相同的内存地址数据是一致的。如果父进程处理新的写操作那么他会复制一个新的副本来进行操作而子进程他还是处理的当时fork时的快照数据所以父子进程之间相互不影响,需要注意早期的fork子进程会完全拷贝父进程的所有数据状态等内容这个在如今是灾难性的。 如今的fork是依托操作系统所提供的 copy-on-write 机制。
小节一下
RDB机制适合大量数据的恢复但是数据的完整性和一致性可能会不足。所以就需要有后续的AOF机制来互补。
