Redis持久化
一.引入
Redis是内存数据库，宕机后数据会消失，Redis重启后快速恢复数据，要提供持久化机制
Redis的两种持久化方式：RDB 和 AOF，默认使用的是 RDB
二.RDB (Redis DataBase)
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是 快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。 这个快照文件就称为 RDB文件(dump.rdb)(RDB文件是二进制文件，不易阅读，但存的更多)，等Redis恢复时再将 RDB 文件直接读回内存里，其中，RDB 就是 Redis DataBase的缩写。
1.自动触发
配置文件
以下是redis7的 conf 配置界面
配置的 save
同时也可在 conf 配置 dbfilename(RDB 文件名，集群模式建议配置) 以及 dir (RDB文件的输出位置)
2.手动触发
Redis提供了两个命今来生成RDB文件分别是 save 和 bgsave
①Save(会阻塞Redis服务器，线上禁用)
在主程序中执行会 阻塞 当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
②BGSAVE(默认)
Redis会在 后台异步 进行快照操作，不阻塞，快照同时还可以响应客户端请求,该触发方式会 fork一个子进程，由子进程复制持久化过程
补充：fork()是 unix 和 linux 这种操作系统的一个api，而不是Redis的api。fork()用于创建一个子进程，注意是子进程，不是子线程。fork()出来的进程共享其父类的内存数据。仅仅是共享fork()出子进程的那一刻的内存数据，后期主进程修改数据对子进程不可见，同理，子进程修改的数据对主进程也不可见。而且子进程B出问题了，对主进程A完全没影响，主进程A依然可以对外提供服务，但是主进程挂了，子进程也必须跟随一起挂。
可以通过 lastsave 命令获取最后一次成功执行快照的时间戳
③flushall/flushdb命令(一般禁用)
- flushdb：删除Redis中当前所在数据库中的所有记录，并且该命令是原子性的，不会终止执行，一旦执行，将不会执行失败。
- flushall：删除Redis中所有数据库中的所有记录，并且该命令是原子性的，不会终止执行，一旦执行，将不会执行失败。
执行flushall/flushdb命令也会产生 dump.rdb文件，但里面是空的，无意义
④执行shutdown目没有设置开启AOF持久化
Redis Shutdown 命令执行以下操作：
- 停止所有客户端
- 如果有至少一个保存点在等待，执行 SAVE 命令
- 如果 AOF 选项被打开，更新 AOF 文件
- 关闭 redis 服务器(server)
⑤主从复制时，主节点自动触发
3.检查修复dump.rdb文件
4.RDB优化配置项
stop-writes-on-gsave-error(建议用默认的保证一致性)
rdbcompression
rdbchecksum
个人感觉没必要为这10%省掉数据校验这比较重要的步骤
rdb-del-sync-files(集群的相关配置，建议默认)
5.RDB的优、劣势
优势
- RDB 非常适合 灾难恢复，在发生灾难时可以轻松恢复不同版本的数据集，非常适合备份。例如，你可能希望在最近的 24 小时内每小时归档一次 RDB 文件，并在30 天内每天保存一个RDB 快照。
- RDB 最大限度地提高了 Redis 的性能，因为 Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘 I/0 或类似操作。
- 与 AOF 相比，RDB 允许使用大数据集更快地重启
- 在副本上，RDB 支持 重启和故障转移后的部分重新同步
劣势
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会 丢失最新分钟的数据。假设你设置每五分钟创建一次 RDB 快照，如果 Redis 在没有正确关闭的情况下停止工作，最近一次快照到Redis宕机期间的数据会丢失
- 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
- RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟，fork的时候内存中的数据被克隆了1份，大致2倍的膨胀性，需要考虑
三.AOF(append only file)
以日志(易阅读)的形式来记录每个写操作，将Redis执行过的所有 写指令 记录下来(读操作不记录)，AOF保存的是 appendonly.aof 文件，并且只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置： appendonly yes
1.AOF的持久化工作流程
2.AOF缓冲区的三种写回策略
Always
同步写回，每个写命今执行完立刻同步地将日志写回磁盘
everysec(默认)
每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
no
操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
3.AOF文件
①保存路径
Redis7之前
AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的 dir 配置
Redis7
Redis7 里AOF保存文件的位置 由 dir + appenddirname 组成
②保存名称
Redis7之前
有且只有一个 appendonly.aof 文件
Redis7.0 Multi Part AOF的设计
MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件，并且统一存放在appenddirname指定的目录下
- BASE： 表示基础AOF，它一般由子进程通过重写产生，该文件最多只有一个
- INCR：表示增量AOF，它一般会在AOFRW开始执行时被创建，该文件可能存在多个
- manifest (清单) 文件：跟踪、管理上面些AOF文件
当key-value写入时，BASE文件和清单文件不会动，由 INCR文件记录
4.异常恢复
故意乱写正常的AOF文件模拟网络闪断文件写error，下面是在 增量文件INCR 乱插入一行
重启 Redis 之后就会进行 AOF 文件的载入，会发现启动都不行
修复命令
redis-check-aof --fix 文件路径5.AOF的优、劣势
优势
- 使用 AOF Redis 更加持久: 有不同的 fsync(写回) 策略: 根本不 fsync、每秒 fsync、每次查询时 fsync。使用每秒 fsync 的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程将努力执行写入，这样只丢失一秒钟的写入。
- AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因) 日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它
- 当AOF 变得太大时，Redis 能够在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
- AOF 以易于理解和解析的格式依次包含所有操作的日志。即便误用FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，仍然可以通过停止服务器、删除AOF文件里的最新命令并重新启动 Redis 来保存数据集.
劣势
- 相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
6.AOF的重写机制
由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF 的文件会越来越大文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动（通过子进程）AOF文件的内容压缩只保留 可以恢复数据的最小指令集可以手动使用命令 bgrewriteaof来重写
解释一下什么是 可以恢复数据的最小指令集
重写过程
①自动触发
满足配置文件中的选项后，Redis会记录上次重写时的AOF大小
默认配置是当AOF文件大小是上次rewrite后大小的一倍并且文件大于64M时
②手动触发
可以手动使用命令 bgrewriteaof来重写
四.RDB-AOF混合持久化(推荐)
因为Redis默认使用的是 RDB持久化机制 ，如果需要使用 RDB-AOF混合持久化机制的话还需要将AOF开启。
在RDB-AOF混合持久化模式下，RDB和AOF的触发机制是各自独立的。RDB持久化根据save配置项触发，而AOF持久化根据appendfsync选项触发。
aof-use-rdb-preamble yes # redis5.0后默认开启
数据恢复顺序和加载流程
因为AOF文件数据完整性更高，所以redis会优先读取AOF文件
RDB镜像做全量持久化，AOF做增量持久化
RDB可以用来做异地容灾，通常用来作为兜底的手段
RDB和AOF的对比
