【Redis学习】Redis持久化
总体介绍
RDB（Redis DataBase）
简介
rdb是什么
在指定的时间间隔，执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
rdb能干嘛
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。
Redis的数据都在内存中,保存备份时它执行的是全量快照,也就是说，把内存中的所有数据都记录到磁盘中。
Rdb保存的是dump.rdb文件
案例演示
需求说明
配置文件（redis6 vs redis7）
redis6.0.16 之前
redis6.2 以及redis7.0之后
配置说明
- Redis7版本，按照redis.conf里配置的save ，设置为5秒2次修改
- 修改dump文件保存路径
- 修改dump文件名称
- 查看配置信息
自动触发
触发备份
第一种情况
第二种情况
如何恢复
将备份文件(dump.rdb)移动到redis配置中dump文件所在目录并启动服务即可。
备份成功后故意用flushdb清空redis，看看是否可以恢复数据——执行flushall/flushdb命令也会产生dump.rdb文件，但里面数据已被清空，无意义。
物理恢复，一定要服务和备份分机隔离。
手动触发
Redis提供了两个命令来生成RDB文件，分别是save和bgsave（默认）
SAVE
在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用。
BGSAVE
Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求,该触发方式会fork一个子进程由子进程复制持久化过程。
Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以继续进行。
LASTSAVE
可以通过lastsave命令获取最后一次成功执行快照的时间。
优缺点及数据丢失案例
优势
-
适合大规模的数据恢复
-
按照业务定时备份
-
对数据完整性和一致性要求不高
-
RDB 文件在内存中的加载速度要比 AOF快得多
劣势
-
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
-
内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
-
RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一倍，大致2倍的膨胀性，需要考虑。
案例
修复命令简介
调用/usr/local/bin中的redis-check-rdb 命令
redis-check-rdb /myredis/dumpfiles/dump6379.rdb
即可修复破损的rdb文件。
触发小结和快照禁用
触发RDB快照的情况
-
配置文件中默认的快照配置，手动save/bqsave命令
-
执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
-
执行shutdown且没有设置开启AOF持久化
-
主从复制时，主节点自动触发
如何禁用快照
-
动态停止所有RDB保存规则的方法:
redis-cli config set save "" -
快照禁用：在配置文件中打开禁用的配置，注释掉原本的配置
优化参数
-
save 设置自动保存策略
-
dbfilename 设置rdb文件名
-
dir 设置rdb文件保存路径
-
stop-writes-on-bgsave-error 在后台保存出错时主进程停止写入，默认yes；如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求
-
rdbcompression 压缩rdb文件，默认yes；对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
-
rdbchecksum 数据校验，默认yes；在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
-
rdb-del-sync-files 删除同步文件，默认no；在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的
小结
AOF（Append Only File）
简介
AOF是什么
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认情况下，redis是没有开启AOF(append only file)的。
开启AOF功能需要设置配置:appendonly yes
AOF能干嘛
Aof保存的是appendonlyfile.aof文件
工作流程和写回策略
持久化工作流程
缓冲区三种写回策略
always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec：默认策略，每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
三种策略小结
配置开启
如何开启aof
使用默认写回策略，每秒钟
aof文件-保存路径
redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
redis7：AOF文件会单独添加一层目录，默认名为"appendonlydir"
aof文件-保存名称
redis6：仅有一个文件：appendonly.aof
redis7（Multi Part AOF的设计）：，从1到3——base基本文件、incr增量文件、manifest清单文件。
小结
redis7中AOF的配置项：
#几种类型文件的前缀,后跟有关序列和类型的附加信息
appendfilename "appendonly.aof"
#新版本增加的目录配置项目
appenddirname "appendonlydir"
#如有下的aof文件存在
# 1.基本文件
appendonly.aof.1.base.rdb
# 2.增量文件
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
# 3.清单文件
appendonly.aof.manifest
正常恢复
启动：设置Yes 修改默认的appendonly no，改为yes
写操作继续，生成aof文件到指定的目录
恢复1:重启redis然后重新加载，结果OK
-
恢复2：
-
写入数据进redis，然后flushdb+shutdown服务器
-
新生成了dump和aof
-
备份新生成的aof.bak，然后删除dump/aof再看恢复
-
重启redis然后重新加载
-
停止服务器，拿出备份修改后再重新启动服务器，恢复成功
-
异常恢复
-
故意乱写正常的AOF文件
-
模拟网络闪断文件写error
-
重启 Redis 之后就会进行AOF 文件的载入，发现启动都不行
-
异常修复命令:redis-check-aof --fix进行修复
-
重新OK
优缺点案例总结
优势
更好的保护数据不丢失、性能高、可做紧急恢复
劣势
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
重写机制案例
是什么
由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
或者可以手动使用命令 bgrewriteaof 来重新。
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
触发机制
自动触发
满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的两倍且文件大于64M时。
手动触发
客户端向服务器发送bgrewriteaof命令。
案例说明
步骤
前期配置准备
-
开启aof
-
重写峰值修改为1k
- 关闭混合，设置为no
- 删除之前的全部aof和rdb,清除干扰项
自动触发案例
自动触发案例
完成上述正确配置，重启redis服务器，执行set k1 v1查看aof文件是否正常。
查看三大配置文件：base incr manifest
使k1不停1111111暴涨
重写触发
手动触发案例
客户端向服务器发送bgrewriteaof命令
结论
AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制：通过redis.conf配置文件中的auto-aof-rewrite-percentage:默认值为100，以及auto-aof-rewrite-min-size: 64mb配置，也就是说默认Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
重写原理
-
在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
-
与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
-
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
-
当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中。
-
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
总结
RDB+AOF混合持久化
官网建议
RDB vs AOF
数据恢复顺序和加载流程
如何选择
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。
同时开启
在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。
推荐方式
RDB+AOF混合方式
纯缓存模式
同时关闭RDB+AOF
在配置文件中设置
save ""
禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件
关闭RDB和AOF实际上只是关闭了自动触发机制，仍然可以执行手动触发。