redis专题：redis的持久化方式有哪些？redis数据的备份和恢复策略

Mike

　　
　　文章目录

• 
  
  
  
  • 1. 为什么要做redis持久化？
    
  • 2. 持久化方式之---RDB快照（snapshot）
    
  • 3. 持久化方式之---AOF（append-only file）
    
  • 4. 持久化方式之---混合持久化
    
  • 5. RDB和AOF的区别，应该用哪一个？
    
  • 6. redis数据的备份与恢复
    
  
  

　　
1. 为什么要做redis持久化？
　　在web项目中，从前台打过来的请求一般会经过redis，如果redis中有，就直接返回，redis中没有再去访问数据库，有效的减轻了数据库的压力。在很多大型互联网公司中，对于redis的依赖程度很大，他们为了提升系统性能，把很多很多数据都存放在redis中，如果redis挂掉且没有做持久化，那么redis中的数据将无法恢复，就会有很多请求都打到数据库，数据库很可能承受不住而挂掉！所以在使用redis时一般要开启持久化

2. 持久化方式之—RDB快照（snapshot）
　　RDB快照是redis的默认持久化方式，在默认情况下， Redis 将redis数据快照保存在名字为 dump.rdb 的二进制文件中，此文件内容为二进制文件。
　　下图为redis内部目录：

dump.rdb文件内部的数据以二进制的形式存储，样式如下：

　　可以在redis的配置文件redis.conf中修改dir配置项来改变dump.rdb文件的存储位置

　　redis中默认的rdb保存方案为：N 秒内数据集至少有 M 个改动，则触发一次保存操作

save 900 1 900秒内至少有一个改动
save 300 10300秒内至少有10个改动
save 60 1000060秒内至少有10000个改动

　　当然你也可以对以上操作进行修改，可以修改为：

save 60 999 60秒内有至少有999个键被改动

　　如何关闭rdb持久化方案呢？只需要将所有的save保存策略注释掉即可！

//关闭 rdb 持久化方式！
#save 900 1 
#save 300 10
#save 60 10000

　　还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。
　　问题一：redis持久化是否会阻塞客户端其他请求命令呢？
　　如果redis中文件较多，在使用rdb持久化方式时，需要花费一定时间。redis为我们提供了 同步和异步 两种方式来进行持久化！当我们马上需要持久化时，如果此时还未达到配置文件中的持久化时机，可以使用save或bgsave命令来立刻进行持久化。如果redis内存很大，推荐使用bgsave来持久化，redis默认的持久化命令也是bgsave！
命令savebgsaveIO类型同步异步是否阻塞其他redis是否(在生成子进程执行调用fork函 数时会有短暂阻塞)复杂度O(n)O(n)优点不会消耗额外内存不阻塞客户端命令缺点阻塞客户端命令需要fork子进程，消耗内存　　bgsave的写时复制机制
　　bgsvae是由redis的主线程fork 生成的子线程，可以共享主线程的所有内存数据。当redis中的数据量很大时，使用bgsave把主线程数据写入RDB文件可能需要一段时间，在这段时间内如果主线程中有命令读写数据时：
　　①：读数据，此时主线程和bgsave子线程互不影响。
②：修改数据，运用写时复制，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据再写入 RDB 文 件
　　bgsave借助操作系统提供的写时复制技术，在生成快照的同时，依然可以正常处理读写命令。
　　问题二：RDB持久化存在的问题
　　使用RDB持久化需要配置 N秒内数据集至少有M个改动，则触发一次保存操作，这种方式不可能天衣无缝，在极端情况下可能会丢失最后一次保存时机 到 redis发生宕机 这段时间内的数据！

3. 持久化方式之—AOF（append-only file）
　　AOF持久化与RDB不同的是：AOF持久化的命令，RDB持久化的是数据。 AOF通过命令来恢复数据，相对较慢；而RDB直接恢复二进制数据，恢复速度比AOF快，但AOF的持计划策略相对于RBD更加安全一些。
　　AOF持久化默认是关闭的，需要手动开启，开启后会根据持久化策略把修改命令保存起来，查询命令不会持久化，停止redis时会执行一次持久化，配置以下选项开启AOF：

appendonly yes  设置为yes代表开启
appendfilename "appendonly.aof"aof存储的文件名，可修改
dir ./aof文件目录，与rdb文件共用

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

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

　　命令set 1 1 经过AOF持久化后在appendonly.aof文件中存储结果如下

// set 1 1 命令aof存储结果如下：
*3当前命令由3个字段组成 (set、1、1）
$3第1个字段的长度：set = 3
set第1个命令字段
$1第2个字段的长度：1 = 1
2第2个命令字段
$1第3个字段的长度：1 = 1
2第3个命令字段

　　问题：AOF重写是什么？有什么作用？
　　由于AOF文件体积较大，恢复数据慢，所以redis对AOF进行了优化，就是AOF重写！
　　案例如下，当我们执行了很多重复的自增命令时

127.0.0.1:6379> incr readcount
1
127.0.0.1:6379> incr readcount
2
127.0.0.1:6379> incr readcount
3
127.0.0.1:6379> incr readcount
4
127.0.0.1:6379> incr readcount
5

　　AOF在保存时会先把这五条自增命令全部保存到AOF文件中去，但是触发了AOF重写条件后，会删除之前冗余的5条incr readcount命令，直接设置readcount = 5 ！节省了部分内存空间。重写后AOF文件里如下：

*3
$3
SET
$2
readcount
$1
5

　　通过如下两个配置可以控制AOF自动重写频率，默认如下：

//aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-min-size 64mb
//aof文件自上一次重写后文件大小增长了100%则再次触发重写 
auto-aof-rewrite-percentage 100

　　当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF！，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响

4. 持久化方式之—混合持久化
　　redis宕机重启时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。通常使用 AOF执行命令的形式来恢复数据，虽然相对安全一点，但恢复速度要比RDB慢很多。这样在 Redis 实例很大的情况下，启动需要花费很长的时间。Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。
　　混合持久化的基础是AOF，相当于AOF持久化方式的增强版，所以开启混合持久化之前必须先开启AOF!!

aof-use-rdb-preamble yes  开启混合持久化！

　　如果开启了混合持久化，那么在AOF重写时(redis的数据大小=上文配置的64Mb时)，不再像AOF一样把redis数据以命令的形式存储在aof文件中，而是把发生重写时redis中的数据以rdb的形式存储起来，在生成rdb数据的过程中，如果有新的命令操作redis，那么这些新增的命令以AOF数据的形式和rdb数据存在一起。
　　新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
　　使用混合持久化目的是：在redis宕机重启时，可以先加载 RDB 的内容，然后再执行增量 AOF 命令日志就可以完全替代之前的 AOF 全量命令执行，因此重启效率大幅得到提升。
　　混合持久化AOF文件结构如下

开启混合持久化的appendonly.aof文件内容构成如下：


5. RDB和AOF的区别，应该用哪一个？
命令RDBAOF恢复速度速度快，直接复制数据速度慢，需要执行很多命令数据安全性容易丢数据根绝策略决定，安全性高体积小大启动优先级低高　　如果启用两种持久化方式，那么持久化时即会生成RDB文件，也会生成AOF文件。redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。
　　生产环境中更推荐混合持久化方式！因为混合持久化方式既保证了相对安全，又保证了数据恢复速度。但他依赖于AOF持久化，所以开启了混合持久化方式，就可以关闭RDB持久化方式了！

6. redis数据的备份与恢复
　　①：redis的数据恢复
　　redis数据恢复非常简单，首先要在redis.conf配置文件中配置好持久化数据存储目录，当redis宕机重启时，只需要把 appendonly.aof 或 dump.rdb文件按照配置放入对应目录，redis会自动检测此位置的文件，并自动恢复数据！！
　　②：redis数据备份
　　由于redis数据恢复依赖于 appendonly.aof 或 dump.rdb文件，所以redis数据备份也就是针对于rdb或aof的备份，备份策略如下：

• 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
  
• 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
  
• 每次copy备份的时候，都把太旧的备份给删了
  
• 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏