Redis的持久化方式

系列文章目录

第一节 Redis的安装
第二节 Redis的五种数据结构（String、Hash、List、Set、ZSet）

---

---

前言

本节整理一下Redis的几种持久化方式

一、RDB快照

如果使用rdb快照方式，在默认情况下，redis会把内存数据保存在名字为dump.rdb的二进制文件中。
关于此种方式，可在redis.conf文件中进行设置，例如以下的配置项：

save 5  1
save 10 10
save 20 30
save 60 10000   #关闭RDB只需要将所有的save配置项注释屏蔽后重启

上面的配置项含义为：让redis在N秒内数据集至少有M个改动，例如save 60 1000，也就是说当在60秒内至少有1000个键被改动

---

除了配置save保存策略外，还可以手动执行save命令生成RDB快照，进入redis客户端执行命令save或者bgsave可以生成dump.rdb文件，每次执行命令都会将所有的redis内存快照到一个新的rdb文件中，并都会覆盖原有的rdb快照文件（所以说不可能配置为修改几条命令就进行持久化，因为当数据量大的时候，会消耗内存，影响redis的性能）

1、save与bgsave的对比

需要注意的是执行save命令会阻塞客户端执行其它命令，属于同步操作，而bgsave不会阻塞，因为其需要fork子线程进行异步操作，但是它会消耗内存（存在COW写时复制），另外就是redis配置的后台自动生成rdb文件使用的就是bgsave方式和。

2、bgsave的写时复制（COW）机制

1、简单来说，就是指在生成快照文件的同时，依然可以正常处理写命令。bgsave子进程是由主进程fork生成，可以共享主线程内所有内存数据。
2、bgsave子进程运行后，开始读取主进程的所有内存数据，并将其写入rdb快照文件，此时如果主进程对这些数据是读操作，那么主进程和bgsave子进程互不影响，但是如果主进程是对内存数据进行写操作，那么要被修改的这部分数据会被复制一份，生成该数据的副本，然后bgsave子进程会把副本数据写入rdb文件，而在这个过程中，主线程依然可以直接修改原来的数据。
3、总的来说，如果执行bgsave操作耗时长的时候，此时主线程对内存数据进行写操作，写操作的这部分数据也会被子线程持久化到rdb快照文件中。

二、AOF(append-only file)

对比rdb快照方式，当redis程序异常故障宕机，那么服务器将丢失还未持久化到rdb快照文件的内存数据，而aop持久化则是一种完全耐久的方式，aop持久化指的是将修改的每一条指令记录进文件appendonly.aof（先写入os cache，每隔一段时间fsync到磁盘）。

打开AOF功能

appendonly yes

开启之后，每当redis执行一个改变数据集的命令时（注意是改变数据集，读数据不算，例如set、lpush、hset等），就会将这个命令追加到AOF文件的末尾，这样每当redis重启后，程序就可以通过重新执行AOF文件中的命令来进行恢复数据（即回放执行）。

Fsync刷新策略

1、appendfsync always：每次有数据修改发生时就执行一次fsync，非常慢，也非常安全
2、appendfsync everysec：每秒钟同步一次，该策略为AOF的缺省策略，足够快，并且在发生故障时只会丢失1S的数据。推荐此种策略，兼顾了速度和安全性
3、appendfsync no：从不fsync，将数据交给操作系统来处理，更快，也更不安全

AOF重写

为什么会有重写这个操作？

AOF文件中可能有太多没用的指令，所以AOF方式会定期根据内存的最新数据生成aof文件。
例如以下情况：
对key为number进行incr操作

没重写之前的aof文件（记录了所有操作的incr命令，总共执行incr五次）：

重写后的aof文件(重写后将其优化为set number 5)：

重写开启方式

手动重写：redis客户端执行命令bgrewriteaof重写

注意：bgrewriteaof与bgsave命令类似，不会对redis正常命令处理有太多的影响，都是fork出子进程去操作

自动重写：redis.conf提供的配置可开启自动重写
1、auto-aof-rewrite-percentage 100 #aof文件自上一次重写文件大小增长了100%再次触发重写
2、auto-aof-rewrite-min-size 64mb #aof文件大小至少达到64M才会触发自动重写，文件太小，重写意义不大

三、RDB与AOF，我应该用哪一种？

命令	RDB	AOF
启动优先级	低	高（同时启用RDB和AOF，优先使用AOF文件恢复数据）
文件体积	小（二进制文件）	大（文本文件，后期越来越大）
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定，可最多丢1秒数据

四、Redis4.0混合持久化

混合持久化是为了解决什么问题？

重启redis时，RDB方式很少被使用来恢复内存数据，因为会丢失大量的数据，所以通常都是用AOF文件重放，但是AOF文件重放相对RDB又要慢很多，所以会导致redis实例很大的情况下，启动要花费很长的时间，混合持久化就是为了解决这个问题，在使用AOF文件来恢复数据时，不要花费太长的时间。

开启混合持久化

aof-use-rdb-preamble yes

开启混合持久化后，AOF在重写时，不仅是把内存数据转换为RESP命令写入AOF文件，而是把重写这一刻之前的内存数据做RDB快照处理，然后将RDB快照的二进制内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，等到重写完毕，才把新的AOF文件替换旧的AOF文件。
相比AOF全量文件重放，混合持久化可以先加载RDB的内容，然后再重放增量AOF日志，重启效率大幅得到提升。

总结

以上就是今天要讲的内容，介绍了Redis的几种持久化方式，下一节我们将介绍Redis的主从架构。