[4] Redis持久化-CSDN博客

本文链接：https://blog.csdn.net/KJ_Study/article/details/115075112

一、Redis持久化

备份后，要把备份文拷贝出来，到另一存储设备中。服务器炸了，那数据就真没了。

保存的文件名是dump.rdb。因为配置文件中的dbfilename dump.rdb写明了文件名

[1] RDB：redis database

介绍

在指定时间间隔内，将内存中的数据块区数据写入到磁盘。

保存为Snapshot快照，它恢复时是将快照文件直接读到内存中。

过程

Redis会单独创建fork一个子进程进行持久化。会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

备份与相关参数

save或bgsave立即备份。

save只管保存，其它不管，全部阻塞
bgsave Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
可以通过lastsave命令，可获取最后一次成功执行快照的时间

SNAPSHOTTING
save 3600 1 #3600秒 改动一次，保存
save 300 100 #300秒 改动100次，保存
save 60 10000 #60秒，改动10000次，保存

redis每次重启会自动去读取dump.rdb。不过使用flushall、shutdown会将数据快速写入dump.rdb

动态停止RDB保存规则的方法：redis-cli config set save ""

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感性，那RDB方式比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

优点：

适合大数据的恢复
对数据完整性和一致性要求不高

劣势：

在一定时间间隔做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀内存需要考虑

[2] AOF：append only flie

为了解决RDB的缺点。

RDB：可能会丢失最后一次的数据

保存的文件名是appendonly.aof，配置文件中的appendfilename "appendonly.aof"决定的

如果aof与dump文件都在，使用的是aof文件。如果aof文件有错，将不能启动redis。

redis中有redis-check-aof可以检测aof文件的正确性，并进行更改

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GyzkULOV-1616391400218)(D:\Code\Markdown\image\redis的aof与dump加载.png)]

解决办法

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF配置

appendonly no
appendfilename "appendonly.aof
---------------------------------
#如何保存
appendfsync everysec
always #每次发生数据变更会被立即记录到磁盘，性能较差当数据完整性较好
everysec #默认，异步操作。如果一秒内宕机，有数据丢失
no #不用
----------------------------------
#重写时，是否可以用appendfsync，默认no即可，保证数据安全性
no-appendfsync-on-rewrite no
设置重写的基准值
auto-aof-rewrite-percentage 100
#重写日志大小。实际生产中3G是起步
auto-aof-rewrite-min-size 64mb

Rewrite重写

如果AOF文件超过了所设定的值时，Redis就会启动AOF文件的内容压缩。AOF采用的是追加方式，AOF文件持续增加而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条Set语句。重写aof文件并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件。

触发机制

Redis会记录上一次重写时的AOF大小，默认配置是当AOF文件大小是上次Rewrite后大小的一倍且文件大于64m时触发。

优点：