Redis：AOF和RDB持久化

系统管理员 2024-03-25 21:16 118阅读 0赞

## 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触发机制主要有以下几种：  
![在这里插入图片描述][35e9651833c24c16805eafa647e8b383.png]

#### 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

![在这里插入图片描述][f221b3e4b8334d3e9965732835e6edf4.png]

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

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

# 然后强制关闭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  
![在这里插入图片描述][2132e249cd734456b999050d600b39e5.png]  
开启AOF后，redis会在存放路径下生成appendonly.aof文件，该文件就是记录redis的操作的。  
![在这里插入图片描述][ec01372d1a23439d8948aa57cc943dc4.png]  
打开AOF文件，看看里面的内容，的确存的是操作而不是数据。  
![在这里插入图片描述][c9d0d50b7bb949c083046b1870e69e87.jpeg]

# 执行命令，然后在观察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

然后打开aof文件  
![在这里插入图片描述][5a1fa8edcac64ec5943e31d4c6575f4b.png]

[35e9651833c24c16805eafa647e8b383.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/d813b4e9dffb461c8b3d1f931ac1d1b8.png
[f221b3e4b8334d3e9965732835e6edf4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/2aec7ec303f24cc295d742dc85e8d296.png
[cdbc5a0b99cc4669ab24a4b211e0e7cf.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/e5b72cfdc946452dabf20c7ba2c70d82.png
[2132e249cd734456b999050d600b39e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/27b73bbd3d40434f9d4adac3da33cc8e.png
[ec01372d1a23439d8948aa57cc943dc4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/22023e18e3fe43ab9daf060f5fea11dd.png
[c9d0d50b7bb949c083046b1870e69e87.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/571c8b5e8c4042898c27f55447234ec6.png
[5a1fa8edcac64ec5943e31d4c6575f4b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/4b30ad2477e240ec9b70027ef246a871.png