关于redis:Redis-系列redis-学习八redis-持久化-RDB-和-AOF

Redis 长久化

redis 是内存数据库，如果不将内存中数据库保留到磁盘上，那么服务器一旦宕机，或者 redis 过程退出，不仅数据会被失落，服务器中的数据库状态也会被失落

因而 redis 提供了长久化的性能

redis 的长久化分为 RDB 和 AOF

RDB（Redis DatabBase）

在主从复制中，rdb 文件都作为备用的，放在从机下面

在指定工夫距离内将内存中的数据集快照写入到磁盘中，这就是快照 snapshot，复原快照的时候，是把快照文件读入到内存中。

redis 通过 fork 的形式创立一个子过程来专门做长久化的动作，

• 先将数据写入到一个临时文件中，待长久化过程完结，再用这个临时文件替换上一次的长久化好的文件

整个过程中，主过程是不进行工作 IO 操作的，这就保障了极高的性能

如果须要 进行大规模的数据恢复，且对于数据的完整性要求不那么敏感和严格，抉择 RDB 的长久化形式比 AOF 的长久化形式更优，更加高效。

RDB 尽管性能高，然而在 最初一次长久化后的数据可能会被失落，redis 默认就是应用的 RDB 长久化形式，个别状况下也不须要批改

save 60 3

# The filename where to dump the DB
dbfilename dump.rdb

dir ./

咱们设置 60s 内若 有操作 redis 3 次，那就做一次长久化

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get dir
1) "dir"
2) "/root"
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK

dump.db 文件是生成在 dir 目录下的，咱们这里的 dir 目录是 /root

进行上述操作之后，咱们发现 /root 生成了 dump.rdb 文件，咱们将该文件删除掉，再尝试一次

root@iZuf66y3tuzn4wp3h02t7pZ:~# rm dump.rdb -rf
root@iZuf66y3tuzn4wp3h02t7pZ:~# redis-cli
127.0.0.1:6379> set p1 1
OK
127.0.0.1:6379> set p2 1
OK
127.0.0.1:6379> set p3 3
OK
root@iZuf66y3tuzn4wp3h02t7pZ:~# ls
dump.rdb

果然也是失常生成的

长久化的触发机制

• 依照 save 的规定满足的状况下，就会触发长久化，例如上述的 60s 操作 redis 3 次就会触发 1 次长久化
• 执行 flushall 命令的时候，也会触发长久化，生成 dump.db 文件
• 退出 redis 的时候，也会触发长久化，生成 dump.db 文件

备份就会主动生成一个 dump.db 文件

如何复原长久化文件

1、只须要将 dump.db 文件放到 redis 的启动目录即可，redis 启动的时候会将该文件读入到内存中，进行数据恢复

2、查看 redis 的启动目录能够这样做

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

这一块的配置，咱们基本上不须要批改太多，默认的配置根本就够用了

RDB 的劣势

• 适宜大规模的数据恢复
• 对数据的完整性要求不高

RDB 的劣势

• 须要在肯定的工夫距离进行操作，如果 redis 意外宕机，最初一次写入的数据就会失落
• fork 子过程的时候须要占用肯定的空间

AOF 长久化形式

AOF 是什么？

将咱们的写命令全副记录下来，复原的时候，将文件中的记录全副执行一遍

AOF 是 redis 的另外一种长久化形式，以日志的模式记录每一个写操作，将 redis 执行过的写操作全副记录下来，只容许追加文件，不容许改写文件

redis 启动的时候就会读取这个 aof 文件重建数据库，也就是说，redis 重启的时候，就会依据日志文件的内容将写指令依照写入程序执行，实现数据恢复

aof 保留的是 appendonly.aof 文件

# Please check https://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

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

auto-aof-rewrite-min-size 64mb

当 aof 文件大于 64 mb 的时候，就会再创立一个子过程来写一个新的 aof 文件

对于 aof 的配置基本上其余的都是应用默认的配置即可，咱们只须要把 aof 模式关上即可

appendonly yes

默认 appendonly 是不开启的，咱们批改了配置之后，重启 redis-server 就会马上失效

重写规定阐明

aof 默认是对文件有限追加，文件必然会越来越大

批改 redis.conf 为 aof 模式后，重启 redis-server 能够看到 appendonly.aof 文件

redis 客户端连贯 server 进行操作 redis，简略的设置几个值

root@iZuf66y3tuzn4wp3h02t7pZ:/# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name xiaozhu
OK
127.0.0.1:6379> set age 19
OK
127.0.0.1:6379> set hobby play
OK
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> shutdown
not connected>

查看 appendonly.aof 文件

appendonly.aof 文件外面寄存的就是咱们操作 redis 的写命令的记录

这个时候，咱们认为的在 appendonly.aof 文件中批改一些值

set
$2
k2
$2
v2
*3
$3
set
$2
k3
$2
ashdkklasdjkkv3        # 批改了这一行

启动 redis-server，查看是否能够复原数据

root@iZuf66y3tuzn4wp3h02t7pZ:/# redis-server /usr/local/redis/redis-6.2.5/redis.conf
root@iZuf66y3tuzn4wp3h02t7pZ:/# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>
root@iZuf66y3tuzn4wp3h02t7pZ:/# ps axu |grep redis
root      1251  0.0  0.0  14436  1048 pts/0    S+   14:55   0:00 grep --color=auto redis
root@iZuf66y3tuzn4wp3h02t7pZ:/#

发现 redis-server 启动失败，是因为咱们的 appendonly.aof 文件被人为的批改过，此时咱们须要修复该文件，redis 有提供工具批改 aof 文件，redis-check-aof

应用指令：

redis-check-aof --fix appendonly.aof

# redis-check-aof --fix appendonly.aof
0x              ce: Expected \r\n, got: 6864
AOF analyzed: size=223, ok_up_to=181, ok_up_to_line=47, diff=42
This will shrink the AOF from 223 bytes, with 42 bytes, to 181 bytes
Continue? [y/N]: y
Successfully truncated AOF
root@iZuf66y3tuzn4wp3h02t7pZ:/# redis-server /usr/local/redis/redis-6.2.5/redis.conf
root@iZuf66y3tuzn4wp3h02t7pZ:/# redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get k1
"v1"

修复 aof 文件后，咱们再次启动 redis-server 来回复磁盘数据，复原胜利，nice

aof 的劣势和劣势

劣势

• 每一次操作 reids 都会被记录，文件的完整性好
• 每秒同步一次，可能会失落一秒的数据
• 从不同步，这个效率是最高的

劣势

• 绝对于数据文件来说，aof 文件会远大于 rdb 文件，修复的速度也比 rdb 文件慢
• aof 运行的效率比 rdb 慢，所以 redis 默认的配置是 rdb 长久化

小结

两种长久化形式简述

• RDB 长久化的形式可能在指定的工夫距离内对数据进行快照存储
• AOF 长久化的形式记录每次对服务器的写操作，当服务器重启或者宕机的时候，会从新执行这些记录外面的写操作命令来复原数据，AOF 命令以 redis 协定追加保留每次写操作到文件开端，redis 还能对 aof 文件进行后盾重写，是的 AOF 文件的体积不至于过大
• 如果需要是只做缓存，只冀望服务器运行的时候数据存在，那么不必做长久化

两种长久化形式的开和不开

• 能够同时开启两种长久化形式

  • 这种状况下，redis 重启会先载入 aof 文件来复原数据，因为通常状况下 aof 文件保留的数据集比 rdb 的数据集要残缺
  • rdb 数据集不是实时的，同时应用两种形式时，服务器重启有只会找 aof 文件，那么要不要只应用 aof 文件呢？

  redis 的作者倡议是不要只应用 aof 文件，因为 rdb 更加适宜用于备份数据库，因为 aof 在一直的变动，不好备份，疾速重启的时候，rdb 不会有 aof 可能潜在的 bug，留着 rdb 做一个兜底的机制

性能上的倡议

对于 rdb 长久化

• 因为 rdb 文件只用于备份数据，倡议只在 slave 下面长久化 rdb 文件，15 分钟长久化一次就够了，也就是这一条指令 save 900 1

• 如果关上 aof 长久化，益处就是在极其状况下失落数据也不会超过 2s 的数据，启动脚本就简略的加载本人的 aof 文件即可，这样做也是有代价的

  • 代价之一就是 这样做带来了继续的 IO 操作
  • 代价之二就是 AOF 重写的最初将重写过程产生新数据写入到新文件造成的阻塞是不可避免的，只有硬盘许可，应该要尽量的缩小 aof 重写的频率

对于 aof 长久化

• aof 重写的根底大小值是 64 mb，咱们能够设置成 5g 以上，默认超过原大小 100% 大小重写，这个参数能够设置成一个正当的参数

• 如果不关上 aof 模式，仅仅靠主从复制实现高可用也是能够的，可能省掉一大笔 IO 耗费，也缩小了重写带来零碎的性能稳定，这样做依然是有代价的

  • 代价之一就是 如果主备 redis 同时挂掉（例如断电），会失落十几分钟的数据，启动脚本也要比拟主备的 rdb 文件，载入较新的那个 rdb 文件

参考资料：

redis_doc

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 小魔童哪吒，欢送点赞关注珍藏，下次见~