Redis持久化小结
RDB
RDB持久化方式是通过快照(snapshotting)完成的，当符合一定条件时，Redis将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。
触发机制
- save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用
- bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
- 使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave
- 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
- 执行debug reload命令重新加载Redis时，也会自动触发save操作。
- 默认情况下执行shutdown和flushall命令时，如果没有开启AOF持久化功能则自动执行bgsave
bgsave运作流程
- 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回
- 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒.Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
- 父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令
- 子进程创建RDB文件（Rdb 保存的是dump.rdb文件），根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项
- 进程发送信号给父进程表示完成，父进程更新统计信息
恢复数据
将rdb文件 移动到 redis 数据目录并启动服务即可，redis就会自动加载文件数据至内存了。
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内 存中需要花费20～30秒钟。 通过RDB方式实现持久化，一旦
Redis异常退出，就会丢失最后一次快照以后更改的所有数据。
优势
RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复（对数据完整性和一致性要求不高）
Redis加载RDB恢复数据远远快于AOF的方式(适合大规模的数据恢复)
劣势
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)
停止RDB保存
redis-cli> config set save ""
配置解读
-
“save 900 1” 表示如果900秒内至少1个key发生变化（新增、修改和删除），则重写rdb文件；
-
“save 300 10” 表示如果每300秒内至少10个key发生变化（新增、修改和删除），则重写rdb文件；
-
“save 60 10000” 表示如果每60秒内至少10000个key发生变化（新增、修改和删除），则重写rdb文件。
AOF
AOF（append only file）以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。通俗一点的理解就是以日志的形式来记录每个写操作，将Redis执行过的所有写指令以只追加文件形式记录下来，redis启动之初会读取该文件重新构建数据。
如何开启
设置配置：appendonly yes，默认不开启。
AOF文件名配置：appendfilename，默认文件名是appendonly.aof
3种刷写模式
- appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
- appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
- appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
AOF的工作流程
- 所有的写入命令会追加到aof_buf缓冲区中;
- aof_buf缓冲区根据对应的策略向硬盘做同步操作;
- 随着AOF文件越来越大需要定期对AOF文件进行重写，达到压缩的目的;
- 当Redis服务器重启时，可以加载AOF文件进行数据恢复。
关闭AOF
redis-cli> config set appendfsync no
重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。通俗的理解就是AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。
原理 : AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
AOF重写过程可以手动触发和自动触发：
- 手动触发：直接调用bgrewriteaof命令。
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
恢复数据
数据文件损坏的时候如何修复
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动。
参考资料
https://blog.csdn.net/weixin_39040059/article/details/79120416
https://blog.csdn.net/weixin_39040059/article/details/79120444
https://blog.csdn.net/johnstrive/article/details/78423595
https://blog.csdn.net/qq_34190023/article/details/82715705
