【Redis学习笔记】第六章 Redis持久化

朱雀 2024-04-08 09:19 41阅读 0赞

#### 文章目录 ####

*  1、持久化
 *  2、持久化的思路
 *  3、RDB
 *   *  3.1 RDB-save
     *  3.2 RDB-bgsave
     *  3.3 RDB自启动--save配置
     *  3.4 RDB的特殊启动方式
 *  4、AOF
 *   *  4.1 AOF持久化数据三种策略(appendfsync)
     *  4.2 AOF相关配置
     *  4.3 AOF重写
     *  4.4 各持久化策略下AOF重写流程
 *  5、RDB与AOF的对比

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

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

## 1、持久化 ##

服务器意外断电或者软件崩溃，等一切恢复后，经常看到一些自动恢复文件：  
![在这里插入图片描述][c8890ecf3c854819a6aed28ac4574557.png]

这其中的过程就是内存和磁盘之间的数据保存：  
![在这里插入图片描述][d2ae6aa2cd294f5f9e5ec0d03f032d85.png]

> 持久化：  
>   
> 利用永久性存储介质将数据进行保存，在发生意外时将保存的数据进行恢复的工作机制称为持久化。

持久化机制可以防止数据的意外丢失，确保数据安全性。

## 2、持久化的思路 ##

*  将当前数据的状态进行保存，快照的形式，在Redis中称RDB
 *  将操作过程进行保存，日志的形式（类比ctrl+z与ctrl+y），在Redis中称AOF  
    ![在这里插入图片描述][867f0dd862b645f38a64bc2b8c09f9e7.png]

## 3、RDB ##

### 3.1 RDB-save ###

> **指令**：save  
> **作用**：手动保存一次数据

RDB在redis.conf中的相关的配置：

*  dbfilename dump.rdb  
    这里规定了save后保存的文件名，长设置为dump-端口号.rdb
 *  dir  
    文件保存位置，包含日志文件、持久化文件，常设置成空间较大的目录，目录起名data
 *  rdbcompression yes  
    设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩。设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
 *  rdbchecksum yes  
    设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行。通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

***以下模拟验证save的效果：
    //添加数据并save
    set name 9527
    save
    
    //杀掉对应进程模拟故障
    ps -ef |grep -i redis
    kill -s 9  26862  
    
    //连接Redis，查看数据name依然存在
    keys *

![在这里插入图片描述][4f962a890f7d49bab2acc7d3565dc98e.png]  
注\*\*

**`由于是单线程，save指令的执行会阻塞当前Redis服务器，直到当前RDB完成，可能造成长时间阻塞，不建议线上环境用。`**

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

### 3.2 RDB-bgsave ###

> **指令**：bgsave  
> **作用**：手动发起保存操作，Redis保存了这个操作，不立即执行，在合适的时候执行。

127.0.0.0:6379 > bgsave
    Background saving started

bgsave执行后如下：若daemonize yes，则日志中可看到返回消息，若daemonize no，则控制台可看到返回消息。  
![在这里插入图片描述][73cd8b5393424c318744d40abb3f6fe6.png]

bgsave在redis.conf中的相关的配置参数：

*  除了save的四个外，bgsave还有其特有的stop-writes-on-bgsave-error yes，即后台存储过程中如果出现错误现象，是否停止保存操作，常为yes

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

### 3.3 RDB自启动–save配置 ###

如何实现当满足某些条件时，让redis服务器发起RDB指令？

> **`save配置`**
> 
>  *  配置  
>     save second changes  
>       
>     
>  *  作用  
>     在限定的时间范围内，key的变化(增减)数量达到指定值即进行持久化  
>       
>     
>  *  参数  
>     second：监控的时间的范围  
>     changes：监控周期内key的变化量  
>       
>     
>  *  位置  
>     conf文件中进行配置  
>       
>     
>  *  示例  
>     save 900 10  
>     900秒之内key变化了十个，就存一次

save配置的原理图：  
![在这里插入图片描述][b691de39460747d4a197b384140fcc21.png]  
注意：

*  不进行数据比对，即两次set改同一个东西，也认为是两个key发生变化了
 *  `save配置启动后执行的是bgsave操作`
 *  配置的频度过高或者过低都会出现性能问题，要结合实际业务进行设置

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

### 3.4 RDB的特殊启动方式 ###

*  全量复制
 *  服务器运行过程中重启：debug reload
 *  关闭服务器时指定保存数据：shutdown save

RDB三种启动方式的对比（dbsave和save配置文件一样）  
![在这里插入图片描述][3d8bcf5c11d84f29a3653e1c499b701a.png]  
RDB优点：

*  RDB文件是一个紧凑压缩的二进制文件，存储效率高
 *  RDB存储的是数据快照，适用于数据备份、全量复制等场景
 *  RDB恢复数据的速度比AOF快很多
 *  应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

RDB缺点：

*  无法实时持久化，有可能丢数据
 *  RDB基于快照思想，每次读写都是全部数据，数据量巨大时，效率很低
 *  bgsave的运行要执行fork操作创建子进程，会损失一点性能
 *  Redis众多版本中rdb文件格式不统一，可能有数据格式不兼容现象

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

## 4、AOF ##

> AOF(append onlyfile)持久化：  
>   
> 以独立日志的方式**记录每次写命令**，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF解决了持久化实时性的问题，是Redis持久化的主流方式。

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

### 4.1 AOF持久化数据三种策略(appendfsync) ###

>  *  **always(每次)**  
>     每次操作都同步到.aof文件中，数据零误差但性能损失太大  
>       
>     
>  *  **everysec(每秒)**  
>     每秒将缓冲区的指令同步到.aof文件中，数据准确性较高，性能较高，系统宕机损失1秒数据  
>       
>     
>  *  **no(系统控制)**  
>     由操作系统控制每次同步到.aof文件的周期，整体过程不可控

### 4.2 AOF相关配置 ###

修改redis-6379.conf：
    
    # AOF功能开启
    appendonly yes
    # 选择策略
    appendfsync always|everysec|no
    # 配置AOF持久化的文件名,默认为appendonly.aof,常用appendonly-端口号.aof
    appendfilename filename
    # 持久化文件的保存路径,和RDB一样
    dir

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

### 4.3 AOF重写 ###

面对以下场景，不再应该单纯的记录三条set指令，这对后续数据恢复无意义。  
![在这里插入图片描述][f59f470c19d64301a7924f4a53f132eb.png]  
AOF重写就是将对同一个数据的若干条指令，按照最终执行的结果转化成对应的指令进行记录。这样既能降低磁盘占用，也能提高数据恢复的效率。

> **`AOF重写方式--手动重写`**
> 
>  *  **手动重写指令**：  
>     bgrewriteaof  
>     其执行的流程图如下：  
>     ![在这里插入图片描述][f4f6c33e989e41aaab55ce88a446fb47.png]

> **`AOF重写方式--自动重写`**
> 
>  *  自动重写触发条件设置一  
>     auto-aof-rewrite-min-size size  
>     对比参数：  
>     aof\_current\_size  
>     触发条件：  
>     aof\_current\_size>auto-aof-rewrite-min-size size时触发自动重写机制
> 
> --------------------
> 
>  *  自动重写触发条件设置二  
>     auto-aof-rewrite-percentage percent  
>     对比参数：  
>     aof\_base\_size  
>     触发条件：  
>     ![在这里插入图片描述][ebbe6026d2a64d039f60d7ebfd06333b.png]
> 
> --------------------
> 
> aof\_current\_size和aof\_base\_size这两个对比参数可以通过指令info查看。也可通过配置文件修改。

### 4.4 各持久化策略下AOF重写流程 ###

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

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

## 5、RDB与AOF的对比 ##

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

*  RDB与AOF的选择各有利弊
 *  不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
 *  能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
 *  灾难恢复选用RDB
 *  双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

[894c31fbc6b7483b87da740bd37794a9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/1e6b15f0dfee4ce3ac1a8065bb86bf36.png
[c8890ecf3c854819a6aed28ac4574557.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/aa59413a1f7a41afbc1c2f69713d0d67.png
[d2ae6aa2cd294f5f9e5ec0d03f032d85.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/6f55dbb96e9e4c119fb8aedfe6013075.png
[867f0dd862b645f38a64bc2b8c09f9e7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/14c904845328460daa3855722ce5b47a.png
[4f962a890f7d49bab2acc7d3565dc98e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/b82eccac6acd4a03b406feea57d41b9e.png
[73cd8b5393424c318744d40abb3f6fe6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/bedfde9235904e678d6893a0abcf3ed2.png
[b691de39460747d4a197b384140fcc21.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/39050625e11c48b89f00c6ef867f4527.png
[3d8bcf5c11d84f29a3653e1c499b701a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/8fe418830ffa45fe8f144de831deddf7.png
[ecfbd718525e4b8e8f8f4ceb6d024b5c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a9929397e99c4f2ab1068f65cc67606e.png
[76f19dc5a70c4eac9c7659c9619988a9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/784178d62e084984968515db4763f440.png
[f59f470c19d64301a7924f4a53f132eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/8a49a983b6c642efad71555663268220.png
[f4f6c33e989e41aaab55ce88a446fb47.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/ece3618f8ec5438f81ab26095c9e6a5c.png
[ebbe6026d2a64d039f60d7ebfd06333b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/cb645dbf54924ef89630a6a58a6cd14f.png
[c4b3f5a5ce014a538d76b54750b79952.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/e3ee907fe6cf4b64b6535fd1c3dc5702.png
[acb29268c3ea4b1a970cb31b0866acac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/5fe71f6e7f7143ab8b3b20c08c084cf0.png
[a80d9990005e4547a77c1e36f80ff784.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/bda800dd65bf4900b4efdf5c79ba99d7.png