1.文档

官网 https://redis.io/docs/manual/persistence/ (opens new window)

中文官网：Redis持久化 (opens new window)

2.Redis持久化方案（RDB和AOF）

2.1 RDB（Redis DataBase）

• RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。
• 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里
• Rdb保存的是dump.rdb文件

2.1.1 使用说明

查找配置文件中SNAPSHOTTING的配置

• 自动触发配置

  • 修改配置文件

  # 触发规则，5s内有两次变动
  save 5 2
  
  # 默认保存文件的名称
  dbfilename dump.rdb
  
  # 配置dump文件的保存位置。默认 ./
  dir ./back
  

  • 重启服务

  127.0.0.1:6379> CONFIG get dir
  1) "dir"
  2) "/home/app/redis/redis-7.0.0/back"
  127.0.0.1:6379> CONFIG get save
  1) "save"
  2) "5 2"
  

  • 触发

    再5s内设置两个值

  • 恢复

    1. 备份dump.rdb
    2. 清空数据库
    3. 停止redis服务
    4. 用备份的dump文件替换redis服务的dump
    5. 启动服务，数据恢复

  • 手动触发

    • Redis提供了两个命令来⽣成RDB⽂件，分别是save和bgsave

    • save: 在主程序中执⾏会阻塞 ,当前redis服务器，直到持久化工作完成

    • 使用save

      set k1 v1
      save
      

    • c(默认)

    • Redis会在后台异步进行快照操作，不阻塞,快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。

    • Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

    • 使用

      set k1 k2
      save
      

    • 可以通过lastsave命令获取最后一次成功执行快照的时间

  • 优势

    • 适合大规模的数据恢复
    • 按照业务定时备份
    • 对数据完整性和一致性要求不高
    • RDB 文件在内存中的加载速度要比 AOF 快得多

  • 劣势

    • 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，
    • 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
    • RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑
    • 数据丢失案列
      • 正常录入数据
      • kill -9故意模拟意外down机
      • redis重启恢复，查看数据是否丢失

  • 如何检查修复dump.rdb文件

    redis-check-rdb ./back/dump.rdb
    

  • 哪些情况会触发RDB快照

    • 配置文件中默认的快照配置
    • 手动save/bgsave命令
    • 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
    • 执行shutdown且没有设置开启AOF持久化
    • 主从复制时，主节点自动触发

  • 如何禁用快照

  • RDB优化配置项详解

    • 动态所有停止RDB保存规则的方法：redis-cli config set save ""

    • 快照禁用

      save ""
      

  • RDB优化配置项详解

    • 配置文件SNAPSHOTTING模块

    • save <seconds> <changes>

    • dbfilename

    • dir

    • stop-writes-on-bgsave-error

      默认 yes 如果配置成no，表示你不在乎数据不一致或其它方式发现数据不一致，在快照写入失败时，也能确保redis继续接受新的写请求

    • rdbcompression

      默认yes，设置进行压缩存储。

    • rdbchecksum

      默认yes，存储快照后，利用算法对数据进行校验。

    • rdb-del-sync-files

      默认no 在没有持久性的情况下，删除复制中的rdb文件。

2.2 AOF（Append Only File）

2.2.1 是什么

以日志的形式来记录每个写操作 将redis执行过的所有写指令记录下来，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置：appendonly yes

2.2.2 文件

Aof保存的是appendonly.aof文件

2.2.3 AOF持久化工作流程

1. Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2. 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3. AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4. 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5. 当Redis Server 服务器重启的时候会从AOF文件载入数据。

2.2.4 AOF缓冲区三种写回策略

三种写回策略

1. Always: 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
2. everysec: 每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
3. no :操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

2.2.5 AOF的开启

开启配置

# 默认 no
appendonly yes

默认写回策略

# appendfsync always
appendfsync everysec
# appendfsync no

aof的保存路径 redis7

dir+appenddirname

# rdb的路径
dir ./back
# For convenience, Redis stores all persistent append-only files in a dedicated
# directory. The name of the directory is determined by the appenddirname
# configuration parameter.

appenddirname "appendonlydir"
# aof文件的最终路径 ./back/appendonlydir

配置文件名称redis7

# base基本文件 
# - appendonly.aof.1.base.rdb as a base file.
# incr增量文件
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
# manifest清单文件
# - appendonly.aof.manifest as a manifest file.

appendfilename "appendonly.aof"

重启redis,

查看保存的aop文件

2.2.5 数据恢复

正常恢复

• 启动：设置Yes，修改默认的appendonly no，改为yes
• 写操作继续，生成aof文件到指定的目录
• 恢复1
  • 恢复1：重启redis然后重新加载，结果OK
• 恢复2
  • 写入数据进redis，然后flushdb+shutdown服务器
  • 新生成了dump和aof
  • 备份新生成的aof.bak，然后删除dump/aof再看恢复
  • 重启redis然后重新加载试试？？？
  • 停止服务器，拿出我们的备份修改后再重新启动服务器看看

异常恢复

• 故意乱写正常的AOF文件，模拟网络闪断文件写error

  vim /myredis/appendonlydir/appendonly.aof.1.incr.aof
  

• 重启 Redis 之后就会进行 AOF 文件的载入，发现启动都不行，o(╥﹏╥)o

• 异常修复命令：redis-check-aof --fix 进行修复

• 重新OK

2.2.6 优势

更好的保护数据不丢失 、性能高、可做紧急恢复

2.2.7 劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb，

aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

2.2.8⭐AOF重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，

文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，

只保留可以恢复数据的最小指令集

或者

可以手动使用命令 bgrewriteaof 来重新。

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

触发机制

官网默认配置：

#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

注意 ，同时满足，且的关系才会触发

1. 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2. 重写时满足的文件大小

• 自动触发
  • 满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
• 手动触发
  • 客户端向服务器发送bgrewriteaof命令

2.2.8 总结

2.3RDB+AOF混合方式

数据恢复和加载流程

如何让选择

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

同时开启两种持久化方式

在这种情况下,**当redis重启的时候会优先载入AOF文件来恢复原始的数据,**因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

推荐方式

RDB+AOF混合方式

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

1. 开启混合方式设置

设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

2. RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

   先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。

简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

2.4 纯缓存模式

同时关闭RDB+AOF，

• save ""
  • 禁用rdb
  • 禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
• appendonly no
  • 禁用aof
  • 禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件