Redis 持久化 - AOF、RDB-优快云博客

本文链接：https://blog.youkuaiyun.com/2302_76668193/article/details/146080329

Redis 持久化 - AOF、RDB

redis是一个内存数据库,当redis服务器重启,获取电脑重启,数据会丢失,我们可以将redis内存中的数据持久化保存到硬盘的文件中

Redis持久化策略有哪些?(RDB、AOF)
Rdb:定时将数据保存在硬盘中(dump.rdb)
Aof:保存所有操作的命令

RDB - 持久化机制默认：

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB,一般情况下不需要修改这个配置。

rdb保存的文件是dump.rdb都是在我们的配置文件中快照中进行配置的!

RDB - 触发机制：

save的规则满足的情况下,会自动触发rdb规则
执行 flushall 命令,也会触发我们的rdb规则!
退出redis,也会产生 rdb 文件!

如果恢复rdb文件!：只需要将rdb文件放在我们redis启动目录就可以,redis启动的时候会自动检查dump.rdb 恢复其中的数据!

查看需要存在的位置：

 127.0.0.1:6379> config get dir
 1) "dir"
 2) "/data"

RDB手动触发： --save bgsave

Save - 不推荐使用：在主程序中执⾏会阻塞当前redis服务器，直到持久化工作完成,执行save命令期间,Redis不能处理其他命令,线上禁止使用
BGSAVE(默认)：Redis会在后台异步进行快照操作,不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程
可以通过lastsave命令获取最后一次成功执行快照的时间

RDB的优缺点：

优点:适合大规模的数据恢复!对数据的完整性要不高

缺点:需要一定的时间间隔进程操作!如果redis意外宕机了,这个最后一次修改数据就没有的了!fork进程的时候,会占用一定的内容空间

RDB配置文件关键点详解：

stop-writes-on-bgsave-error: 默认yes：如果配置成no,表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致,那么在快照写入失败时也能确保redis继续接受新的写请求
rdbcompression: 默认yes：对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能
rdbchecksum:默认yes：在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能
rdb-del-sync-files:在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no,此选项是禁用的

AOF：AOF保存的是 appendonly.aof 文件

默认是不开启的,我们需要手动进行配置!我们只需要将 appendonly 改为yes就开启了 aof!重启,redis就可以生效了!
aof默认就是文件的无限追加,文件会越来越大!如果aof文件大于 64m,太大了! fork一个新的进程来将我们的文件进行重写!

 appendonly no # 默认是不开启aof模式的,默认是使用rdb方式持久化的,在大部分所有的情况下,
 rdb完全够用!
 appendfilename "appendonly.aof" # 持久化的文件的名字
 # appendfsync always # 每次修改都会 sync。消耗性能
 appendfsync everysec # 每秒执行一次 sync,可能会丢失这1s的数据!
 # appendfsync no # 不执行 sync,这个时候操作系统自己同步数据,速度最快!
 # rewrite 重写

AOF - 优点：