做网上商城网站设计网络营销现状分析

目录

引子

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次更新，则备份rdb
RDB的其他配置

• 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机制来互补。