Redis 持久化方案

梦里梦外; 2023-02-13 03:23 143阅读 0赞

### 目录 ###

*   *   *  RDB（默认）
         *   *  相关配置
             *  RDB持久化的执行过程 | 原理
         *  AOF
         *   *  相关配置
             *  AOF持久化的执行过程
             *  AOF重写机制
         *  RDB、AOF的比较 | 选择
         *  redis启动时的数据恢复策略
         *  手动同步数据到硬盘文件

redis提供了2种持久化方案：RDB，AOF。

关闭redis server时，会将内存中的数据持久化到硬盘；启动redis server时，会从硬盘加载数据到内存；redis server运行时，每隔一段时间会自动同步内初中的数据到硬盘。

### RDB（默认） ###

rdb是redis默认使用的持久化方案，隔一段时间同步一次，使用快照保存内存中的全量数据。

#### 相关配置 ####

在redis.conf中搜索rdb即可看到rdb相关配置  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]  
RDB默认设置了3种策略，分别对应redis服务器key的更新（增删改）频率

*  如果900s（即15min）内，对键值对的修改个数达到1，就同步数据到硬盘。对应修改频率低的情况。
 *  如果300s（即5min）内，对键值对的修改个数达到10，就同步数据到硬盘。对应修改频率一般的情况。
 *  如果60s（即1min）内，对键值对的修改个数达到10000，就同步数据到硬盘。对应修改很频繁的情况。

如果要禁用rdb，在下面加一行即可

save ""

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

*  默认持久化到硬盘出错时会停止接受写请求，防止新写入内存中的数据因为故障而丢失。
 *  默认会压缩.rdb文件的体积，压缩可以减小硬盘占用，但压缩时会加大cpu开销，cpu远比硬盘值钱，建议改为no。

#### RDB持久化的执行过程 | 原理 ####

达到同步要求后

*  fork：启动一个子进程，将内存中的全量数据写到一个临时文件中，写入完成后用临时文件替换原来的.rdb文件。
 *  cow（copy on write）：子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

### AOF ###

Append Only File，aof是把执行过的写指令记录到一个.aof文件中（相当于写指令的日志），启动redis server时，把.aof中的写指令重新执行一遍，还原数据。

#### 相关配置 ####

redis.conf中搜索append即可找到aof相关配置  
![在这里插入图片描述][2020052623320151.png]

*  默认没有开启aof，如果要启用aof，改为yes即可

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 2]  
往.aof文件追加写指令（同步）有3种策略

*  always 每执行完一条写指令，就往.aof文件中追加该指令，开销大、拉低服务器性能，但数据完整性最高，宕机最多丢失1个写指令
 *  no：把写指令放到缓冲区里，缓冲区满了才会写到.aof文件中，资源开销最小，但数据完整性最低，宕机时缓冲区里的写指令全部丢失
 *  everysec：上面2种的折中，每秒往.aof文件中追加一次，一次性写入这一秒内执行的所有写指令，宕机丢失上一秒内的写指令。默认使用everysec，一般也是使用这个。

#### AOF持久化的执行过程 ####

达到同步要求后，fork启动一个子进程，把新增的写指令添加到.aof文件中。

#### AOF重写机制 ####

.aof文件中的写指令越来越多，文件越来越大，还原数据越来越慢。当.aof文件体积达到阈值时自动启动一个子进程重写.aof文件，减少.aof中的（写）指令数量，以减小.aof文件体积、提高数据恢复速度。

hmset user name "zhangsan" age 20
    hset user name "lisi"
    hset user age 30
    
    #aof重写后，以上3条写指令会重写为一条，直接写为最终结果
    hmset user name "lisi" age 30

aof的重写策略  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 3]  
redis会记录上次aof重写后.aof文件的大小，如果redis启动后还没有重写过.aof文件，则默认取redis启动时.aof文件的大小。

以下2个条件，只要满足其中一个，就会触发aof重写

*  如果当前.aof文件的体积，比上一次重写后增加了百分之多少（默认100，即翻1倍），就自动重写aof文件。设置为0即禁用aof重写。
 *  如果aof文件的体积，比上一次重写后增加了多少（默认64mb），就自动重写aof文件。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 4]  
重写aof文件时是否不同步写指令到.aof文件中，默认no 要同步。

### RDB、AOF的比较 | 选择 ###

*  rdb是全量同步，尽管是fork一个子进程进行操作，但IO压力仍然较大，影响性能；aof只添加新增的写指令，资源占用少、时间开销小
 *  redis故障时，rdb数据丢失量往往比aof大，aof数据安全性、完整性更高
 *  rdb是将内存数据压缩保存为二进制文件，文件体积小；aof是将写指令保存在文本文件中，文件体积往往比rdb的大。
 *  rdb恢复数据时直接加在二进制流，数据还原快；aof需要重新执行一遍写指令，数据还原慢。

只使用rdb，故障时可能会丢失很多数据，数据完整性得不到保障；只使用aof，数据恢复慢，且aof重写机制较复杂，可能存在bug，从.aof文件恢复数据出错时往往需要与.rdb文件对照数据。

一般都是同时使用rdb、aof，rdb，可以同时保存多个时刻的内存全量数据，十分适合做冷备，aof数据完整性更好。

rdb可以保存多个时刻的快照，适合做冷备，aof适合做热备。一般同时使用rdb、aof，发生故障时先用rdb恢复数据，再用aof做数据补全。

### redis启动时的数据恢复策略 ###

同时使用rdb、aof，redis在启动时默认优先从aof恢复数据，因为aof的数据完整性更高

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

*  如果启用了aof，且aof文件存在，则执行aof文件中的写指令恢复数据
 *  如果未启用aof，或aof文件缺失，或aof恢复数据失败，且启用了rdb、rdb文件存在，则从rdb文件恢复数据

### 手动同步数据到硬盘文件 ###

除了自动同步以外，redis还支持手动同步

#在主线程中进行同步，会阻塞主线程，同步完成主线程才能继续处理读写请求，一般不使用
    save 
    
    #后台fork启动一个子进程进行同步
    bgsave

如果是生产环境，建议在夜深人静流量小的时候进行同步。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200526232213587.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200604121030972.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[2020052623320151.png]: https://img-blog.csdnimg.cn/2020052623320151.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200526233857117.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200527000437556.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/2020052700163539.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20210621235534299.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70#pic_center