redis-持久化（1）
目录
一、RDB
1.1 触发机制
1.2 流程说明
1.3 RDB优缺点
二、AOF
2.1 开启AOF
2.2 AOF流程
三、重启加载流程
持久化即备份，这是单机高可用的策略之一，有了备份，就可以在Redis故障通过备份进行恢复。redis持久化主要有RDB和AOF。
RDB
RDB（Redis DataBase），基于策略定时将redis内存中的数据保存到硬盘。需要时可以通过这个备份文件进行恢复。
AOF
AOF（Append Only File），是把每次redis执行的命令记录到日志文件中（类似于MySql的Bin log），当Redis启动时可以通过执行log中的命令来恢复数据
一、RDB
1.1 触发机制
save命令：阻塞当前redis服务器，直到RDB过程完成，服务器在阻塞期间不能处理如何客户端请求，原则上save命令已经废弃。
bgsave命令：会fork一个子进程，RDB的持久化由这个子进程来完成，阻塞只发生在fork阶段，耗时较短，子进程执行rdb期间redis服务器不会阻塞，正常处理客户端请求。
自动触发机制：在redis.conf 配置：
save m n
代表如果在m秒内存在n次的修改时，则执行bgsave命令
1.2 流程说明
执行bgsave命令，redis父进程判断如果当前存在正在执行的子进程，则直接返回，比如AOF或者RDB子进程。
父进程fork一个子进程，fork过程父进程是阻塞，无法响应客户端请求
fork结束后，bgsave返回“background saving started”信息，并且不再阻塞父进程，父进程可以继续响应客户端请求。
子进程根据父进程的内存快照创建RDB文件，完成后对原有文件进行原子替换。
子进程发送信号给父进程表示RDB完成
1.3 RDB优缺点
优点
RDB是一个压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景
Redis加载RDB恢复数据远远快于AOF
缺点
RDB无法做到实时持久化
兼容性问题，新版本的redis可能无法兼容老版本的RDB
为了解决实时持久化问题，redis引入了AOF。
二、AOF
2.1 开启AOF
AOF默认是关闭的，通过如下命令开启：
appendonly yes
2.2 AOF流程
AOF工作基本流程：
命令写入（append）：redis所有的写入命令会追加到aof_buf（缓冲区）中
文件同步（sync）：AOF缓冲区根据对应的策略向硬盘做同步操作
文件重写（rewrite）：随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
重启加载（load）：redis启动后可以加载AOF文件进行数据恢复。
命令写入
对于每一条redis写入命令，在AOF中会追加一条文本，文本格式是redis文本协议格式（RESP），直接采用协议格式，以来兼容性和可读性高，二来避免了二次处理的开销。
如果直接把命令写入硬盘会影响到redis的性能。先写入aof_buf，然后后期通过同步策略写入硬盘，避免直接的IO影响到redis的性能。
文件同步
redis提供了多种AOF缓冲区文件同步策略，同步策略分别使用了操作系统的wirte函数和fsync函数，说明如下：
write: 会触发延迟写（delayed write）操作，为了性能，linux在内核提供了页缓冲区用来提高硬盘的IO性能，write操作在写入系统缓冲区后直接返回，后期同步硬盘操作依赖于操作系统调度（比如按时，或者缓冲区慢等）。如果在同步前出现系统宕机故障，缓冲区的数据会丢失。
fsync: 强制操作系统将缓冲区的操作同步到硬盘。
由appendfsync参数控制：
| 可配置的值 | 说明 |
|---|---|
| always | 命令写入buf后调用系统调用fsync同步AOF文件，fsync完成后线程返回 |
| no | 命令写入buf后调用系统调用write操作，后续fsync同步操作由操作系统来完成，一般为30秒一次。 |
| everysec | 命令写入buf后调用系统调用write操作，后续fsync同步操作专门线程每一秒调用一次。 |
everysec是always和no的折中，是性能和安全性的这种，是redis默认的配置，也是比较推荐的配置。
文件重写
文件重写就是把Redis进程里面的最新数据转化为写命令然后同步到aof文件的过程，通过重写不但可以减小aof文件的体积，从而进一步提高aof文件在恢复过程中的加载速度。
由以下原因可以通过aof重写减少aof文件的体积：
旧的apf包含过期的数据不再写入aof，比如 set k1 aaa，这条命令已经过期，但是已经在aof文件中存在，通过重写这条命令将移除aof文件。
旧的aof中存在无效的命令，比如set k1 111,set k1 222，aof中存在两条命令，其实第一条已经失效，通过重写，可以变成一条。
多条命令命令合并。
触发机制：
手动触发：执行bgrewriteaof命令
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机：
auto-aof-rewrite-min-size：表示运行aof重写时文件的最小体积，默认为64MB
auto-aof-rewrite-percentage：表示当前aof文件的size（aof_current_size）和上一次重写后aof文件的size(aof_base_size)的比值。
只有当以上两个条件同时满足时，才会触发自动aof
aof重写流程：
执行aof重写请求
父进程fork一个子进程，开销等同于bgsave时候fork的过程
aof缓冲区写入
fork结束后，主进程继续响应客户端请求，所有修改命令都会写入aof_buf，后续基于appendfsync策略写入硬盘
由于fork操作运用写时复制技术，子进程只能共享fork操作时的的内存数据。在执行bgrewrite期间，主进程依然在响应命令，redis用aof_rewrite_buf来保存这部分数据，防止在新的aof文件生成期间丢失这部分数据。
写入新的AOF，子进程基于fork后的aof_buf（快照）生成新的aof文件
后续操作
子进程发送信号通知父进程aof生成完成，父进程更新相关统计信息
父进程把aof_rewrite_buf的数据写入到新的aof文件
使用最新的aof文件替换老文件，完成最终的AOF重写。
三、重启加载流程
优先加载AOF
AOF关闭时加载RDB
加载成功后redis才能成功启动
加载失败，则redis启动失败