redis配置文件的持久化（详细对比）

爱被打了一巴掌 2023-07-09 10:29 105阅读 0赞

## 一、redis持久化方式 ##

Redis 提供了两种持久化方式，一种是基于快照形式的 RDB，另一种是基于日志形式的 AOF，每种方式都有自己的优缺点。

### 1.1、RDB持久化的概述 ###

*  RDB 基于内存快照，是 Redis 默认开启的持久化方式，并不需要我们单独开启。
 *  RDB 有两种持久化方式：手动触发 和 自动触发，手动触发使用以下两个命令：
    
     *  **save**：会阻塞当前 Redis 服务器响应其他命令，直到 RDB 快照生成完成为止，对于内存比较大的实例会造成长时间阻塞，所以**线上环境不建议使用**
     *  **bgsave**：Redis 主进程会 fork 一个子进程，RDB 快照生成有子进程来负责，完成之后，子进程自动结束，bgsave 只会在 fork 子进程的时候短暂的阻塞，这个过程是非常短的，所以**推荐使用该命令来手动触发**
 *  大部分情况，我们会通过配置 时间间隔 触发 RDB 文件写入。

### 1.2、AOF持久化 ###

*  Redis 默认并没有开启 AOF 持久化方式，需要我们自行开启，与 RDB 不同的是 AOF 是以记录操作命令的形式来持久化数据的，我们可以查看以下 AOF 的持久化文件 appendonly.aof
 *  appendfsync 的配置项有以下三种值可选：  
    always：每一次系统 serverCorn 函数调用就刷新一次缓存区  
    everysec：每秒执行一次磁盘写入，期间所有的命令都会存储在 aof 缓存区  
    no：不做控制，任由操作系统决定什么时候刷新缓冲区  
    redis 默认配置是 everysec，即每秒刷新一次缓存区。

## 二、redis 配置文件 ##

### 2.1、RDB 持久化配置 ###

*  save格式：  
    save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。

[root@localhost ~]# vim /etc/redis/6379.conf
    save 900 1
    save 300 10
    save 60 10000
    
    //生成快照失败时，主线程是否停止写入
    stop-writes-on-bgsave-error yes
     
    //是否采用压缩算法存储
    rdbcompression yes
     
    //数据恢复时是否检测 RDB文件有效性
    rdbchecksum yes
    
    //RDB快照生成的文件名称，一般采用默认的dump.rdb
    dbfilename dump.rdb
     
    //快照生成的路径，AOF也是存放在这个路径下面
    dir /var/lib/redis/6379

### 2.2、AOF持久化配置 ###

*  开启AOF 持久化就在 redis.conf 配置文件中将 appendonly no 调整为 appendonly yes 。

[root@localhost ~]# vim /etc/redis/6379.conf
    //开启AOF持久化
    appendonly yes   
    
    //AOF文件名称，默认值为 appendonly.aof
    appendfilename "appendonly.aof"
    
    # appendfsync always
    appendfsync everysec   默认推荐
    # appendfsync no
    
    //忽略最后一条可能存在问题的指令
    aof-load-truncated yes

### 2.3、AOF 重写 ###

*  理论上来说，随着 redis 服务器运行时间的持续，生成的 aof 文件只会越来越大，redis 提供 AOF 重写策略帮助优化和压缩 aof 文件。能将几百条甚至几千条的命令日志，重写优化成个位数。带给我们最直观的好处就是，aof 文件体积变小，数据恢复速度变快。
 *  一般来说，我们可以通过向 redis 服务器发送 bgrewriteaof 命令触发服务器对 aof 文件进行重写，如果当前有正在运行的重写子进程，则本次重写 会推迟执行，否则，直接触发一次重写。
 *  除此之外，我们还可以在配置文件中配置 aof 文件达到多大，自动触发文件重写。

vim /etc/redis/6379.conf
    
    //设置为yes表示rewrite操作不进行同步fsync,暂时存在内存中,避免造成磁盘IO操作冲突，默认为no，建议yes。
    no-appendfsync-on-rewrite no
     
    //当前aof文件大小超过上一次重写的aof文件大小的百分之多少时进行重写新的日志进程
    auto-aof-rewrite-percentage 100
     
    //允许重写aof文件的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的重写操作
    auto-aof-rewrite-min-size 64mb

## 三、RDB与AOF的持久化对比 ##

### 3.1、RDB 优缺点 ###

RDB 文件中保存的是 redis 内存中所有的数据一份快照。

*  优点：  
    1、相同的数据量下，rdb 文件要小于 aof 文件，且恢复速度要快于 aof  
    2、rdb 文件中是整个数据的完整备份快照，数据存储紧凑即便不同版本的 redis，也能顺利恢复  
    3、整个 rdb 持久化，只需要 fork 一个子进程进行持久化即可，父进程依然可以提供服务，效率最大化。
 *  缺点：  
    1、容易丢失数据，即便配置了事件时间触发备份，也至少丢失一秒数据  
    2、如果数据量太大，fork 子进程的时候会阻塞毫秒级别时间

### 3.1、AOF 优缺点 ###

AOF 是基于命令操作日志，每条更新命令都会被刷到缓存区，然后在特定的时间节点被写入 aof 磁盘文件。

*  优点：  
    1、相较于 RDB，AOF 数据可靠性更强，最多丢失一秒数据  
    2、数据库容错率变好，一些误操作可以通过直接改 aof 文件进行回退
 *  缺点：  
    1、AOF 文件通常较大且恢复效率比不上 RDB，不适合做数据冷备份

**总的来说，AOF 策略会使数据稳定性更高，具有更完整的数据备份，RDB 恢复效率高适合做灾难恢复，建议生产环境上两者都开启。**