【Redis】Redis持久化

在使用Redis作为缓存时，可以选择使用Redis的持久化功能来保证数据不会因服务器重启而丢失。Redis支持两种持久化方式： RDB（快照）和 AOF（追加式文件）

RDB(Redis DataBase)

RDB定期把我们Redis内存中的所有数据 都写入硬盘中 生成一个快照

定期具体来说 又有两种方式

手动触发和自动触发

手动触发
程序员通过redis客户端 执行特定的命令 来触发快照生成

1. save:执行save的时候,redis就会全力进行生成快照操作 此时就会阻塞其他客户端的命令
2. bgsave: 不会影响Redis服务器处理其他客户端的请求和命令

多进程实现bgsave

自动触发
在Redis配置文件中设置一下,让Redis每隔多长时间/每产生多少次修改就触发

redis生成的rdb文件,是存放在redis的工作目录中的 在配置文件中可以设置

redis默认就是开启了rdb的 名为dump.rdb的二进制文件 二进制文件把内存中的数据以压缩的形式 保存到这个二进制文件中 后续redis服务器重新启动,就会尝试加载这个rdb文件, 如果发现格式错误 就可能会加载数据失败

redis提供了rdb文件的检查工具

当执行rdb镜像操作的时候 此时就回吧要生成的快照文件先保存到一个临时文件中 当这个快照生成完毕后,在删除之前的rdb文件,把心生成的临时的rdb文件名改成刚才的dump.rdb

rdb文件中的数据并不是这边插入数据就会立即更新

rdb 的触发时机

900s内进行了至少一次修改
300s内最少进行了10次修改
60s内最少进行了10000次修改
此处的数值都可以自由修改配置

AOF(Append Only File)

类似于mysql的binlog 把用户的每个操作都记录在文件中 当redis重新启动的时候 就会赌气这个aof文件中的内容 用来恢复数据

aof一般是关闭状态 通过修改配置文件来开启aof功能 当aof开启后 rdb就不会生效了 启动时就不再读取rdb文件内容了

aof的文件名是 appendonly.aof

aof是一个文本文件 每次进行的操作都会被记录到文本文件中 通过一些特殊符号作为分隔符 对命令的细节进行划分

aof机制并非是直接让工作线程把数据写入硬盘,而是先写入一个内存缓冲区,积累一波 在统一写入硬盘

如果把数据写到缓冲区里 此时进程突然挂 那么缓冲区内的数据就会丢失 此时redis就给出一些选项 让程序员根据实际情况来进行取舍 来设置缓冲区的刷新策略,刷新频率越高,性能越低,数据的可靠性越高,刷新频率越低 性能影响越小,数据的可靠性越低

aof文件持续增长, 体积越来越大 会影响到redis下次启动的启动时间

redis启动时要读取aof文件的内容,但是实际上redis再重新启动的时候 只关注最终结果,而aof文件记录了中间的过程

因此redis就存在一个机制,能够针对aof文件进行整理操作 这个整理就是能够剔除其中的冗余操作,并合并一些操作 达到给aof文件瘦身这样的效果

AOF重写流程

1创建子进程fork 父进程依然负责接受请求 子进程负责针对aof文件进行重写

重写的过程中 不关心原aof文件中都有什么 只是关心内存中的最终数据状态 子进程只需要把内存中当前的数据获取出来,以aof格式写入到一个新的aof文件中

混合持久化

aof本来是按照文本的方式来写入文件的 但是以文本的方式写文件 成本是比较高的 redis就引入了混合持久化的方式 结合了aof和rdb的特点

按照aof的方式 每个请求都记录到文件中 再出发aof重写之后 就会把当前内存的状态按照rdb的二进制格式写入到新的aof文件中 后续在进行的操作 仍然是按照aof文本的方式追加到文件后面

当redis上同时存在aof文件和rdb快照时 以aof为主 rdb就直接被忽略了