这是redis系列文章之《redis持久化【RDB+AOF】持久化双雄》，上一篇文章【redis基础】redis的十大数据类型_努力努力再努力mlx的博客-CSDN博客
感谢大家的支持~
目录
RDB
什么是RDB
RDB的作用
配置文件关于RDB部分 6vs7
操作步骤
修改配置文件（本案例设置5s修改2次）
修改dump文件的保存路径
修改dump文件名称
触发备份
自动触发
如何恢复
手动触发
优劣分析
修复RDB文件
触发快照的情况
禁用快照
优化配置
总结
AOF
什么是AOF
AOF的作用
AOF持久化工作流程
AOF缓冲区三种写回策略
redis6 vs redis7配置文件关于AOF的区别
AOF文件发挥作用
AOF文件损坏后的修复
AOF的优劣
AOF的重写机制
AOF优化配置
总结
RDB – AOF混合持久化
纯缓存模式
RDB
什么是RDB
RDB是在指定的时间间隔内，对执行数据集时间点进行快照。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。在这种情况下，即使redis发生宕机或者其他类型的故障问题，数据也会在快照文件中有所保存，数据的可靠性也有所保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
RDB的作用
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。其中redis的数据都是保存在内存中的，在保存备份时它执行的是全量快照，也就是说把内存中的所有数据都记录在磁盘中（一锅端）
配置文件关于RDB部分 6vs7
在redis6.0.16及以下和redis6.2、redis7.0.0的配置文件对生成快照文件的设置有所不同
redis6.0.16
redis6.2、redis7.0.0
操作步骤
修改配置文件（本案例设置5s修改2次）
修改dump文件的保存路径
修改dump文件名称
触发备份
自动触发
第一种情况：
第二种情况：因为我们设置的是5s内变化2次会生成dump文件，所以在这种情况下不会生成dump文件
如何恢复
直接将备份文件进行恢复即可
需要注意的是：当我们进行flushdb的操作后，同样会生成dump文件，但是这个dump文件中的内容是空的，也就是说，它保存了空的数据，对于redis数据恢复而言没有任何意义。
手动触发
save
- 在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令， 线上禁止使用
bgsave
- Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
- lastsave 命令可以获取最后一次成功执行快照的时间
优劣分析
优势：
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB 文件在内存中的加载速度比AOF快得多
劣势：
- 在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
- 内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
- RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑
修复RDB文件
触发快照的情况
- 配置文件中默认的快照配置
- 手动 save/bgsave 命令
- 执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
- 执行 shutdown 且没有设置开启 AOF 持久化
- 主从复制时，主节点自动触发
禁用快照
动态所有停止RDB保存规则的方法：redis-cli config set save “”
优化配置
总结
AOF
什么是AOF
- 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
- 默认情况下，redis是没有开启AOF的
- 开启AOF 功能需要设置配置 ： appendonly yes
AOF的作用
简单来说，AOF的作用是记录指令中的写操作，当redis重新启动时从生成的aof文件中赌球数据，进行数据的恢复
AOF持久化工作流程
AOF缓冲区三种写回策略
三种写回策略
- always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
- everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
- no 操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
redis6 vs redis7配置文件关于AOF的区别
aof文件-保存路径
- Redis 6 AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
- Redis 7 作了改变 dir/appendirname
d. aof文件-保存名称
- Redis 6 有且只有一个
- Redis 7 三个文件：base基本文件、incr增量文件、manifest清单文件（manifest文件会被默认清除）
AOF文件发挥作用
恢复1：
重启redis然后重新加载，结果OK
恢复2：
- 写入数据进redis，然后flushdb+shutdown服务器
- 新生成了dump和aof
- 备份新生成的aof.bak，然后删除dump/aof
- 再看恢复B重启redis然后重新加载
- 停止服务器，拿出我们的备份修改后再重新启动服务器。
AOF文件损坏后的修复
在网络闪断时，aof文件写了错误的指令，使用 异常修复命令 ： redis-check-aof –fix 进行修复
AOF的优劣
优势
- 更好的保护数据不丢失、性能高、可做紧急恢复
劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
AOF的重写机制
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
自动触发
满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
手动触发
客户端向服务器发送 bgrewriteaof 命令
结论：也就是说AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制:通过 redis.conf配置文件中的auto-aof-rewrite-percentage:默认值为100，以及auto-aof-rewritemin-size: 64mb配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
AOF重写原理
1.在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2.与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3.当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
4.当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
5.重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
AOF优化配置
总结
RDB – AOF混合持久化
同时开启两种持久化方式
当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那要不要只使用AOF呢
安特雷兹建议不要
因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段
1 开启混合方式设置
设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用
2 RDB+AOF的混合方式———> 结论：RDB镜像做全量持久化，AOF做增量持久化
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。—-》AOF包括了RDB头部+AOF混写
纯缓存模式
同时关闭RDB + AOF
save “”
禁用rdb
禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
禁用aof
禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
