RDB
概念：把当前进程数据生成快照保存在RDB文件的过程
分为手动触发和自动触发。
RDB持久化生成的RDB文件是一个经过压缩的二进制文件。
手动触发
命令：
SAVE：会阻塞Redis服务器进程，直到RDB文件创建完毕，在服务器进程阻塞期间，不能处理任何命令。
BGSAVE：fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段。
BGSAVE运作流程：
执行BGSAVE命令，Redis父进程判断当前是否有正在执行的子进程，如RDB/AOF子进程，如果存在直接返回。
父进程执行fork操作创建子进程，fork操作会阻塞父进程。父进程fork操作执行完成后，便不再阻塞父进程，可以继续响应其他命令。
子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。
子进程发送信号给父进程表示完成，父进程更新统计信息。
自动触发
通过SAVE选项设置多个保存条件，让服务器每隔一段时间自动执行一个BGSAVE命令，只要有一个条件被满足，服务器就会执行BGSAVE命令
--保存条件
默认条件：
SAVE 900 1 // 服务器在900秒之内，对数据库进行了至少1次修改。
SAVE 300 10 // 服务器在300秒之内，对数据库进行了至少10次修改。
--服务器状态redisServer结构
dirty计数器：记录距离上一次成功执行SAVE或BGSAVE命令之后，服务器对数据库状态进行了多少次修改（包括写入、删除和更新等操作）
lastsave：是一个UNIX时间戳，记录了服务器上一次成功执行SAVE或BGSAVE命令的时间。
struct redisServer{
// 记录保存条件的数组
struct saveparam *saveparams;
// 修改计数器
long long dirty;
//上一次执行的保存时间
time_t lastsave;
//…
}
struct saveparam{
//秒数
time_t seconds;
// 修改数
int changes;
}
检查保存条件是否满足：
Redis服务器周期性操作函数saverCron默认每隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，其中一个工作就是检查SAVE条件是否满足，如果满足则调用BGSAVE命令
saverCron函数检查保存条件的过程：
(1) 遍历所有的保存条件。
(2) 计算距离上次执行保存操作有多少秒.。
(3) 如果数据库状态的修改次数超过条件所设置的次数并且距离上次保存的时间超过了条件所设置的时间，就会执行保存操作。
当且仅当AOF持久化关闭的状态，服务器使用RDB文件来还原数据库状态。
服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。
优缺点
优点：紧凑的二进制文件，适用于备份、全量复制的场景。加载RDB文件恢复数据远远快于AOP文件
缺点：不能实时持久化，数据丢失的风险高。每次BGSAVE创建子进程属于重量级操作，频繁执行成本高。
AOF
Append Only File
概念：以独立日志方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的
主要作用是解决数据持久化的实时性。
被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis命令请求协议格式是纯文本格式，可直接打开。
--使用AOF
默认情况下AOF功能是关闭的。配置文件appendonly no改为appendonly yes。
--工作流程
命令追加（append）、文件同步（sync）、文件重写（rewrite）、重启加载。
1 命令追加：服务器执行完一个写命令后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区末尾。
2 文件同步：AOF缓冲区根据对应的策略向硬盘做同步操作。
3 文件重写：随着AOF越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4 重启加载：当Redis重启时，可以加载AOF文件进行数据恢复。
- AOF缓冲区同步文件策略
-
appendfsync_always：命令写入aof_buf后调用系统的fsync操作同步到AOF文件中，fsync完成后线程返回。
配置always时，每次写入都要同步AOF文件，从效率上看，是最慢的，从安全性上看，是最安全的。 -
appendfsync_everysec：命令写入aof_buf中调用系统的write操作，writer完成后线程返回。fsync同步文件操作由专门下线程每秒调用一次。
配置为everysec时，服务器每次写入aof_buf缓冲区的所有内容都写入AOF文件中，并且每隔1秒就在子线程中对AOF文件进行同步。从效率上看，everysec模式足够快，并且就算出现故障停机，数据库也只会丢失1秒的数据。该模式也是默认的同步策略。 -
appendfsync_no：命令写入aof_buf后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘由操作系统负责。
配置为no时，服务器每次写入缓冲区的所有内容都写入AOF文件，但是何时同步由操作系统控制，该模式的写入速度最快，但是安全性无法保证。
- OF文件的载入与数据还原
-
重写机制
由于AOF是通过命令追加的方式写入AOF文件中，这会导致AOF文件越来越大。如果不加以控制，体积过大的AOF文件很可能对Redis服务器，甚至整个宿主计算机造成影响。并且AOF文件越来越大，使用AOF文件进行数据还原需要的时间就越多。
目的：解决AOF文件越来越大的问题。Redis通过重写功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同。但是新的AOF文件体积更小。
--重写的AOF文件体积变小的原因：
1 过期的数据不再写入文件
2 无效的命令不再执行
3 多条写命令合并为一个（64个元素为佳）
--重写流程
1 父进程执行fork操作创建子进程。
2 主线程fork操作完成后，可以继续响应其他命令，所有修改依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性.
3 由于fork操作运用写时复制（copy-on-write）技术，子进程只能共享fork操作时内存数据，可以在避免使用锁的情况下，保证数据的安全性。
4 由于父进程依然在响应命令，为了防止在重写过程中数据的丢失，Redis使用了**AOF重写缓冲区**，这个缓冲区在服务器创建子线程之后开始使用，
当Redis服务器执行完一个写命令后，它会同时将这个命令发送给AOF缓冲区和AOF重写缓冲区。
5 当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数：
5.1将AOF重写缓冲区中的所有内容写入到新的AOF文件中，这时AOF所保存的数据库状态将和当前的数据库状态一致。
5.2对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。
6 信号处理函数执行完毕后，父线程继续接受命令请求
注：信号处理函数执行 是阻塞的
重启加载
AOF和RDB文件都可以用于服务器重启时恢复数据。如果开启了AOF持久化会选择加载AOF文件，只有在AOF持久化关闭时才会加载RDB文件。
RDB使用一次性生成内存快照方式，产生的文件紧凑压缩比更高，因此读取RDB文件恢复速度更快。由于每次生成的RDB文件开销比较大，无法做到实时持久化，一般用于数据冷备和复制传输
AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以控制实时/秒级持久化。因为需要不断的追加写命令，所以AOF文件体积会越来越大，需要定期执行重写操作来降低文件体积。
在执行BGREWRITEAOF命令时，Redis服务器还维护一个AOF重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。 当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件， 以此来完成AOF文件重写操作。
