Redis学习之Redis的持久化方式RDB与AOF

redis的持久化

RDB（redis database）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是我们经常说的快照snapshot,它恢复时是将快照文件直接读到内存里，redis会单独创建fork一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任务io操作的。这就确保了极高的性能，如果需要进行大规模的数据恢复，且数据恢复的完整性要求不是很高，那么使用RDB方式要比AOF方式更加的高效。EDB的缺点是最后一次持久化的数据可能会丢失

rdb保存的文件是dump.rdb

dbfilename dump.rdb # 配置文件中默认的文件名字

# 触发机制
save 900 1 # 900秒内至少有一个key进行了修改，触发快照
save 300 10 # 300秒内，10次的修改
save 60 10000 # 60秒内修改的10000次

触发机制

1、save的规则满足的情况下，会自动触发rdb

2、执行了flushall命令也会生成rdb文件（没有意义，这样生成的rdb文件中没有内容）

3、退出redis，也会生成rdb文件

备份就会自动生成一个dump.rdb文件

如何恢复rdb文件呢？

1、通过 config get dir 获得redis的工作目录

2、然后只需要将dump.rdb文件放在这个工作目录下即可

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" # 只需要将dump.rdb文件放到这个目录下，启动redis就会把数据读取到内存
127.0.0.1:6379>

优点：

• 适合大规模的数据恢复！dump.rdb
• 如果你对数据的完整性要求不高，

缺点：

• 需要一定的时间间隔进行操作，如果redis以外宕机，这个最后一次修改数据就会丢失
• fork进程的时候，会占用一定的内存空间

AOF（Append Only File）

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

Aof保存的是appendonly.aof文件

appendonly yes # 默认是不开启的，我们要设置为yes

appendfilename "appendonly.aof" # 默认生成appendonly.aof文件

# aof触发策略
appendfsync always # 每次修改都会同步，消耗性能
appendfsync everysec # 每秒同步一次，，默认
appendfsync no # 永不同步

aof文件的修复

如果aof有问题时候，那我们下次连接redis的时候将会报错 redis-check-aof --fix

[root@pihao bin]# redis-cli -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused # aof文件错误从而导致拒绝连接
not connected>

[root@pihao bin]# ls
appendonly.aof  cloud-id    cloud-init-per  dump.rdb      easy_install-3.6  jsondiff   jsonpointer  redis-benchmark  redis-check-rdb  redis-sentinel
chardetect      cloud-init  config          easy_install  easy_install-3.8  jsonpatch  jsonschema   redis-check-aof  redis-cli        redis-server
[root@pihao bin]# redis-check-aof --fix appendonly.aof # 使用redis-check-aof --fix 命令来修复aof文件
0x              32: Expected \r\n, got: 666a
AOF analyzed: size=68, ok_up_to=23, diff=45
This will shrink the AOF from 68 bytes, with 45 bytes, to 23 bytes
Continue? [y/N]: y
Successfully truncated AOF # 修复成功

# 重新连接redsi
[root@pihao bin]# redis-server config/redis.conf
10776:C 11 Jul 2020 11:00:23.244 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
10776:C 11 Jul 2020 11:00:23.244 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=10776, just started
10776:C 11 Jul 2020 11:00:23.244 # Configuration loaded
[root@pihao bin]# redis-cli -p 6379
127.0.0.1:6379> # 连接成功

优点和缺点

优点：

• 每一次修改都同步，数据的完整性较好
• 每秒同步一次，可能会丢失一秒的数据
• 从不同步，效率是最高的

缺点：

• 相对于数据文件来说，aof远远大于rdb,修复的速度也不如rdb
• aof运行效率也要比rdb慢，所以redis默认的配置就是rdb

重写规则说明

# 重写规则
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

这两个配置项的意思是，在aof文件体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写。我们可以修改这些参数达到自己的实际要求

扩展

• 只做缓存，如果你只是希望你的数据在服务器运行的时候存在，你可以不使用任何的持久化
• 同时开启两种持久化方式
  • 在这种i情况下，当redis重启的时候会优先加载aof文件来恢复原始的数据，因为在通常情况下aof文件保存的数据更加完整
  • rdb的数据不实时，同时使用两者时服务器重启也只会找aof文件，那要不要只使用aof呢？不用，因为rdb更适合用于备份数据库（aof在不断变化不好备份），快速重启，而且不会有aof可能潜在的bug,可以留着以防万一