Redis持久化RDB、AOF原理及对比

亦凉 2023-10-02 15:45 5阅读 0赞

## Redis 持久化 ##

### 1.RDB ###

#### 1.1.概念 ####

RDB全称 redis database Backup file 即redis数据备份文件。

相当于把redis内存中的所有数据拷贝到磁盘保存起来。保存的文件称为快照文件也叫RDB文件（默认保存在当前运行目录

Redis发生故障重启后能够从磁盘中读取快照文件恢复数据，保障其数据不丢失。

#### 1.2.持久化方式 ####

redis-cli 建立连接

save 主进程执行（会阻塞其他所有命令）

bgsave 后台开启子进程执行（异步持久化

bgsave基本流程：

*  Fork 主进程的到一个子进程，共享内存空间
 *  子进程读区内存数据并写入新的RDB文件
 *  用新RDB文件替换旧的RDB文件

*redis 停机时会执行一次RDB*

#### 1.3.RDB触发机制（redis.conf文件 ####

##### 1.3.1.持久化规则 #####

# 900秒内，如果至少有一次修改，则执行bgsave。
    save 900 1
    # 如果是 save "" 则表示禁用RDB
    save ""

##### 1.3.2.其他配置 #####

# 是否压缩，建议不开启，压缩会消耗cpu
    rdbcompression yes
    # RDB文件名称
    dbfilename dump.rdb
    # 文件保存的路径目录（  ./ 代表当前运行目录
    dir ./

#### 1.4.fork原理 ####

bgsave 是开启一个子进程异步完成内存数据的读取和写入，几乎可以做到对主进程的0阻塞，但是子进程是fork主进程得来的，fork过程中主进程不能接受其他请求

##### 1.4.1.页表 #####

在linux中进程不能直接操作物理内存，而是由操作系统给每个进程分配一个虚拟内存，主进程只能操作虚拟内存，而后会维护一张虚拟内存和物理内存的映射关系表，称之为页表。

主进程操作虚拟内存，而虚拟内存基于页表的映射关系进行内存数据的读与写。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16]

##### 1.4.2.fork实现主进程与子进程的数据共享 #####

执行fork会创建一个子进程，fork不是把内存数据做拷贝，而是把页表的映射关系拷贝给子进程，当子进程操作自己的虚拟内存时映射关系一样，因此实现了子进程和主进程的内存数据共享

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 1]

##### 1.4.3.脏数据的解决 #####

但是由于子进程在进行读操作的同时，主进程能接收用户请求进行读写操作，如果进行写操作则会产生脏数据

fork采用copy-on-write技术解决脏数据的问题

*  当主进程执行读操作时可以直接访问共享内存
 *  当主进程执行写操作时则会拷贝一份数据，执行写操作（但要注意内存溢出问题）

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 2]

#### 1.5.RDB缺点 ####

持久化间隔期时间长，如果进行两次RDB之间写数据会有数据丢失风险

fork子进程，压缩和写出RDB文件比较耗时

### 2.AOF持久化 ###

AOF全称为Append Only File（追加文件），AOF会记录Redis操作的所有写命令，是一个不断累加的操作。可以看作是命令日志文件

#### 2.1.AOF原理![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 3] ####

AOF文件格式： $ 后面的数字是当前字符的长度

如果服务宕机导致数据丢失，可以通过读取aof文件，执行命令将文件还原

#### 2.2.AOF配置 ####

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
    appendonly yes
    # AOF文件的名称
    appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
    appendfsync always 
    # 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
    appendfsync everysec 
    # 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
    appendfsync no

三种策略对比：

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

#### 2.3.AOF文件重写 ####

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。  
![在这里插入图片描述][470bfedfe545406a9186a86aac5dfb0b.png]

如图，AOF原本有三个命令，但是`set num 123 和 set num 666`都是对num的操作，第二次会覆盖第一次的值，因此第一个命令记录下来没有意义。

所以重写命令后，AOF文件内容就是：`mset name jack num 666`

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
    auto-aof-rewrite-percentage 100
    # AOF文件体积最小多大以上才触发重写 
    auto-aof-rewrite-min-size 64mb

### 3.RDB与AOF对比 ###

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会**结合**两者来使用。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 4]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/07a7519478ae486b9c9e2d65ae6dd1f5.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAaVN5TWlrYXNhbu6Ukw==,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/915fc48125a546c4ac62490c2c2560d9.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAaVN5TWlrYXNhbu6Ukw==,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/c6b4696533c546498c7d2a3762dfb901.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAaVN5TWlrYXNhbu6Ukw==,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 3]: https://img-blog.csdnimg.cn/1e46008fe3f144f38f14a680bae628c5.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAaVN5TWlrYXNhbu6Ukw==,size_20,color_FFFFFF,t_70,g_se,x_16
[ce6f24e7a1ee4f249d440b9c9ee5b5bb.png]: https://img-blog.csdnimg.cn/ce6f24e7a1ee4f249d440b9c9ee5b5bb.png
[470bfedfe545406a9186a86aac5dfb0b.png]: https://img-blog.csdnimg.cn/470bfedfe545406a9186a86aac5dfb0b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAaVN5TWlrYXNhbu6Ukw_size_20_color_FFFFFF_t_70_g_se_x_16 4]: https://img-blog.csdnimg.cn/c4e93165568c4c13bc021376041fae4c.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBAaVN5TWlrYXNhbu6Ukw==,size_20,color_FFFFFF,t_70,g_se,x_16