一、RDB持久化
RDB持久化是把当前进程的数据已快照的形式保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发
手动触发命令：save和bgsave。
- save：阻塞式，内存较大的实例在执行过程中会造成长时间的阻塞，影响主进程上的正常服务请求。
-
bgsave：fork子进程，RDB持久化的过程在子进程中进行，完成后自动结束进程。阻塞发生在fork阶段，时间 较短
自动触发：满足RDB持久化条件后会自动执行持久化过程。
触发条件：
- 使用save相关配置
配置格式：save <seconds> <changes> 表示<seconds>秒内数据集存在<changes>次修改时，自动触发bgsave。
默认配置：
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes fork子进程内存不足或rdb文件所在的文件夹没有写入权限
rdbcompression yes
dbfilename dump.rdb
rdbchecksum yes
dir ./
实现原理：
serverCron服务定时器每100ms执行一次检查
if(now()-rdb_last_save_time < m(指定秒数) and rdb_changes_since_last_save>n(修改次数)){
bgsave();
}
- 从节点执行全量复制操作
- debug reload命令
- shutdown命令，如果没有开启aof自动执行bgsave
RDB持久化步骤：
- 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回
- 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
- 父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
- 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
- 进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。
小提示：
config set save "20 2" 动态修改rdb持久化条件
rdbconfig set dbfilename 和config set dir可以修改rdb文件的目录
config set rdbcompression 【yes|no】 指定是否压缩
RDB文件格式：
----------------------------#
52 45 44 49 53 # 魔数"REDIS"
30 30 30 37 # RDB数据库版本号，3.0服务器数据库为6，3.2服务器数据库为7. "0007" = 7
----------------------------
FA # 辅助信息
$string-encoded-key # 包括Redis服务器版本，系统32或64位，创建时间，可用内存
$string-encoded-value #
- 09 Redis服务器版本 ：redis-ver 3.2.100
- 0A Redis系统位数（32位或64位） ：redis-bits
- 05 系统时间：ctime
- 08 可用内存：used-mem
----------------------------
FE 00 # 数据库编号默认16个库. db number = 00
FB # 数据库键值对总数量
$length-encoded-int # 键值对总数
$length-encoded-int # 过期键值对总数
----------------------------# Key-Value pair starts
FD $unsigned-int # 过期时间单位秒, 四个字节长的无符号int表示
$value-type # 1个字节，表示编码方式
$string-encoded-key # key值，字符串类型
$encoded-value # value值,编码方式
----------------------------
FC $unsigned long # 过期时间单位毫秒, 八个字节长的无符号int表示
$value-type # 1个字节，表示编码方式
$string-encoded-key # key值，字符串类型
$encoded-value # value值,编码方式
---------------------------- # 无过期时间的键值对
$value-type # 1个字节，表示编码方式
$string-encoded-key # key值，字符串类型
$encoded-value # value值,编码方式
----------------------------
FE $length-encoding # 当前数据库结束，下一个数据库开始（多个数据库场景）.
----------------------------
FF ## RDB文件结束
8-byte-checksum ## 环冗余校验码，Redis采用crc-64-jones算法，初始值为0.
编码方式对照表:
| CODE | 对照 |
|---|---|
| 0 | "String Encoding" |
| 1 | "List Encoding" |
| 2 | "Set Encoding" |
| 3 | "Sorted Set Encoding" |
| 4 | "Hash Encoding" |
| 9 | "Zipmap Encoding" |
| 10 | "Ziplist Encoding" |
| 11 | "Intset Encoding" |
| 12 | "Sorted Set in Ziplist Encoding" |
| 13 | "Hashmap in Ziplist Encoding" (Introduced in rdb version 4) |
| 14 | "Quicklist" |
文件校验：
对于错误格式的RDB文件，用redis-check-rdb工具进行修复
二、AOF
开启AOF功能需要设置配置：appendonly yes，默认不开启。
AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。
保存路径同RDB持久化方式一致，通过dir配置指定。
AOF工作流程：
1）、所有的写入命令会追加到aof_buf（缓冲区）中。
2）、AOF缓冲区根据对应的策略向硬盘做同步操作。
3）、随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）、当Redis服务器重启时，可以加载AOF文件进行数据恢复。
AOF文件采用文本协议格式的好处：
- 文本协议具有很好的兼容性。
- 文本协议具有可读性，方便直接修改和处理。
- 开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
AOF重写机制：
2.1、重写后的AOF文件缩小文件体积有如下原因：
- 进程内已经唾弃的数据不再写入文件
- 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a 111、set a222等。重写使用 进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
- 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。
2.2、重写触发机制：
a）、手动触发，直接调用bgrewriteaof命令。
b）、自动触发，根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
·auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件
空间（aof_base_size）的比值。
自动触发时机:
aof_current_size>auto-aof-rewrite-minsize&&(aof_current_size- aof_base_size)/aof_base_size>=auto-aof-rewritepercentage
2.3、重写工作流程
- 执行AOF重写请求。如果当前进程正在执行AOF重写则不执行重写操作，如果进程在执行bgsave则等待执行完毕后再执行。
- 父进程执行fork创建子进程，开销等同于bgsave过程。
3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，
Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-
rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3）使用新AOF文件替换老文件，完成AOF重写。
AOF加载流程：
AOF加载流程
文件校验：
AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动。
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof --fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
