Dedis学习笔记（一）Redis持久化

Redis有两种持久化方式：RDB和AOF

RDB（Redis DataBase）

RDB是什么，能干嘛？

总结来说就是在指定的时间内，进行数据集的时间点快照，实现类似照相的功能，把某一时刻的数据和状态以文件的形式写入到磁盘上进行存储。这样即是发生了故障宕机快照文件（RDB文件(dump.rdb)）也不会丢失，这样就保证了数据的安全性。

操作方法

有两种：自动触发和主动触发

自动触发

版本变化：在Redis6.0.16以下的版本Redis.config文件中的配置情况是这样的

这一配置在Redis7中发生了变化

自动触发就是在配置的时间内有超过配置数的key发生了变化就会有一份新的RDB文件

注意：在执行危险的flushall或者flushdatabase这种命令时也会Redis也会写一份RDB文件

手动触发

save和bgsave

save命令会在主程序中执行持久化工作，会阻塞redis服务器直到持久化完成，所以基本很少使用

bgsave命令会在后台异步进行快照操作，该方式会fork一个子进程由子进程来复刻持久化工作，所以不会阻塞Redis服务器，在快照的同时Redis服务器还可以响应客户端的操作

RDB总结

优势：

1.适合大规模的数据备份

2.可以按照业务定时备份

3.对数据的完整性和安全性要求不高

4.RDB文件在内存中的加载速度比AOF快的多

劣势：

1.如果在快照的间隔时间发生故障那么会丢失在间隔时间的数据

2.内存数据全量同步，如果数据量太大会导致IO严重影响系统性能

AOF（APPEND ONLY FILE）

AOF是什么，能干嘛？

以日志的形式记录redis每一个写操作（读操作不会记录），只允许追加文件但不可以更改文件，redis启动之初会读取该文件重新构建数据，换而言之redis重启之后就会读取日志文件（appendonly .aof）的写指令并执行一遍以完成数据恢复的工作

需要注意的是默认情况写AOF功能是关闭的，需要配置appendonly yes

操作方法

AOF持久化工作流程

三种写回方式

always：同步写回

everysec：（默认方式）每秒写回

no：操作系统控制的写回

AOF重写机制

是什么？

启动AOF的文件压缩，，只保留可以恢复数据的最小指令集

举例：

比如有个key 

一开始你  set k1 v1

然后改成  set k1 v2

最后改成  set k1 v3

如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；

但是，我们实际效果只需要set k1 v3这一条，所以，

 

开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。

 

AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

官网配置：

触发机制：

自动触发：满足配置文件的选项后，redis会记录上次重写时的AOF文件大小，默认配置是当AOF文件是上次rewrite后大小的一倍且文件大小大于64MB时

手动触发：客户端发送bgrewriteaof命令

重写原理：

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

AOF优缺点：

优点：更好的保护数据不丢失，性能高，可以做紧急恢复

缺点：相同数据集数据的aof文件大于远rdb，恢复速度也慢于rdb

AOF总结

RDB+AOF混合持久化

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写