RDB
把当前进程数据生成快照保存在硬盘
触发时机
- 手动执行
dgsave。 - 使用save 相关配置 ，
save m n。表示m秒内数据集存在n次修改时，自动触发bgsave。 - 从节点执行全量复制，主节点自动执行
bgsave生成RDB文件并发送给从节点。 - 执行
debug reload重新加载redis时。 - 在没有开启AOF的情况下执行
shutdown。 - 执行
flushall，在这种情况下，会删除所有数据，即RDB文件也会是空的。谨慎操作
生成流程
- 父进程执行bgsave，会fork子进程，由子进程生成RDB文件。
- fork 子进程过程中会阻塞，fork完成后，父子进程并行，父进程可以处理其他操作。
- 子进程根据父进程内存生成临时快照文件，完成后对原文件进行原子替换。
- 子进程发送信号给父进程表示完成，父进程更新统计信息
在生成RDB文件过程中产生的数据无法备份。
RDB生成流程
文件处理
保存： 保存在dir/dbfilename 下 。 dir、dbfilename为配置项。
压缩： dbcompression yes 默认开启，采用LZF算法进行压缩。
校验： 加载RDB文件时，可能存在文件的损坏。 采用 redis-check-dump 工具进行检测。
AOF
- 持久化每次的写命令，重启时再执行AOF中命令进行数据恢复。主要的解决数据持久化的实时性。
- 开启AOF设置参数
appendonly yes，默认不开启。 - 文件名设置参数
appendfilename指定，默认为 appendonly.aof。
处理流程
- 写命令执行，会追加到缓存（命令写入）
- AOF缓存区根据对应的策略向硬盘做同步操作（文件同步）
- AOF文件过大，需要定期重写AOF文件（文件重写）
- 重启服务加载AOF（AOF加载）
文件同步
同步策略
使用 appendfsync 参数控制，默认为 appendfsync everysec
| 可配置项 | 说明 |
|---|---|
| always | 命令写入缓存后，调用系统fsync同步数据到硬盘AOF文件中，然后线程返回 |
| everysec | 1. 命令写入缓存后，调用系统write操作，然后线程返回。 2. fsync同步文件操作由专门线程每秒调用一次。 3. fsync同步可能失败或同步时间超过1秒，若主线程判断距上一次同步成功超过2秒，则会阻塞主线程，直到同步操作完成。 保证了最多可能丢失2秒数据。 |
| no | 命令写入缓存后，调用系统write操作，然后线程返回。 fsync同步文件操作由操作系统负责何时执行，通常同步周期最长30秒 |
文件同步
重写机制
重写是通过丢弃进程中超时的数据、去除旧AOF文件中无效的命令以及将多条写命令合并为一个的操作。
触发时机
手动触发： 直接调用 bgrewriteaof 命令
自动触发： 根据auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定触发时机。
auto-aof-rewrite-percentage ，当前的aof文件的大小超过上一次文件大小的百分比时，会触发重写。
auto-aof-rewrite-min-size ，限制了允许重写的最小文件大小，当aof文件达到这个值时，触发重写。
《redis开发与运维》P159看具体公式
重写流程
- 若当前已经存在AOF重写了，流程返回。 若当前正在执行
bgsave,重写命令等待bgsave完成后继续执行。步骤1） - fork 子进程，fork完成后父进程继续工作。步骤 2）、3.1）
- 由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。aof_rewrite_buf 保存的是fork之后父进程新写入的数据。步骤3.2）
- 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。批量写入磁盘由
aof-rewrite-incremental-fsync yes控制默认32MB。步骤4） - 父进程把 ***aof_rewrite_buf *** 中的数据追加到新的AOF文件。 步骤5.2）
- 使用新的AOF文件的替换旧的文件，完成AOF重写。步骤5.3）
重写流程
重启加载
- 若开启了AOF持久化的，优先加载AOF文件。
- 若加载过程中发现AOF文件损坏，可尝试采用
redis-check-aof --fix命令进行修复，修复前先备份AOF文件。
重启加载
混合模式
- redis4.0开始支持
- 开启方式：
aof-use-rdb-preamble true - 开启之后，AOF重写会把内存中数据以RDB方式写到AOF中，再将重写缓存区的数据追加到AOF中，最后将含有RDB格式和AOF格式的AOF文件覆盖旧的AOF文件。
- 重启加载时，也是优先加载AOF
总结
| 持久化模式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| RDB | 1. 重启加载速度比AOF快 2. 文件体积比整个实例内存小，在传输速度上快，适合做容灾恢复的备份 |
1. 没法做到实时持久化、不能保证数据完整性 2. 可阅读性差 3. 由于采用特定的二进制格式保存，多个版本之间可能存在兼容性的问题 |
1. 主从全量数据同步 2. 数据库备份 3. 对于丢失数据不敏感的业务场景，实例宕机后快速恢复 |
| AOF | 1. 能保证数据实时持久化，秒级丢失 2. 兼容性好，基于redis通讯协议（RDSP）的写命令追加 3. 可阅读性好 |
1. 数据文件体积大，即便有重写机制，但在相同数据集下,AOF还是比RDB文件大 2. 恢复速度比RDB慢 |
|
| 混合模式 | 既能快速备份又能避免大量数据丢失 | 1. RDB是压缩格式，AOF文件可读性差。 2. 不兼容4.0以下的版本 |
