redis持久化机制
redis提供了两种持久化机制：
- 快照（snapshot）：保存某一时刻的数据状态
- AOF（appen only file）：将写命令记录到日志文件中
快照
- 默认的持久化机制
- 保存以
.rdb结尾的文件，于是也被称为RDB方式
快照生成方式
-
客户端执行BGSAVE、SAVE指令
-
服务器配置自动触发
900 1
300 10
60 10000
BGSAVE
当接收到客户端的BGSAVE指令后，redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘中，而父进程则继续处理命令请求。
fork：当一个进程创建子进程的时候，底层操作系统会创建该进程的一个副本。在类UNIX系统中，创建子进程的操作会被优化：刚开始的时候，父子进程共享同一份内存，只有在父或子进程对内存进行了写操作后，共享才会结束
SAVE
整个进程都会进行创建快照的操作，在创建快照完成之前redis处于阻塞状态
AOF
- 开启AOF持久化，修改
appendonly yes - 修改
appendfilename "appendonly.aof"指定生成文件名称
日志追加频率
always 【谨慎使用】
- 每个redis写命令都同步到硬盘。
- 如果同一时间内大量涌入写命令，会引发严重的写入放大问题（向硬盘写入大量小文件导致硬盘寿命缩减等问题）
everysec 【推荐】
- 每秒执行一次同步。最多只会丢失1秒内的数据
no 【不推荐】
- 由操作系统决定何时同步。看命，如果一次性堆积大量写操作然后同步，也会导致redis处于阻塞状态
set a 100 执行一万次，即使最终的结果只有一条，但是aof文件中却会保存所有指令。所以日久天长，aof文件可能越来越大，所以就有了AOF重写
AOF重写
-
客户端方式触发重写
执行
BGREWRITEAOF命令 不会阻塞redis服务 -
服务器配置方式自动触发
修改redis.conf中的两个选项：
-
auto-aof-rewrite-percentage 100
-
auto-aof-rewrite-min-size 64mb
如果这么设置，当启用了AOF持久化时，当AOF文件体积＞64MB，且上一次重写之后体积增加了100%时，就自动重写一次
如果重写过于频繁，则可以将
auto-aof-rewrite-percentage设置大一些 -
AOF重写原理
AOF重写，并没有读取旧有的aof文件，而是将整个内存中的数据库用命令的方式写成一个新的aof文件，用来替换就有的aof文件。
重写流程：
1、redis调用fork，产生子进程，子进程生成快照，将快照中的数据信息以写入命令的方式存入临时文件
2、父进程继续处理来自客户端的请求，并将这些请求中所有写命令存入旧aof中的同时，再存入一份到缓存中
3、子进程将快照中的内容以命令形式全部写入临时文件后，通知父进程，然后父进程将刚才缓存的新命令追加到临时文件
4、父进程将临时文件替换旧有的aof文件。后面收到的命令也开始向新的aof文件中追加
