Redis的持久化操作

ゝ一世哀愁。 2023-01-11 03:57 126阅读 0赞

# Redis的持久化操作 #

## 一、持久化的目的 ##

Redis主要是工作在内存中。内存本身就不是一个持久化设备，断电后数据会清空。所以Redis在工作过程中，如果发生了意外停电事故，如何尽可能减少数据丢失。 将内存中的数据，备份到磁盘！

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

## 二、RDB ##

### 2.1 RDB简介 ###

RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

工作机制：每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。  
RDB是默认开启的！

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。 redis服务在每次启动时，会自动根据配置的dump文件的路径，加载所有的dump文件到内存！

### 2.2 RDB保存策略 ###

save 900 1 900 秒内如果至少有 1 个 key 的值变化，则保存  
save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存  
save 60 10000 60 秒内如果至少有 10000 个 key 的值变化，则保存  
save “” 就是禁用RDB模式；

redis的主进程，调用fork函数，复制一个子进程，子进程和主进程共享资源！

*  如果使用save命令，主进程阻塞，子进程将内存中的数据持久化到磁盘！
 *  如果使用bgsave，主进程不阻塞，子进程将内存中的数据持久化到磁盘！

### 2.3 RDB常用属性配置 ###

<table> 
 <thead> 
  <tr> 
   <th>属性</th> 
   <th>含义</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save</td> 
   <td>保存策略</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>dbfilename</td> 
   <td>RDB快照文件名</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>dir</td> 
   <td>RDB快照保存的目录</td> 
   <td>必须是一个目录，不能是文件名。最好改为固定目录。默认为./代表执行redis-server命令时的当前目录！</td> 
  </tr> 
  <tr> 
   <td>stop-writes-on-bgsave-error</td> 
   <td>是否在备份出错时，继续接受写操作</td> 
   <td>如果用户开启了RDB快照功能，那么在redis持久化数据到磁盘时如果出现失败，默认情况下，redis会停止接受所有的写请求</td> 
  </tr> 
  <tr> 
   <td>rdbcompression</td> 
   <td>对于存储到磁盘中的快照，可以设置是否进行压缩存储</td> 
   <td>如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话， 可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。</td> 
  </tr> 
  <tr> 
   <td>rdbchecksum</td> 
   <td>是否进行数据校验</td> 
   <td>在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗， 如果希望获取到最大的性能提升，可以关闭此功能。</td> 
  </tr> 
 </tbody> 
</table>

### 2.4 RDB数据丢失的情况 ###

两次保存的时间间隔内，服务器宕机，或者发生断电问题。  
![在这里插入图片描述][20210126200825856.png]

### 2.5 RDB的触发 ###

*  ①基于自动保存的策略
 *  ②执行save，或者bgsave命令！执行时，是阻塞状态。
 *  ③执行flushall命令，也会产生dump.rdb，但里面是空的，没有意义。
 *  ④当执行shutdown命令时，也会主动地备份数据。

### 2.6 RDB的优缺点 ###

> **优点：** 全量备份，非常适合容灾恢复！  
>  rdb文件格式紧凑(对比aof)，节省磁盘空间！  
> **缺点：** 一旦redis服务宕机，至少会丢失最后一次备份到现在的数据！相对(对比aof)不安全！

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

## 三、AOF ##

### 3.1 AOF简介 ###

*  AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都把新建、修改数据的命令保存到指定文件中。Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
 *  默认不开启，需要手动开启
 *  AOF文件的保存路径，同RDB的路径一致。
 *  AOF在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
 *  当RDB和AOF存的不一致的情况下，按照AOF来恢复。因为AOF是对RDB的补充。备份周期更短，也就更可靠。

### 3.2 AOF保存策略 ###

*  appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！
 *  appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。
 *  appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

### 3.3 AOF常用属性 ###

<table> 
 <thead> 
  <tr> 
   <th>属性</th> 
   <th>含义</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>appendonly</td> 
   <td>是否开启AOF功能</td> 
   <td>默认是关闭的</td> 
  </tr> 
  <tr> 
   <td>appendfilename</td> 
   <td>AOF文件名称</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>appendfsync</td> 
   <td>AOF保存策略</td> 
   <td>官方建议everysec</td> 
  </tr> 
  <tr> 
   <td>no-appendfsync-on-rewrite</td> 
   <td>在重写时，是否执行保存策略</td> 
   <td>执行重写，可以节省AOF文件的体积；而且在恢复的时候效率也更高。</td> 
  </tr> 
  <tr> 
   <td>auto-aof-rewrite-percentage</td> 
   <td>重写的触发条件</td> 
   <td>当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写</td> 
  </tr> 
  <tr> 
   <td>auto-aof-rewrite-min-size</td> 
   <td>设置允许重写的最小aof文件大小</td> 
   <td>避免了达到约定百分比但尺寸仍然很小的情况还要重写</td> 
  </tr> 
  <tr> 
   <td>aof-load-truncated</td> 
   <td>截断设置</td> 
   <td>如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load</td> 
  </tr> 
 </tbody> 
</table>

### 3.4 AOF文件的修复 ###

如果AOF文件中出现了残余命令，会导致服务器无法重启。此时需要借助redis-check-aof工具来修复！  
命令： redis-check-aof --fix 文件

### 3.2 优缺点 ###

> **缺点：**
> 
>  *  比起RDB占用更多的磁盘空间
>  *  恢复备份速度要慢
>  *  每次读写都同步的话，有一定的性能压力
>  *  存在个别Bug，造成恢复不能

> **优点：**  
>  - 备份机制更稳健，丢失数据概率更低
> 
>  *  可读的日志文本，通过操作AOF稳健，可以处理误操作

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][20210126201628572.png]

## 四、备份建议 ##

### 4.1 如何看待数据“绝对”安全 ###

Redis作为内存数据库从本质上来说，如果不想牺牲性能，就不可能做到数据的“绝对”安全。  
RDB和AOF都只是尽可能在兼顾性能的前提下降低数据丢失的风险，如果真的发生数据丢失问题，尽可能减少损失。  
在整个项目的架构体系中，Redis大部分情况是扮演“二级缓存”角色。  
二级缓存适合保存的数据

*  经常要查询，很少被修改的数据。
 *  不是非常重要，允许出现偶尔的并发问题。
 *  不会被其他应用程序修改。

如果Redis是作为缓存服务器，那么说明数据在MySQL这样的传统关系型数据库中是有正式版本的。数据最终以MySQL中的为准。

### 4.2 官方建议 ###

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

官方推荐两个都用；如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能出现Bug;如果只是做纯内存缓存，可以都不用

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70]: /images/20221119/dee09d9c7c21415b8f50abb63a222690.png
[20210126200825856.png]: /images/20221119/59a6e443b5954988952062a069491ac2.png
[20210126200950935.png]: /images/20221119/122b212181c44f488c498b8ac4a322a8.png
[20210126200958104.png]: https://img-blog.csdnimg.cn/20210126200958104.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210126201556364.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw==,size_16,color_FFFFFF,t_70
[20210126201628572.png]: https://img-blog.csdnimg.cn/20210126201628572.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210126201809384.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw==,size_16,color_FFFFFF,t_70