部分参考地址：
较详细：https://baijiahao.baidu.com/s?id=1654694618189745916
简明扼要：https://blog.csdn.net/qq_39291929/article/details/103436742
很全：https://www.cnblogs.com/naci/p/3824815.html
aof重写机制详解：https://blog.csdn.net/hezhiqiang1314/article/details/69396887
持久化流程
1. 客户端向服务端发送"写"操作请求（此时，数据存在于客户端内存中）
2. 数据库服务端接收写请求（此时，数据存在与服务端内存中）
3. 服务端调用write（write是个系统的调用），将数据向磁盘上写（此时，数据存在于系统内存的缓冲区）
4. 对系统进行操作，将缓冲区中的数据，写入磁盘控制器（此时，数据存在于磁盘缓存中）
5. 磁盘控制器将数据写到磁盘的物理介质上（此时，数据真正存在于物理磁盘上了）
持久化方式：
1：RDB（redis database）
快照:每隔指定时间，将所有数据进行拍照保存(相对耗时)，redis默认的持久化策略，二进制文件保存，默认文件名dump.rdb。
触发方式：
客户端发送指令 save：会阻塞当前redis服务器，执行save命令期间，redis不饿能处理其他命令，直到rdb过程结束执行完成后， 如果发现存在就得rdb文件，则用新的替换掉旧的。（若数据量大，则此方式不可取）客户端发送指令 bgsave(background save)：会在后台进行异步的快照操作，保证了在快照操作的同时，还可以响应客户端请求。
具体操作：redis进程执行fork操作，创建子进程，持久化操作由子进程负责，完成后自动结束。 也会发生阻塞，但时间很短。基本上redis内部的所有rdb操作都是bgsave命令。快照执行期间，主进程修改的数据不会被保存 自动触发（配置redis.conf文件，默认使用bgsave命令）
- 文件内搜索save：其中的 **save seconds changes**为触发快照的条件，即：当**seconds**秒内，数据被修改了**changes**次，就会触发rdb快照。
- 文件内搜索stop-writes-on-bgsave-error ：默认值为yes：当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了；
- 文件搜索rdbcompression ；默认值是yes。：对于存储到磁盘中的快照，可以设置是否进行压缩存储。
- 文件搜索rdbchecksum ：默认值是yes：在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
- 文件搜索dbfilename ： 设置快照的文件名，默认是 dump.rdb
- 文件搜索dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# save
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# 默认三个都开启，不需要持久化的时候，就注释掉所有的save来停掉保存功能
save 900 1 # 900秒内，只要有1次变化，就执行
save 300 10 # 300秒内，只要有10次变化，就执行
save 60 10000 # 60秒内，只要有10000次变化，就执行
对比：
因为第三种方式是配置的，所以我们对前两种进行一个对比：
```
命令 | save | bgsave
io类型 | 同步 | 不同步
阻塞 | 是 | 仅在fork时阻塞
优点 | 不占内存 | 不会阻碍客户端请求
缺点 | 会阻塞客户端的请求 | 需要fork，占用内存,可能会丢失fork期间主进程修改的数据
```
优劣：
* 恢复：直接读取持久化文件到内存中(恢复大数据时，速度很快)
* 优势：
1. rdb文件只有一个，存储的是内存数据的二进制序列化形式，且文件紧凑，体量较小（文件不大），全量备份，非常适用于备份和灾难恢复
2. 生成rdb文件时，单独fork一个进程来执行保存操作，主进程不进行任何io，并可同时接受前台的请求
3. 恢复大数据集时速度更快
* 劣势：
当进行快照持久化时，主进程单独fork了一个 子进程 专门负责快照持久化，子进程会拥有主进程的内存数据，主进程修改内存时， 子进程不会反应出来，所以在快照持久化期间主进程修改的数据不会被保存，可能丢失数据。
2.AOF(appendonly.aof)
* 增量追加：调用write函数进行文件使用增量追加（类似于日志模式）
* 触发方式：
* （1）always(每有修改同步)：
每当有一个“写”命令过来时，则通过write函数，直接保存命令本身到aof文件的末尾
* （2）everysec(每秒同步)：
异步操作，每秒记录 （如果一秒内宕机，有数据丢失）
* （3）no(不同步)：从不同步
```
命令 | always | everysec
优点 | 不丢数据 | --
缺点 | io开销很大，一般的 |丢一秒数据
| sata盘只有击败tps
```
* 文件重写：
触发：由系统判断是否满足重写条件，或客户端输入命令 bgrewriteaof
重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
为了压缩此文件，官方给出了**bgrewriteaof**命令，将内存中的数据以命令的方式保存到临时文件中， 同时会fork出一个新进程来将文件重写 重写的过程中，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件（类似于快照） aof 持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大； 越来越大的aof文件影响包括但不限于：对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间增加；
为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件， 新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
详情：https://blog.csdn.net/hezhiqiang1314/article/details/69396887
* 优点
1. 数据完整（每秒/每修改）
2. 几乎不阻塞主进程（仅在重写机制临近结束时，会有暂时性的阻塞）
3. 重写机制保证文件不会过大
* 缺点
1. 相比rdb模式，aof文件还是大了
2. io请求次数还是有点多的，所以速度相对rdb来说 ，无论是存储，还是恢复 还是慢的
如果同时开启了aof和rdb，则系统在恢复数据时，仅会执行aof
