redis(三)redis持久化

雨点打透心脏的1/2处 2022-11-15 01:14 172阅读 0赞

### 文章目录 ###

*   *  持久化方式
     *  RDB
     *   *  RDB工作机制
         *  保存策略
         *  RDB属性设置
         *  触发持久化的方式
         *  优缺点
     *  AOF
     *   *  保存策略
         *  AOF属性设置
         *  AOF文件的修复
         *  AOF的rewrite机制
         *  优缺点
     *  应用场景

## 持久化方式 ##

redis主要工作在内存中。内存本省就不是一个持久化的设备，断电后数据会清空。但是redis提供了持久化方式。个人看来 这是redis提供了一种备份机制，可以将内存中的数据持久化到磁盘上，有利于这些热点数据的备份恢复和迁移。

redis提供了两种持久化方式，分别是RDB 和AOF

RDB持久化方式能够在指定的时间间隔对数据进行快照存储

AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，个人认为类似于MySQL的binlog日志

## RDB ##

RDB：在指定的时间间隔内将内存中的数据写入磁盘，它恢复时是将文件读取到内存中。  
RDB是默认开启的

### RDB工作机制 ###

工作机制：每隔一段时间，就会把内存中的数据保存到硬盘上的指定文件中。

RDB在持久化时会单独创建一个fork子进程来进行持久化操作，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。  
整个过程中，主进程work是不会进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模的数据恢复，RDB性能比AOF好很多。

### 保存策略 ###

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

### RDB属性设置 ###

<table> 
 <thead> 
  <tr> 
   <th>属性</th> 
   <th>含义</th> 
   <th>默认</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save</td> 
   <td>保存策略</td> 
   <td>默认开启三个 也就是15分钟1个key则保存</td> 
  </tr> 
  <tr> 
   <td>dbfilename</td> 
   <td>RDB 快照文件名</td> 
   <td>dump.rdb</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>

### 触发持久化的方式 ###

1、基于自动保存策略  
2、执行save，或者bgsave命令，执行时save时是阻塞状态  
3、执行 shutdown 命令时，也会主动地备份数据。  
4、执行 flushdb 命令，也会产生 dump.rdb，但里面是空的，没有意义

### 优缺点 ###

**优点**  
1、RDB是一个文件，保存了某个时间点的数据集，非常适合用于数据集的备份。  
2、压缩格式 恢复速度快  
**缺点**  
1、（可能有 但是我没找到）没有设置固定大小的策略，随着业务量的增加 只能任由rdb文件增大  
2、不是实时的，可能会丢数据，操作比较重。  
3、fork时内存中的数据被克隆了一份，大概2倍的膨胀。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjUwNjU5OQ_size_16_color_FFFFFF_t_70]  
**备份脚本**

每小时备份一次rdb文件
     crontab  -e
    0 */1 * * * cp /etc/redis/dump.rdb  /etc/redis/dump.rdb`date +%Y%m%d%H`

## AOF ##

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

### 保存策略 ###

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即 1 秒钟的数据）。

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

### 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>

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

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

### AOF的rewrite机制 ###

AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增加了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

**重写原理**  
AOF文件持续增长而过大时，会fork出一条新进程来将文件重新（也就是先写临时文件最后rename），遍历新进程的内存中数据，每条记录有一条set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和RDB快照相似。

**触发机制**  
redis会记录上次重写时AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。

### 优缺点 ###

**优**  
1、备份机制更稳健，丢数据概率更低  
2、可读的日志文本，通过操作AOF文件，可以处理误操作。  
**缺**  
1、比起RDB占用更多的磁盘空间  
2、恢复备份速度要慢  
3、每次读写都同步的话，有一定的性能压力

**两种备份方式的有优先级**  
如果同时开启两种持久化方式：  
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不是实时的，同时使用两者时服务器重启也只会找AOF文件。那要不要只用AOF呢？  
也不建议，因为RDB更适合备份数据库，进行快速重启。

## 应用场景 ##

一、服务器卡死或者redis卡死  
如果数据不是很重要 建议直接使用RDB恢复。  
恢复步骤：  
1、移动AOF文件（因为默认是从AOF文件reload）  
2、检查RDB文件 进行redis restart 重新reload RDB文件

二、人为误删除部分数据  
数据不重要：删除了就删除吧  
数据重要：AOF恢复

三、人为误删除全部数据  
数据不重要：使用crontab 定时备份任务 备份的RDB文件进行恢复  
数据重要：使用AOF的方式，vim appendonly.aof文件，将flushall命令删除后进行重启redis  
四、误删除AOF文件  
误删除了 就是没了。只能从现在再开始记录。  
五、误删除RDB文件  
save \\bgsave触发条件会再次自动生成dump.rdb 是无所谓的

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjUwNjU5OQ_size_16_color_FFFFFF_t_70]: /images/20221022/26a60acff1ef42a7be66995b244e63d5.png