剑指Offer(Redis)——Redis做持久化

文章目录

1、RDB持久化
2、AOF(Append-Only-File)持久化:保持写状态
3、RDB和AOF文件共存情况下的恢复流程
4、RDB和AOF优缺点
5、RDB-AOF混合持久化方式

Redis是一种基于内存存储的非关系型数据库，所以可以保证查询速度很快，但是因为内存数据库所以会导致如果一旦宕机就会立刻失去所有的缓存，于是有了 Redis持久化策略，将缓存信息一边存一边写到硬盘上保证数据的存储是完全的。。。

1、RDB持久化

RDB实现缓存持久化，能保存某个时间点的全量数据快照。

意思是：
如果900s内有一条写入指令，产生一次快照。
如果300s内有十条写入指令，产生一次快照，如果指令条数小于十条大于等于一条就会等到900s再产生快照。
如果60内有一万条写入指令，产生一次快照，如果指令条数小于一万条大于等于十条就会等到300s再产生快照。

这样配置是为了保证数据安全，以及保证Redis的性能。

当备份进程出错时候，主进程就停止继续写入数据，主要是为了保持数据一致性的问题。

将RDB文件压缩之后再存储。

如果想要主动生成RDB文件，两种方法如下：

SAVE:阻塞Redis服务器进程，直到RDB文件被创建完毕

这种方式有一个很不好的地方，是SAVE运行在Redis主进程而主进程还负责处理所有的请求，就会将主进程的请求阻塞。

BGSAVE:Fork出一个子进程来创建RDB文件，不阻塞服务器进程

如果想要自动触发RDB持久化，方法如下：

根据redis.conf配置文件中的SAVE m n定时触发(使用的方式是BGSAVE)
主从复制时候主节点自动触发
执行Debug Reload
执行Shutdown且没有开启AOF持久化

BGSAVE原理入下:

系统调用fork时候，创建进程实现了Copy-on-write。

Copy-on-write
如果有多个调用者同时要求相同资源(如内存或磁盘上的数据存储)，他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。

RDB持久化缺点：

内存数据的全量同步，数据量大会由于IO而严重影响性能；
可能会因为Redis挂掉而丢失从当前至最近一次快照期间的所有数据。

2、AOF(Append-Only-File)持久化:保持写状态

AOF持久化可以记录除了查询之外的所有变更数据库状态的指令，并以append形式追加到AOF文件中，是对增量方式去进行保存的。

默认情况下都是先启动RDB需要手动去启动AOF。

在redis.conf配置文件中将appendonly改成yes就可:

AOF配置如下：
启动之后默认拷贝配置是everysec就是每秒钟同步到硬盘一次，always是总是同步到硬盘，no意思就是缓冲区使用完才同步到硬盘。

日志重写解决AOF文件大小不断增大的问题，原理如下：

调用fork(),创建一个子进程；
子进程把新的AOF写到一个临时文件中，不依赖原来的AOF文件；
主进程持续将新的变动同时写到内存和原来的AOF中；
主进程获取子进程重写AOF的完成信号，往新的AOF同步增量变动；
使用新的AOF文件替换掉旧的AOF文件。

3、RDB和AOF文件共存情况下的恢复流程

4、RDB和AOF优缺点

RDB优点：全量数据快照，文件小，恢复快
RDB缺点：无法保存最近一次快照之后的数据

AOF优点：可读性高，适合保存增量数据，数据不易丢失
AOF缺点：文件体积大，恢复时间长

5、RDB-AOF混合持久化方式

关于上图需要声明几点：

重写期间，由于主进程依然在响应命令，为了保证最终备份完整；因此依然会写入旧的AOF文件中，如果重写失败能够保证数据不丢失；
将重写期间响应的写入信息也写入到新的文件中，会为子进程保留一个buffer，防止新写的文件丢失数据；
重写是直接把当前内存的数据生成命对应命令，并不需要读取旧的AOF文件进行分析、命令合并；
AOF文件直接采用的文件协议，主要是兼容性好、追加方便可读性高，可以认为是修改修复；
此种混合持久化方式，用BGSAVE做镜像全量持久化，AOF做增量持久化。