文章目录
前言
持久化有两种方式，RDB（Redis Data Base）和AOF（Append Only File）
RDB是快照模式
AOF是复制写操作
当redis宕机时，可以通过这两种模式进行数据恢复。
一、RDB（Redis Data Base）
RDB 持久性以指定的时间间隔执行数据集的时间点快照。
- 在指定的时间间隔，执行数据集的时间点快照
- 实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。
- 这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
- 这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
- 将内存数据全部保存到磁盘dump.rdb文件种
1.1 设置自动备份
redis 7 按照 redis.conf 里配置的 save
save 3600 1 300 100 60 10000 // 3600秒 修改一次 300秒 修改100次 60秒 修改10000次
// 以上条件会触发保存
修改dump文件保存地址，默认在配置文件
修改dump文件名称，加上端口号，清楚这个dump文件是redis形成的
1.2 恢复数据
将备份文件(dump.rdb)移动到redis安装目录并启动服务即可自动恢复成功。
物理恢复，一定服务和备份分机隔离。
因为在shutdown命令时，会产生与关闭redis时数据一致的dump.db文件；
而flushall/flushdb命令时，会产生dump.rdb文件，但里面是空的没有意义。
所以在运行这两个命令前，需要把备份过的文件进行转移隔离。
1.3 手动备份
Redis提供了两个命令来生成RDB文件,分别是save和bgsave
- Save
- 在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令，
- 线上禁止使用
- BGSAVE（默认）
- Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
- lastsave 命令可以获取最后一次成功执行快照的时间
1.4 RDB优缺点
优势
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB 文件在内存中的加载速度比AOF快得多
劣势
- 在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
- 内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
- RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑
哪些情况会触发RDB快照
- 配置文件中默认的快照配置
- 手动 save/bgsave 命令
- 执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
- 执行 shutdown 且没有设置开启 AOF 持久化
- 主从复制时，主节点自动触发
1.5 如何禁用快照
- 动态所有停止 RDB 保存规则的方法:执行命令： redis-cli config set save “”
- 修改配置，将框选部分进行去掉注释
二、 AOF（Append Only File）
以
日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，
换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF的
开启AOF 功能需要设置配置 ： appendonly yes
AOF保存的是appendonly.aof文件
优势
- 更好的保护数据不丢失、性能高、可做紧急恢复(即对aof文件进行修改)
劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
2.1 AOF 持久化工作流程及写回策略
AOF 缓冲区三种写回策略
- always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
- everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
- no 操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
配置文件种默认的是everysec
2.2 AOF配置
开启appendonly为yes
保存路径
比如，我的配置路径就是保存在了/myredis/appendonlydir中
AOF文件
在7版本后被拆分为3种文件
- BASE：表示基础AOF,它一般由子进程通过重写产生，该文件最多只有一个。
- lNCR：表示增量AOF，它一般会在AOFRW开始执行时被创建，该文件可能存在多个。
- HISTORY:表示历史AOF，它由BASE和INCR AOF变化而来，每次AOF RW成功完成时，本次AOF RW之前对应的BASE和INCR AOF都将变为HISTORY，HISTORY类型的AOF会被Redis自动删除。
- 为了管理这些AOF文件，我们引入了一个
manifest(清单）文件来跟踪、管理这些AOF。
2.3 恢复数据
正常恢复
和RDB类似，在启动redis时，读取对应的aof文件进行写操作恢复。
异常恢复
在网络闪断时，aof文件写了错误的指令，使用异常修复命令 ： redis-check-aof --fix 文件路径
修完后，进行正常恢复。
2.4 AOF重写机制
对AOF进行压缩，只保留可以恢复数据的最小指令集
说AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
开启自动重写
- 满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
- 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时，会触发重写机制，对aof文件进行压缩
手动触发
客户端向服务器发送 bgrewriteaof 命令
现象： 也就是一旦重写就会生成新的base、incr文件，去替换之前的
重写原理
1:在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2∶与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3:当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4:当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5:重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
2.5 RDB - AOF混合持久化
同时开启两种持久化方式
- 当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段
三、 纯缓存模式
在高并发高性能的要求时。
同时关闭RDB + AOF
- 配置文件 save “” 或命令 CONFIG SET save “”
- 禁用rdb
- 禁用db持久化模式下，我们仍然可以使用命令
save、bgsave生成rdb文件
- 配置文件 appendonly no
- 禁用aof
- 禁用aof持久化模式下，我们仍然可以使用命令
bgrewriteaof生成aof文件
