redis 持久化 RDB、AOF

最新推荐文章于 2024-08-21 14:59:54 发布

好运haoyun

最新推荐文章于 2024-08-21 14:59:54 发布

阅读量165

点赞数 1

CC 4.0 BY-SA版权

分类专栏： # Redis 文章标签： redis java 数据库 linux 缓存

本文链接：https://blog.youkuaiyun.com/qq_43439968/article/details/110391977

Redis 专栏收录该内容

11 篇文章

订阅专栏

Redis的持久化包括RDB和AOF两种方式。RDB在指定时间间隔做快照，适合大规模数据恢复，但可能丢失最后的修改。AOF记录所有命令，保证数据不丢失，但文件较大，恢复速度慢。AOF可通过appendfsync配置同步频率。在数据完整性要求高时，可启用AOF，反之则选择RDB。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Redis持久化

持久化RDB、AOF，重点

Redis是内存数据库，断电即失去，只要是内存数据库就一定会有持久化操作

RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入到磁盘中，Snapshot快照，恢复时将快照文件直接读到内存中

单独创建一个子进程，fork分支
将内存内容写入临时RDB文件
再用临时文件替换上次持久化完成的文件

整个过程主进程不进行任何io操作，保证了性能，如果进行大规模数据恢复，RDB和AOP都可以进行数据恢复，RDB数据恢复完整性不敏感，RDB更加高效，缺点时最后一次持久化后的数据可能丢失，默认使用的就是RDB，一般情况不需要修改这个配置

RDB保存的文件是dump.rdb

AOF保存的文件是appendonly.aof

配置快照在snapshots配置区域下

dump.rdb文件

通过Redis config get dir 获取
```
config get dir
```
触发机制
- save规则触发
- 执行flushall命令
- 关闭redis
备份会自动生成dump.rdb文件

如何恢复备份文件

只要将rdb文件放在redis规定的目录，redis启动时会自动检查dump.rdb文件恢复数据

查看位置，config get dir

在生产环境中最好对dump.rdb文件进行备份

RDB优缺点

优点：

父进程正常处理用户请求，fork分支一个子进程进行备份
适合大规模的数据恢复，如果服务器宕机了，不要删除rdb文件，重启自然在目录下，自动会读取

缺点：

需要一定的时间间隔，可以自行修改设置
如果redis意外宕机，最后一次的修改数据会丢失
fork进程的时候，会占用一定的内存空间

AOF（Append Only File）

将所执行的所有命令都记录下来，处读操作以外，恢复时重新执行一次，如果是大数据就需要写很久

aof默认是文件无限追加，大小会不断扩张

在主从复制中，rdb是备用的，在从机上使用，aof一般不使用

fork分支出子进程
根据内存中的数据子进程创建临时aof文件
父进程执行的命令存放在缓存中，并且写入原aof文件
子进程完成新aof文件通知父进程
父进程将缓存中的命令写入临时文件
父进程用临时文件替换旧aof文件并重命名
后面的命令都追加到新的aof文件中

开启AOF

配置文件Append Only Modo区块中设置

appendonly no
#默认关闭appendonly 手动设置yes开启

appendfilename "appendonly.aof"
#默认名字

# appendfsync always
appendfsync everysec
# appendfsync no
#每次都进行修改
#每秒钟都进行修改
#不进行修改

no-appendfsync-on-rewrite no
#是否进行重写

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
#percentage重写百分比
#重写时文件最小的体积


#一般保持默认，一般只需要开启

这些配置也能在连接redis后在redis中通过config set 进行更改

与RDB类似的触发机制，也能生成配置文件

进行了一些操作，如list在同一个key上覆盖值操作，aof是一同操作的，把之前的值进行了覆盖，但是保存的并不是最新的值，而是把全部进行的操作保存了下来，lpush lpop，当从aof文件中恢复数据时，不管最新的值是什么都重新的进行一遍操作，这样在时间上和效率上并不是最优的，但是能保证在每次的操作能进行备份，保证数据不丢失，如果出于绝对的安全考虑可以开启aof

aof文件损坏情况

人为测试aof文件损坏，aof文件是根据文件的大小进行比对，判断文件是否损坏，使用

haoyun@HAOYUN ~ % redis-check-aof --fix /usr/local/var/db/redis/appendonly.aof 
AOF analyzed: size=23, ok_up_to=23, diff=0
AOF is valid

损坏的aof会导致redis无法打开
这个修复真垃圾，给我数据删没了，删除规律数据不好修复，但是加入明显没有逻辑的错误，还是能修复
redis-check-rdb 能修复rdb文件

优缺点

优点：

可设置文件修改每次都同步备份，文件完整性更好，但是消耗性能
设置每秒同步一次可能会丢失一秒的数据
从不同步效率最高

缺点

对于数据文件，aof远远大于rdb，修复速度也比rdb慢
aof是io操作，所以默认是aof
aof文件会无限扩大