Redis系列之持久化机制RDB和AOF

1. 为什么需要持久化？

Redis的数据是保存在内存中的，如果每次关闭或者机器断电，就会出现数据丢失，所以需要进行持久化保存处理

2. 持久化的方式

Redis进行持久化保存的方式主要有两种：RDB和AOF，在redis官网也有进行介绍： https://redis.io/docs/manual/persistence/

3. RDB机制

3.1 RDB机制介绍

RDB，Redis Database快照，是Redis默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写到磁盘，生成一个快照文件，默认的文件名为dump.rdb

3.2 配置RDB

可以在redis.conf配置RDB文件的文件名和路径

  # The filename where to dump the DBdbfilename dump.rdb # 文件路径dir ./

3.3 什么时候触发

• 自动触发

  • 配置触发

    # 在redis.conf配置，配置300s检查一次，至少有1个key被修改就触发
    save 300 10 
    

  • shutdown关闭触发

    在redis执行shutdown正常关闭的时候会去持久化数据到磁盘

  • flushall命令触发

    清空数据操作会触发RDB操作，并且生成一个空的RDB文件，所以，如果没有开启其它持久化方式的时候，使用flushall是很危险的，在生产环境慎用

• 手动触发

  • save

  • bgsave

    在redis-cli使用save和bgsave命令

  127.0.0.1:6379> save
  OK
  127.0.0.1:6379> bgsave
  Background saving started
  127.0.0.1:6379>
  

  save和bgsave对比

  命令	save	bgsave
  IO类型	同步	异步
  阻塞	是	是（发生在fork）
  复杂度	O(n)	O(n)
  消耗内存	不会消耗额外内存	fork消耗内存
  备份	主线程去进行备份，备份期间不会去处理其它的指令，其它指令必须等待	子线程去进行备份，其它指令正常执行

3.4 操作实例

添加一些数据

127.0.0.1:6379>set k1 1
127.0.0.1:6379>set k2 2
127.0.0.1:6379>set k3 3

查询验证数据是否保存成功

127.0.0.1:6379>keys *

shutdown操作触发RDB进行快照

127.0.0.1:6379>shutdown

在redis目录里对dump.rdb文件进行备份，备份一份新的dump.rdb.backup，然后重新启动redis

然后再来模拟一些删库跑路

127.0.0.1:6379>flushall

然后关闭redis服务端，再启动，发现数据已经丢失，要恢复数据，只能先删了dump.rdb，再将备份的dump.rdb.backup改为dump.rdb，重启redis，发现数据已经恢复

3.5 RDB优势和不足

• RDB的优点：

  Redis官网总结归纳的redis RDB的优点

  

  • RDB是个紧凑型的文件，适合容灾备份，恢复速度非常快

  • RDB最大限度的提高性能，会fork一个子进程，父进程不会产生磁盘io

  • 可以做到很快的重启

    简而言之，RDB备份与恢复都非常的快

• RDB的不足：

  

  • 数据安全性不是很高，因为是根据配置的时间来备份，假如每5分钟备份一次，就可能会有5分钟数据的丢失

  • 经常fork子线程，所以会比较耗CPU，对CPU不是很友好

4. AOF机制

由于RDB的数据安全性不是很好，所以redis又提供了另外一种持久化方案，AOF

4.1 什么是AOF机制？

AOF：Append Only File，顾名思义，就是一种追加文件的意思，工作机制比较好理解，redis会将每一个收到的写命令通过write函数追加到文件中，通俗理解就是日志记录

AOF机制默认是关闭的，你可以在配置文件中开启，找到redis.conf

# 默认是关闭的，可以进行开启
appendonly no
# The name of the append only file (default:"appendonly.aof")
appendfilename "appendonly.aof"

4.2 同步机制

• appendfsync always：表示每次写入都执行fsync刷新函数，性能会非常慢，但是非常安全
• appendfsync everysec： 每秒执行一次fsync函数，可能丢失1s的数据
• appendfsync no：由操作系统保证数据同步到磁盘，速度最快，你的数据只需要交给操作系统就行

4.3 重写机制

由于AOF是追加的形式，所以文件就会越来越大，越大的话，数据加载越慢，所以我们需要对AOF文件进行重写

• 重写流程：

以redis7之前的版本为例

1. Redis fork一个子进程，在一个临时文件中写入新的数据
2. 如果在写入新的文件的过程中，主进程还会有指令进入，那么主进程会在内存缓存区中累计新的指令
3. 如果子进程重写完成，主进程会收到完成信号，并且将缓存中的指令追加到新的aof文件中
4. 替换旧的aof文件，并且将新的指令附加到重写好的aof文件中

• 什么时候重写？

  需要配置文件redis.conf

  # 配置达到百分比大小就触发重写
  auto-aof-rewrite-percentage 100
  # 配置达到文件大小就触发重写，就算达到第一个百分比大小，也必须大于64M才触发重写
  auto-aof-rewrite-min-size 64mb
  

举例，在aof文件达到64mb的时候就重写1次，重写后的aof文件大小假如为50mb，上面第一个配置auto-aof-rewrite-percentage为100，即aof文件到了100mb的时候，进行再次重写

4.4 AOF的优势和不足

• 优势

  1. 安全性高，就算是使用默认的持久化同步机制，也最多只会导致1s的数据丢失

  2. AOF文件相对安全，AOF文件由于某些原因，比如磁盘满了等导致追加失败，也可以通过redis-check-aof工具来修复

     [root@localhost src]$ ./redis-check-aof --fix append
     

  3. 数据格式都是追加的日志，所以可读性更高

• 不足

  1. 数据集一般比RDB大
  2. 持久化和加载都比RDB慢
  3. 在redis7.0版本之前，重写的时候，新的指令会缓存到内存区，所以会导致占用大量的内存
  4. 在重写期间，会跟磁盘进行两次IO，一个是写入旧的AOF文件，一个是写入新的AOF文件

混合模式

看了上面的介绍，我们知道RDB和AOF两种方式各有优缺点，RDB会有数据丢失的风险，但是备份和恢复的速度很快，AOF虽然可以保证数据的一致性，但是恢复数据时候会很慢。

所以从Redis4.0之后加了一种混合RDB和AOF的模式，这种模式，前部分是使用RDB格式 作为全量备份，后面部分使用AOF追加的写命令数据作为增量备份

混合模式开启，在redis.conf里修改配置

aof-use-rdb-preamble yes 

参考资料

• https://redis.io/docs/management/persistence/
• Redis进阶 - 持久化：RDB和AOF机制详解
• Redis两种持久化机制RDB和AOF详解