读书笔记：Redis 持久化
Redis 持久化
Redis 是内存数据库，为了防止进程退出后数据丢失，Redis 提供的两种数据持久化方式RDB 方式和 AOF 方式，本文整理这两种方式的基本内容，最近阅读书籍是付磊、张益军编著的《Redis 开发和运维》，AOF（Append only file ） 流程图也来源于该书。
RDB 方式
1、 概念：将当前进程数据生成快照保存到硬盘的过程。
2、触发方式：
save 命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，该方法已经废弃。
bgsave 命令：Redis 进程执行 fork 操作创建子进程，由子进程完成。
手动触发会导致阻塞，所以对内存占据较大的实例会造成影响。
fork方式在fork一瞬间会造成阻塞。
3、自动触发的几种场景：
- 使用save相关配置
- 从节点全量复制操作会触发主节点向从节点发送RDB文件。
- debug reload命令会自动触发
- AOF 未开启，但是Redis执行shutdown操作时会触发
4、执行流程：
关注这里的 fork 操作之后，由于子进程只能共享主进程 fork 时的内存信息，所以生成的快照不包含（3）以后主进程此后响应的其他命令，所以不具备实时性。
5、优缺点：
优点：
1）紧凑的二进制文件，代表 Redis 在某个时间点上的数据快照，适合拷贝、全量复制等场景；
2）Redis 加载 RDB 恢复数据远远快于 AOF 方式；
3）默认采用 LZF 算法对生成的 RDB 文件进行压缩处理，压缩后的文件远远小于内存大小，默认开启了压缩。
缺点：
1）RDB 方式没法做到实时持久化、秒级持久化，因为它是全量快照、重量级操作；
2）RDB 使用的二进制格式，存在版本迁移问题，可能会出现新版本不兼容老版本；
3）由于子进程只能共享 fork 操作时的内存数据，bgsave 方式下主进程后续的响应命令无法实时体现在快照中。
AOF 方式
1、概念：以独立日志的方式记录每次写命令，重启时重新执行AOF中的命令达到数据恢复的目的。
2、特点：
- 直接采用文本协议格式，有较好的兼容性和可读性，方便修改和处理；
- 命令先追加到aof_buf中，再根据硬盘当前的负载执行同步硬盘的策略。
3、AOF 文件同步策略，控制参数为appendfsync：
- always：写入缓存后调用系统的fsync操作；
- ererysec：写入缓存后调用系统的write操作，wrtie完成后线程返回，由专门线程每秒调用一次fsync， 默认的同步策略；
- no：写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，由操作系统负责，通常同步周期为最长30秒。
知识点：系统的 write 和 fsync 操作，前者立即返回，会触发延迟写；后者针对单个文件强制硬盘同步，fsync 将阻塞直到写硬盘完成后返回，保证了数据的持久化。
4、AOF 重写机制：
目的：解决 AOF 文件逐渐臃肿而进行的。
概念：是将 Redis 进程内的数据转换为写命令同步到新的 AOF 文件。（相当于一次快照后的全新文件）此时的文件相比一致追加的旧文件来说容量相对小很多。
触发机制：
手动触发：bgrewriteaof
自动触发：auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定。
执行流程：
fork 之后子进程保证 AOF 文件实时性的巧妙设计流程为：
3.1 和 3.2 的 AOF 重写缓存部分，保证 fork 后主进程的写操作被同步到缓冲区，写入最终的 AOF 文件。这点与 RDB 的 bgsave 的处理不同，得到的收益也不同。
启示录
持久化中学到的几种巧妙设计：
1、RDB 的压缩处理。
2、为防止 AOF 文件过大而提出的 AOF 重写机制。
3、AOF 重写 流程中在 fork 操作之后的写命令缓存两份的处理过程，以防止数据丢失。
4、AOF 为平衡性能和安全性而使用的文件同步策略。