Redis的RDB与AOF持久化机制

水深无声 2023-10-08 15:43 38阅读 0赞

所谓持久化，就是把缓存内容写进磁盘永久存储（你不删，磁盘不坏可不就是永久嘛）

## RDB ##

RDB 是 Redis 默认的持久化方案。  
RDB快照（Redis DataBase）：当满足`一定条件`的时候，会把当前内存中的数据写入磁盘，生成一个快照文件dump.rdb。  
还是先贴配置：

# 文件路径，
    dir ./
    # 文件名称
    dbfilename dump.rdb
    # 是否是 LZF 压缩 rdb 文件
    rdbcompression yes
    # 开启数据校验 sht
    rdbchecksum yes

Redis重启会通过dump.rdb文件恢复数据。那个`一定的条件`是啥呢？到底什么时候写入rdb 文件？

1.  自动触发
    
    1.  配置规则触发  
        redis.conf， SNAPSHOTTING配置，其中定义了触发 把数据保存到磁盘的 触发频率。 如果不需要 RDB 方案，注释 或者配置成空字符串 " " 。
    
    > save 900 1 \# 900 秒内至少有一个 key 被修改（包括添加）  
    > save 300 10 \# 300 秒内至少有 10 个key 被修改  
    > save 60 10000 \# 60 秒内至少有 10000 个 key 被修改  
    > 注意上面的配置是不冲突的，只要满足任意一个都会触发。
    
    1.  shutdown触发,保证服务器正常关闭，关闭的时候不会造成数据丢失
2.  手动触发  
    如果我们需要重启服务或者迁移数据，这个时候就需要手动触RDB快照保存。所以redis也提供了2种手动保存RDB快照的指令。
    
    1.  Save  
        save在生成快照的时候会阻塞当前Redis服务器，Redis不能处理其他命令。如果内存中的数据比较多，会造成Redis长时间的阻塞。生产环境不建议使用这个命令。为了解决这个问题，Redis 提供了第二种方式。
    2.  bgsave  
        执行bgsave时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。  
        具体操作是Redis进程执行fork（创建进程函数）操作创建子进程(copy-on-write)，RDB持久化过程由子进程负责，完成后自动结束。它不会记录 fork之后后续的命令。阻塞只发生在fork阶段，一般时间很短。用lastsave 命令可以查看最近一次成功生成快照的时间。

演示一次RDB快照恢复数据的一个过程！（我的快照在src下面）  
我们首先添加一份数据并且备份到RDB：

redis> set k1 1
    redis> set k2 2
    redis> set k3 3

查看数据是否存在：

redis>keys *

我们进行shutdown操作触发RDB快照：（模拟意外断电）

redis> shutdown

对现有RDB数据进行备份cp：

redis>cp dump.rdb dump.rdb.bak

启动redis：

redis> src/redis-server& redis.conf

发现数据都还在，现在模拟数据丢失（手动清一下）

redis> flushall

停服务器再启动

redis> shutdown
    redis> src/redis-server& redis.conf

发现数据已经丢失，我们现在就要从我们备份的数据恢复，先关闭

redis> shutdown

删除原RDB备份数据cd .

redis>rm dump.rdb

将备份数据改名为dump.rdb

mv dump.rdb.bak dump.rdb

重启服务

src/redis-server& redis.conf

自己看一下数据喽（手动滑稽）

我们知道了RDB的实现的原理逻辑，那么我们就来分析下RDB到底有什么优劣势。  
一、优势  
1．RDB是一个非常紧凑(compact类型)的文件，它保存了redis在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。  
2．生成RDB文件的时候，redis主进程会fork()复刻一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。  
3．RDB在恢复大数据集时的速度比AOF的恢复速度要快。  
二、劣势  
1．RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行 fork 操作创建子进程，频繁执行成本过高。  
2．在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。  
所以，针对与这种情况，redis又提供了一种持久化机制，就是AOF持久化机制！

## AOF ##

Append Only File的简称，只加载文件，这个方案在redis默认是不开启的。

AOF是怎么恢复的？

AOF`采用日志的形式来记录每个写操作，并追加到文件中`。开启后，执行更改 Redis数据的命令时，就会把命令写入到AOF文件中。`Redis重启时会根据日志文件的内容把写指令`从前到后执行一次`以完成数据的恢复工作`。

那么它从哪里开启，又有些什么特性？

还是贴配置：  
配置文件redis.conf

# 开关
    appendonly no
    # 文件名
    appendfilename "appendonly.aof"

### 同步机制 ###

AOF,会记录每个写的操作，那么问题来了？我难道每次操作命令又得跟磁盘交互？  
当然不行，所以，redis支持几种策略，由你们自己来决定要不要每次都跟磁盘交互。

> # appendfsync always 表示每次写入都执行fsync(刷新)函数 
    > # appendfsync everysec 每秒执行一次fsync函数 默认1s一次，最多有1s丢失
    > # appendfsync no 由操作系统保证数据同步到磁盘，速度最快

### 重写机制（rewrite） ###

**为什么要重写**？  
比如，我们用分布式锁，指令是setnx,然后设置过期日期；由于是每次都是命令追加。那么1年后，10年后，我们会发现这个aof文件里面全都是这样的指令！！  
我一个1T的aof文件，竟然全都是这个2个指令。所以我们需要重写。

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

**怎么重写**：  
4.0版本之前，是比较指令并去除无效指令  
假如：aof文件里这样几个指令：

redis> lpush huihuilist a
    redis> lpush huihuilist b c d
    redis> lpop huihuilist

就会重写成

redis> lpush huihuilist a b c

后来人们发现，这种方法效率很低，需要一个一个区比对！  
所以，4.0之后引入了RDB 跟AOF 混合的模式，让RDB跟AOF一起使用，因为RDB的速度快，那么我们就引入这个特点，根据RDB模式，将以前的指令以二进制的方式覆盖到aof,后面写入的继续追求到文件后面。（混合模式默认是开启，也可以关闭）

aof-use-rdb-preamble yes //是否开启RDB与AOF混合模式

**什么时候重写**？

配置文件redis.conf

# 重写触发机制
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb 
    //最开始aof文件必须要达到这个文件大小时才触发，后面的每次重写就不会根据这个变量了

说明一下上述配置的意义：

> 在 aof 文件小于64mb的时候不进行重写，当到达64mb的时候，就重写一次。  
> 重写后的 aof文件可能是20mb。上面配置了auto-aof-rewrite-percentag为100，  
> 即 aof文件到了40mb的时候，又开始重写一次。以此类推。

我们知道了AOF的实现原理，我们来分析下它的优缺点。

一、优点  
能最大限度的保证数据安全，就算用默认的配置everysec，也最多只会造  
成1s的数据丢失。  
二、缺点  
数据量比RDB要大很多，所以性能没有RDB好，没有一个性能保证！  
那我们平时开发中应该使用哪种持久化呢？  
如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定  
时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复  
数据集的速度也要比AOF恢复的速度要快。

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

[92af341d6faa4884a5b937def8e82b1f.png]: https://img-blog.csdnimg.cn/92af341d6faa4884a5b937def8e82b1f.png