RDB
触发机制
- 手动触发
save（阻塞主线程直至备份完成，不推荐）
bgsave（阻塞主线程，直至fork出一个进程，新线程进行备份） - 自动触发
1） 使用save相关配置， 如“save m n”。 表示m秒内数据集存在n次修改时， 自动触发bgsave。
2） 如果从节点执行全量复制操作， 主节点自动执行bgsave生成RDB文件并发送给从节点， 更多细节见6.3节介绍的复制原理。
3） 执行debug reload命令重新加载Redis时， 也会自动触发save操作。
4） 默认情况下执行shutdown命令时， 如果没有开启AOF持久化功能则自动执行bgsave。
bgsave流程
1） 执行bgsave命令， Redis父进程判断当前是否存在正在执行的子进程， 如RDB/AOF子进程， 如果存在bgsave命令直接返回。
2） 父进程执行fork操作创建子进程， fork操作过程中父进程会阻塞， 通过info stats命令查看latest_fork_usec选项， 可以获取最近一个fork操作的耗时， 单位为微秒。
3） 父进程fork完成后， bgsave命令返回“Background saving started”信息并不再阻塞父进程， 可以继续响应其他命令。
4） 子进程创建RDB文件， 根据父进程内存生成临时快照文件， 完成后对原有文件进行原子替换。 执行lastsave命令可以获取最后一次生成RDB的时间， 对应info统计的rdb_last_save_time选项。
5） 进程发送信号给父进程表示完成， 父进程更新统计信息， 具体见info Persistence下的rdb_*相关选项。
RDB文件的处理
运行期动态执行（get回去对应值）
config set dir {newDir} 保存路径
config set dbfilename {newFileName} 保存文件
config set rdbcompression {yes|no} 压缩
RDB的优缺点
- RDB的优点：
·RDB是一个紧凑压缩的二进制文件， 代表Redis在某个时间点上的数据快照。 非常适用于备份， 全量复制等场景。
比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs） ， 用于灾难恢复。
·Redis加载RDB恢复数据远远快于AOF的方式。 - RDB的缺点：
·RDB方式数据没办法做到实时持久化/秒级持久化。 因为bgsave每次运行都要执行fork操作创建子进程， 属于重量级操作， 频繁执行成本过高。
·RDB文件使用特定二进制格式保存， Redis版本演进过程中有多个格式的RDB版本， 存在老版本Redis服务无法兼容新版RDB格式的问题
AOF （append only file）
AOF流程
redis.conf中配置文件： appendonly no appendfilename “appendonly.aof”
- 所有的写入命令会追加到aof_buf(缓冲区)中，使用文本协议格式。
set hello word： *3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n -
AOF缓冲区根据对应的策略向硬盘做同步操作。
配置文件中 appendfsync 参数:
always 每次写入aof_buf后系统调用fsync（tps差）
everysec 每次写入aof_buf后系统调用write，fsync使用另外线程调用，如一秒一次(推荐)
no 每次写入aof_buf后系统调用write，由操作系统自己决定fsync(通常最长30s) -
随着AOF文件越来越大， 需要定期对AOF文件进行重写， 达到压缩的目的(删除无效命令，合并多条命令等)。
手动触发 bgrewriteaof
自动触发，参数控制：
auto-aof-rewrite-percentage 100 （当前AOF文件空间(aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值)
auto-aof-rewrite-min-size 64mb （运行AOF重写时文件最小体积）
自动触发时机 = aof_current_size > auto-aof-rewrite-minsize && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
3.1和3.2中fork出来新进程后或同时写在两个buf，一份会同步到旧文件，一份同步到新文件，最后新替换旧 -
当Redis服务器重启时， 可以加载AOF文件进行数据恢复。
