Redis的持久化

目录

RDB

手动触发

bgsave的执行过程

自动触发 

AOF 

AOF的执行流程 

重写机制 

重写的流程 

混和持久化 

比较AOF和RDB 

RDB

手动触发

1.save

这个命令会全力以赴地生成“快照”，如果数据量过大的话，可能会阻塞其他客户端地命令。

2.bgsave

与save不同，这个命令会创建出子进程来进行生成“快照”的过程。而父进程可以继续接收到其他客户端传来的命令，互不影响。

bgsave的执行过程

1.判断当前是否存在其他正在工作的子进程，如果有，则bgsave直接返回。

2.如果没有其他子进程，则fork出一个子进程执行任务。

3.子进程负责写文件，生成“快照”，父进程继续接收其他客户端的命令。

4.子进程完成持久化的操作后会通知父进程，并退出。

注意：

1.当在生成新的快照时，会把数据先保存在一个临时文件中，当生成完后，就删除之前的文件，将本次写完的文件的名字改成dump.rdb。实现了替换，保证了有且只有一个dump.rdb文件。

2.文件一般保存在/var/lib/redis中，当然也可以自行修改：

3.文件格式是二进制文件，将数据以压缩的方式写入该文件：

自动触发 

自动触发顾名思义就是系统自动进行生成快照，不需要手动操作。

在redis的配置文件中可以修改redis进行自动生成快照的频率：

save 900 1的意思就是900秒内修改了一次就进行保存

AOF 

可以在配置文件中手动设置AOF是否开启和设置AOF的文件名：

AOF的执行流程 

1.因为AOF的实时保存的，所以它需要经常与磁盘打交道，但是频繁的I/O会严重影响效率，所以AOF设计了一个缓冲区，积累一定的数据之后，再写入到磁盘。（但是期间若发生断电或者其他事故，那么数据就没了）。

2.缓冲区的刷新策略也可以由程序员自行设计：

需要根据不同的业务进行选择。缓冲区的刷新频率越高，那么意味着保存数据的可靠性更高，但是换来的是效率的下降。

重写机制 

为什么要进行重写？什么是重写？

总的来说重写就是把.aof中的文件进行了整理和修改的过程，去除了冗余并进行了合并。节省了内存也提高了将数据从磁盘读到内存的效率。

重写的流程 

1.创建出子进程，子进程进行重写，父进程继续接收客户端的命令。

2.因为在创建子进程的时候仅仅是保存了父进程当前的数据，所以之后父进程写入的数据父进程将获取不到。所以设计了一个缓冲区，专门存放fork之后产生的数据。当子进程完成重写后，利用信号通知父进程。父进程再把缓冲区的数据写入到子进程刚刚写入的aof文件里。

混和持久化 

因为考虑到aof文件恢复到内存中的速度比较慢，所以设计出了一种混合持久化的操作。即按照AOF的方式将每条命令都记录到磁盘上，同时aof文件中存的数据的格式也是二进制格式。

可以在配置文件中开启是否进行混合持久化：

比较AOF和RDB 

1.RDB的文件格式是二进制格式，AOF是文本格式。

2.RDB不是实时保存，而AOF是实时保存。

3.RDB加载恢复数据的速度要大于AOF。

总结：根据不同的业务需求和场景进行选择。