redis持久化(RDB和AOF)

redis提供了三种持久化的方案，将内存中的数据持久化写入磁盘。

1、RDB（快照）持久化：保存某个时间点的全量数据快照。特定的时间间隔保存那个时刻的全量数据。

RDB.png

打开conf配置文件，
第一个框表示：
900秒内有1个写入操作，就RDB一次。
300秒内有10个写入操作，就RDB一次。
60秒内有10000个写入操作，就RDB一次。

第二个框表示：
当备份进程出错的时候，主进程就停止接收新的写入操作，保证持久化的数据的一致性。

第三个框表示：
RDB文件的压缩选项，Yes表示将RDB文件压缩后再去做保存。建议设置成no，因为redis是CPU密集型服务区，开启压缩后会带来更多的CPU的消耗，相比硬盘成本，CPU更值钱。

禁用RDB.png

RDB文件通过两个命令来生成：
SAVE:阻塞redis的服务器进程，直到RDB文件被创建完毕。在主线程中保存快照，redis是用一个主线程来处理所有请求的，这种方式会阻塞所有客户端的请求。
BGSAVE:Fork出一个子进程来创建RDB文件，不阻塞服务器进程，记录接收BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程。
BGSAVE原理
1>执行BGSAVE之后会去检查当前主进程有没有正在进行AOF/RDB的子进程。如果有，返回错误。（防止子线程之间的竞争）
2>如果没有，触发持久化，调用rdbSaveBackground。
3>再之后，执行fork系统调用（本质调用操作系统的系统调用fork指令）。
4>fork指令创建进程，linux下实现了Copy-on-Write。传统方式下的话，直接把所有资源复制给子进程，实现简单但是效率低下，而且复制的资源可能对子进程毫无用处。
（linux下，内核只为子进程创建虚拟空间，父子两个进程使用的是相同的物理空间，只有父进程发生更改时才会对子进程分配独立的物理空间。）

BGSAVE.png

COW.png

自动化触发RDB持久化的方式
1>根据配置redis.conf的save就可以(用的bgsave)
2>主从复制时，主节点自动触发
3>执行Debug Reload
4>执行shutdown且没有开启AOF持久化

2、AOF持久化：通过保存redis服务器所执行的写状态来记录数据库的。
RDB备份数据库状态，AOF备份数据库接受到的指令。所有被写入AOF的命令都是以redis的协议格式来保存的，在AOF持久化的文件中，数据库会记录下所有变更数据库的命令。

AOF.png

AOF间隔.png

那现在有一个问题，比如说redis现在做一个定时器，轮询100下，那其实我们想要的结果是最后的数据，但是AOF会把整个过程记录下来，所以AOF文件大小会不断增大。怎么办呢？
BGREWRITEAOF命令来重写
1>调用fork()，创建一个子进程
2>子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
3>主进程持续将新的变动同时写到内存和原来的AOF里
4>主进程获取子进程重写AOF的信号之后，往新的AOF同步增量变动
5>使用新的AOF文件替换旧的AOF文件

BGREWRITEAOF.png

RDB和AOF的优缺点比较
1>
RDB优点：全量数据快照，文件小，恢复快
RDB缺点：无法保存最近一次快照之后的数据
2>
AOF优点：可读性高，适合保存增量数据，数据不易丢失
AOF缺点：文件体积大，恢复时间长

RDB-AOF混合
redis4.0之后推出RDB-AOF混合持久化方式，并且是默认配置。
BGSAVE做镜像全量持久化，AOF做增量持久化。
在redis实例重启时，会使用BGSAVE持久化文件重新构建内容，再使用AOF重放近期的操作指令。

最后编辑于：2019.04.15 16:59:11