Redis实现持久化

﹏ヽ暗。殇╰゛Y 2023-10-09 22:27 26阅读 0赞

## 1、AOF持久化和RDB持久化都是Redis的两种数据持久化方式,各有优劣势: ##

**AOF持久化:**

> 优势:
> 
> > 1.  零丢失数据。AOF日志记录所有的写操作,保证数据绝对一致性,不会出现丢失。
> > 2.  支持部分数据恢复。可以只恢复AOF文件的某一部分,选择性恢复数据。
> > 3.  时间复杂度较低。因为只需要追加文件,所以时间复杂度是O(1)。
> 
> 劣势:
> 
> > 1.  体积过大。AOF文件会不断增长,体积较大,占用更多磁盘空间。
> > 2.  重写AOF性能影响较大。当AOF文件体积过大时,需要对AOF文件进行重写,这会对Redis性能产生较大影响。
> > 3.  恢复速度慢。要恢复 sehr 大量的数据时,AOF恢复速度通常较RDB慢,因为要重放很多命令。

**RDB持久化:**

> 优势:
> 
> > 1.  体积较小。RDB只包含某个时刻的数据,体积较小,占用较少磁盘空间。
> > 2.  恢复速度快。直接加载RDB数据快照到内存,恢复速度很快.
> > 3.  性能影响较小。周期性创建RDB快照的性能影响较小。
> 
> 劣势:
> 
> > 1.  数据丢失风险。如果Redis在两次快照之间发生故障,会导致中间的数据丢失。
> > 2.  不支持部分数据恢复。要么全部恢复RDB数据,要么完全不恢复,不支持选择性恢复。
> > 3.  定期全量备份会影响性能。创建RDB快照时,会对当前服务器性能产生一定影响

### **总结：** ###

AOF持久化可以保证数据零丢失,但同时也会产生体积过大和性能下降等问题。而RDB持久化可以最大程度减少资源消耗,但存在潜在的数据丢失风险。对于有高数据一致性要求的业务,可以同时使用AOF和RDB这两种持久化方式来弥补各自的不足,达到最佳的持久化效果。如果有比较灵活的数据要求,也可以根据实际情况选择一种持久化方式来使用。

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

## 2、AOF持久化和RDB持久化各有优势,在不同的情况下会有不同的使用建议: ##

*  **对数据一致性要求高**。如果业务对数据零丢失有较高要求,这时应该选择AOF持久化,或者同时使用AOF和RDB两种方式。AOF可以最大限度地保证数据不丢失。
 *  **重要性数据较多**。如果Redis中存储的关键数据较多,同样应考虑使用AOF持久化,或同时使用AOF+RDB的方案。
 *  **数据集较小**。如果Redis中数据量较小,可以单独使用RDB持久化。因为RDB占用空间小,性能影响也较小,适合数据集较小的场景。
 *  **内存空间不足**。如果服务器内存较小,也应该选择RDB持久化,因为RDB只会定期创建快照,不会 stair 占用较多内存,比较适合内存受限的环境。
 *  **部分数据恢复**。如果需要支持选择性恢复Redis中的部分数据,那么应选择AOF持久化。因为AOF文件记录的是所有写命令,可以只重放部分命令来达到选择性恢复的目的。
 *  **系统IO较弱**。如果服务器磁盘IO能力较弱,RDB会更加适合。因为RDB只需要周期性短时间创建快照文件,所以对磁盘IO的要求不高。而AOF需要频繁记录写命令,对磁盘IO性能要求较高。
 *  **数据集更新频繁**。如果Redis中数据更新非常频繁,AOF日志会快速增长,可能超过硬盘写入速度,这时RDB更适合。RDB只在一定周期创建快照,可避免AOF日志膨胀带来的影响。

### **总结：** ###

可以根据**数据量**、**一致性要求**、**服务器性能**以及**数据变更频率**等因素来判断使用AOF还是RDB,或两者结合使用。AOF确保数据零丢失,但会占用更多资源。RDB资源消耗少,但存在数据丢失风险。需要在两者之间权衡选择。

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

## 3、AOF和RDB配置 ##

### 1）AOF配置（**AOF默认不开启**） ###

在 /etc/redis 下，打开配置文件redis.conf进行修改：

## 1、AOF
    ############################## APPEND ONLY MODE ###############################
    #是否开启aof   
    #appendonly no
    appendonly yes
    # aof文件名字
    appendfilename "appendonly.aof"
    #写操作会触发IO，可以调整配置文件如下三种策略：
    # appendfsync always # 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
    # appendfsync no # redis不主动进行同步，把同步时机交给操作系统。
    appendfsync everysec # 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
    
    no-appendfsync-on-rewrite no
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    aof-load-truncated yes

### 2）RDB配置（RDB默认开启） ###

在 /etc/redis 下，打开配置文件redis.conf进行修改：

save 900 1
    save 300 10
    save 60 10000
    # save: 设置快照的触发条件，格式为：save <seconds> <changes>
    # 其中seconds表示指定时间间隔内的秒数，changes表示指定修改数量内的次数。
    # 当满足其中一个条件时，Redis 就会进行快照。
    
    
    stop-writes-on-bgsave-error yes # 在RDB执行时如果出现错误，是否停止写入。默认是yes。
    rdbcompression yes   # 是否压缩 RDB 文件。默认是yes。
    rdbchecksum yes  #是否对 RDB 文件进行校验和。默认是yes。
    dbfilename dump_6379.rdb  # 设置 RDB 文件名，默认是dump.rdb。
    dir /var/lib/redis/6379  # 设置 RDB 存储的路径，默认是Redis启动目录，一般需要指定其他路径
    rdb-del-sync-files no
    
    # rdb-del-sync-files是Redis的一个高级配置选项，在默认情况下不开启。
    # 当开启后，Redis在执行RDB持久化期间，将首先创建一个新的RDB文件，如果保存成功，则删除上一个RDB文件，并将新RDB文件重命名为原来的RDB文件名。具体来说，当开启rdb-del-sync-files选项时，Redis会在将新的RDB文件重命名为旧的RDB文件的同时将旧的RDB文件删除，这个动作是同步执行的，因此相当于在RDB文件的写入和删除之间插入了一个同步点。
    # 开启rdb-del-sync-files，可以将RDB生成和删除的CPU负载分散在时间上，从而减少对Redis操作的影响。但是需要注意的是，由于同时进行写入和删除的操作，所以会消耗更多的磁盘IO，因此在I/O繁忙的系统上，这个选项可能会影响Redis的性能表现。