Redis：AOF和RDB持久化

最新推荐文章于 2024-01-11 08:24:26 发布

我叫985

最新推荐文章于 2024-01-11 08:24:26 发布

阅读量577

点赞数 1

文章标签： redis 缓存数据库

本文链接：https://blog.csdn.net/yal_insist/article/details/129659796

版权

AOF 和 RDB

redis持久化就是将redis的数据存储在硬盘中，防止redis崩溃或者服务器重启后redis的数据丢失。redis持久化有2种方式，第一种是AOP（保存操作）；第二种是RDB（保存数据）。

AOF

AOF（append only file）持久化，采用日志的形式来记录每个写操作，追加到AOF文件的末尾。
Redis默认情况是不开启AOF的。重启时再重新执行AOF文件中的命令来恢复数据

AOF的问题

AOF是执行完命令后才记录日志的。为什么不先记录日志再执行命令呢？这是因为Redis在向AOF记录日志时，不会先对这些命令进行语法检查，如果先记录日志再执行命令，日志中可能记录了错误的命令，这样可能会导致Redis使用日志恢复数据时出错。
正是因为执行完命令后才记录日志，所以不会阻塞当前的写操作。但也因此会有两个风险：

更执行完命令还没记录日志时，宕机了会导致数据丢失
AOF不会阻塞当前命令，但是可能会阻塞下一个操作。

AOF回写策略

这两个风险最好的解决方案是折中妙用AOF机制的三种回写策略appendfsync 。

always，同步写回，每个子命令执行完，都立即将日志写回磁盘。
everysec，每个命令执行完先把日志写到AOF内存缓冲区，然后每隔一秒将内存缓存区的命令同步到磁盘。
no：只是先把日志写到AOF内存缓冲区，有操作系统去决定何时写入磁盘。

always同步写回，可以基本保证数据不丢失，no策略则性能高但是数据可能会丢失，一般可以考虑折中选择everysec。

AOF重写机制

如果接受的命令越来越多，AOF文件也会越来越大，文件过大还是会带来性能问题。日志文件过大怎么办呢？AOF重写机制！就是随着时间推移，AOF文件会有一些冗余的命令如：无效命令、过期数据的命令等等，AOF重写机制就是把它们合并为一个命令（类似批处理命令），从而达到精简压缩空间的目的。比如：先set key，后面del key，那这2条命令就可以压缩成一条；或者多次set key，只需要保留最后一次set key。
AOF重写会阻塞嘛？AOF日志是由主线程会写的，而重写则不一样，重写过程是由后台子进程bgrewriteaof完成。

AOF重写触发时机：

执行BGREWRITEAOF命令重写AOF日志时触发
使用CONFIG SET命令开启AOF日志时触发
当AOF日志超过基准大小的特定百分比时(参数auto-aof-rewrite-percentage控制)时触发。

AOF小结

优点：数据的一致性和完整性更高，秒级数据丢失。
缺点：相同的数据集，AOF文件体积大于RDB文件，恢复数据慢。

RDB

因为AOF持久化方式，如果操作日志非常多的话，Redis恢复就很慢。
RDB（Redis DataBase），就是把内存数据以快照的形式保存到磁盘上。和AOF相比，它记录的是某一时刻的数据，并不是操作。

什么是快照?可以这样理解，给当前时刻的数据，拍一张照片，然后保存下来。

RDB触发机制

RDB持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。RDB触发机制主要有以下几种：
在这里插入图片描述

RDB的问题

bgsave

使用bgsave去主动触发持久化，basave命令会fork一个子进程，虽然在持久化的过程种可以避免阻塞主线程，但是创建过程是会阻塞主线程的。

bgsave持久化过程中的数据的修改

在持久化的时候，数据能修改吗？ Redis借助操作系统的写时复制技术（copy-on-write），在执行快照的同时，能正常处理写操作。

RDB小结

优点：与AOF相比，恢复大数据集的时候会更快，它适合大规模的数据恢复场景，如备份，全量复制等
缺点：没办法做到实时持久化/秒级持久化。

如何选择AOF和RDB？

AOF因为每次执行完命令后都要回写硬盘，所以效率比较慢，但是能保证数据基本不丢失，而且它记录的是一条一条的操作，所以恢复数据也会更慢。
RDB因为备份的是当前的数据，所以备份会更快，恢复数据也更快，但是数据丢失的可能性更大。

如果数据不能丢失，RDB和AOF混用。Redis4.0开始支持RDB和AOF的混合持久化，即：使用RDB进行持久化，在两次RDB之间，使用AOF持久化（AOF优先使用everysec的写回策略）。这种方式即保障了性能，也保障了数据基本不丢失。
如果只作为缓存使用，可以承受几分钟的数据丢失的话，可以只使用RDB，这种方式性能最高。

使用redis客户端做实验

RDB 备份与恢复

# 查看dump.rdb的存放路径
config get dir

在这里插入图片描述

# 执行备份命令
set key1 'test1'
bgsave

# 等dump.rdb文件生成后在执行，测试redis宕机rdb会丢失2次快照间隔之间的数据
set key2 'test2'

然后过一会后就可以在rdb存放路径下看到生成好的dump.rdb文件
在这里插入图片描述

# 然后强制关闭redis，在重新开启redis，redis重启时会自动读取dump.rdb恢复数据
service redis-server stop
service redis-server restart

# 然后在keys，可见只返回了key1，key2在bgsave后redis宕机，丢失了
localhost:0>keys "*"
1) "key1"

AOF 备份与恢复

AOF持久化默认是关闭的，要开启AOF，去修改redis的config文件，然后在重启redis
在这里插入图片描述
开启AOF后，redis会在存放路径下生成appendonly.aof文件，该文件就是记录redis的操作的。

打开AOF文件，看看里面的内容，的确存的是操作而不是数据。

# 执行命令，然后在观察appendonly.aof的修改时间会立刻变化
set key1 'test1'
# 过一分钟后在执行命令，然后在观察appendonly.aof的修改时间会立刻变化。因为当前回写策略是'everysec'，所以每隔1秒会将命令回写到aof文件种
set key2 'test2'

# 把appendonly.aof重命名为appendonly2.aof，并且保留dump.rdb
# 强制关闭redis，然后重新打开
redis存放目录下会重新生成appendonly.aof，可见单单开启aof时，redis在启动的时候是不会加载dump.rdb的

# 强制关闭redis
# 把appendonly2.aof改名为appendonly.aof
# 重新打开redis
# redis在开启aof时，重启默认会加载appendonly2.aof恢复数据
localhost:0>keys "*"
1) "key2"
2) "key1"

RDB和AOF混用备份与恢复

4.0版本的混合持久化功能默认关闭，我们可以通过 aof-use-rdb-preamble配置参数控制该功能的启用。5.0 版本默认开启。
需要特别注意的是要开启混合持久化，必须同时设置 aof-use-rdb-preamble为yes ,开启 AOF持久化方式。

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
aof-use-rdb-preamble yes

# redis的配置文件说了，开启AOF和RDB混用之后，生成的aof文件内容格式是：
前半段是RDB格式
后半段是AOF格式

# 可以使用BGREWRITEAOF命令来手动触发一下aof的重写，可以快点看到aof文件格式的变化。
BGREWRITEAOF