Redis -持久化方式对比

清疚 2023-02-21 06:23 4阅读 0赞

redis 提供两种持久化方式，一种是RDB持久化（定时将数据被分到磁盘上），另一种是AOF（append only file）持久化（将对 redis 的操作日志以追加形式写入文件）

--------------------

# RDB持久化 #

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

## 配置方式 ##

在`redis.conf`中默认配置

#   save <seconds> <changes>
    
    # 时间策略
    # 900s (15min)内超过 1 个key被修改，则进行持久化
    save 900 1
    # 300s (5min)内超过 10 个key被修改，则进行持久化
    save 300 10
    # 60s 内超过 10000 个key被修改，则进行持久化
    save 60 10000
    
    # 文件名称
    dbfilename dump.rdb
    
    # 文件保存路径
    dir /home/suhw/data/redis
    
    # 如果持久化出错，主进程是否停止写入
    stop-writes-on-bgsave-error yes
    
    # 是否压缩
    rdbcompression yes
    
    # 导入时是否检查
    rdbchecksum yes

## 使用 ##

### **手动触发** ###

在 redis 中手动触发持久化可使用以下命令（一般只适用`bgsave`）

*  save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
 *  bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

### 自动触发 ###

*  根据 `save m n` 配置自动触发
 *  从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发`bgsave`
 *  执行`debug reload`时
 *  执行`shutdown`时，若没有开启`aof`，也会触发

## 执行流程 ##

![image-20200629095148565][]

## 优势 ##

1.  备份出的数据只包含一个文件，当系统出现灾难性故障时，恢复十分容易
2.  性能最大化，对于redis的服务进程来说，在开始持久化时，唯一需要做的就是fork出子进程，之后再由子进程完成持久化的工作，从而避免服务进程执行IO操作
3.  相比于AOF，如果数据量很大，RDB的启动效率会很高

## 劣势 ##

1.  在两次持久化之间若服务宕机，数据就会因为还未保存而丢失
2.  通过fork子进程完成持久化工作，若数据量较大时，可能会导致服务器暂时停止服务几百ms，或1s

--------------------

# AOF持久化 #

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

## 配置方式 ##

同样在`redis.conf`中默认配置文件672行

############################## APPEND ONLY MODE ###############################
    # 是否开启AOF，默认关闭（no）
    appendonly yes
    
    # 指定 AOF 文件名
    appendfilename appendonly.aof
    
    # Redis支持三种不同的刷写模式：
    # appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
    appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
    # appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
    
    #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
    #设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no
    no-appendfsync-on-rewrite no 
    
    #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
    auto-aof-rewrite-percentage 100
    
    #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
    auto-aof-rewrite-min-size 64mb

## 使用 ##

### 手动触发 ###

通过`bgrewriteaof`命令手动触发`AOF`持久化

### 自动触发 ###

根据`redis.conf`中的配置规则来触发

## 执行流程 ##

![image-20200629095239613][]

## 优势 ##

1.  对比RDB持久化，具有更高的数据安全性。redis 中提供了三种同步策略：每秒同步，每修改同步和不同步。
    
    1.  每秒同步也是异步完成的，但是若系统突然宕机，可能一秒中之内的数据将会丢失
    2.  每修改同步是效率最低的，每次发生数据的变化都会被立刻记录到磁盘中
2.  AOF对于日志文件采用的是追加模式，因此在写入过程中即使出现宕机，也不会破坏日志文件中已经存在的内容；若只写入一半数据就宕机，在redis下次启动时，可通过`redis-check-aod`工具来解决数据一致性的问题
3.  若日志文件过大，redis可自动启用rewrite机制。
4.  AOF包含一个格式清晰，易于理解的日志文件用于记录所有的数据修改操作。

## 劣势 ##

1.  对于相同数据量时，AOF文件通常大于RDB文件，并且RDB在恢复大数据量时速度要比AOF快
2.  根据同步策略的不同，AOF在运行效率上往往会慢于RDB

# 注 #

不论是RDB还是AOF都是先写入一个临时文件，然后通过 `rename` 完成文件的替换工作。

# 参考 #

*  https://www.php.cn/redis/421586.html
 *  https://blog.csdn.net/aitangyong/article/details/52072708

[image-20200629095148565]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9naXRlZS5jb20vc3VoYW93L25vdGUvcmF3L21hc3Rlci9pbWcvMjAyMDA2MjkwOTUxNTAucG5n?x-oss-process=image/format,png
[image-20200629095239613]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9naXRlZS5jb20vc3VoYW93L25vdGUvcmF3L21hc3Rlci9pbWcvMjAyMDA2MjkwOTUyNDAucG5n?x-oss-process=image/format,png