持久化

Redis持久化提供：RDB、AOF两种方式

• 官网：https://redis.io/docs/management/persistence/

RDB持久化

RDB 持久性以指定的时间间隔执行数据集的时间点快照

• 是什么？

  实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
  这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。

• 能干嘛？

  在指定的时间间隔内将内存中的数据集快照写入磁盘也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里
  Redis的数据都在内存中，保存备份时它执行的是全量快照也就是说，把内存中的所有数据都记录到磁盘中，一锅端
  Rdb保存的是dump.rdb文件

• 配置文件

  • Redis6.0.16及以下

    
    

  • Redis6.0.16以上

    

  • 自动触发

    通过修改配置文件：5秒内修改两次即触发

    

    修改保存路径

    
    

    修改保存文件名称

    

    测试：在redis里面命令config get dir即可查看

    

    如何通过dump.rdb文件恢复数据

    • 将备份文件 (dump.rdb)移动到 redis 安装目录并启动服务即可

      

    • 注意

      不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。

  • 手动触发

    Redis提供了两个命令来生成RDB文件分别是save和bgsave(不阻塞，后端执行)

    • Save

      在主程序中执行会阻塞当前redis服务器，直到持久化工作完成；线上禁止使用执行save命令期间，Redis不能处理其他命令

      案例

      
      

    • BGSAVE(默认)

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

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

      fork是什么?

      案例

      
      

    • LASTSAVE

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

      案例

      
      

• 优势

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

• 劣势

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

  数据丢失案例

  

• 修复dump.rdb文件

  

• 哪些情况会触发RDB快照

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

• 禁用RDB快照

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

  • 快照禁用

    

• RDB配置优化

  • save <seconds> <changes>

  • dbfilename

  • dir

  • stop-writes-on-bgsave-error

    默认yes。如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求

  • rdbcompression

    默认yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
    如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

  • rdbchecksum

    默认yes。在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

  • rdb-del-sync-files

    默认情况下no，此选项是禁用的。rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用

AOF持久化

• 是什么

  以日志的形式来记录每个写操作，将Redis执行过的所有**写指令记录下来(读操作不记录)**只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。

  换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

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

• 能干嘛？

  Aof保存的是appendonly.aof文件

• AOF工作流程

  

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

• 写回策略

  • Always

    同步写回，每个写命令执行完立刻同步地将日志写回磁盘

  • everysec(默认的)

    每秒写回，每个写命令执行完。只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘

  • no

    操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

    

• 配置文件说明(6 VS 7)

  • 开启aof

    

  • 使用默认写回策略

    

  • aof文件-保存路径

    • Redis6

      AOF保存文件的位置和RDB保存文件的位置一样都是通过redis.conf配置文件的 dir配置

      

    • Redis7

      新添了 appenddirname "appendonlydir"

      

  • aof文件-保存名称

    • Redis6

      appendfilename 有且仅有一个

      

    • Redis7

      Redis7.0 Multi Part AOF的设计

      • base基本文件
      • incr增量文件
      • manifest清单文件

      
      

      配置文件表现上

      

• 演示(写入aof、恢复、异常处理)

  写入aof文件

  

  数据恢复

  

  异常情况恢复

  • appendonly.aof.1.incr.aof文件内容异常
  • redis-check-aof --fix进行修复

  

  ---

  

• 优势

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

  

• 劣势

  相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

  

• AOF重写机制

  由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

  为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令bgrewriteaof来重写。

  • 官网默认配置(自动执行)

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

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

    

  • 命令bgrewriteaof(手动)

    

  • 重写原理

    1. 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

    2. 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

    3. 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

    4. 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

    5. 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

• AOF配置优化

  

RDB-AOF混合持久化

官网建议使用RDB+AOF混合使用；共存的时候，AOF初始化被优先加载

• 加载流程

  

• RDB与AOF的比较

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

• 共存时，RDB与AOF

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

  • RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?

    作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段.

• 开启混合方式设置

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

  • RDB镜像做全量持久化，AOF做增量持久化
  • 先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写