1 什么是持久化
Redis 支持RDB和AOF 两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题。当下次重启时利用之前持久化的数据快照文件即可实现数据恢复。
配置文件：
save 100 时间，单位是s，100s内修改1次就会做更新
1.1 aof
aof 实时存储：
1、aof的参数
- dir 存储路径 /. 表示在哪里启动，文件在哪里生成
- appendonly：默认no，如果设置为yes，就打开了实时存储
- appendfilename 存储文件的名字
1.2 rdb
rdb 定时存储：
1、rdb 的参数
- dir 存储路径 /. 表示在哪里启动，文件在哪里生成
- rdbdfilename 存储文件的名字
2、风险：容易丢失数据；避免风险：使用aof 实时存储
3、如果数据没有那么重要，可以使用rdb。
2 RDB持久化
是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
2.1 RDB 是什么
RDB在指定的时间间隔内将内存中的数据集快照写入磁盘。
原理是redis 会单独创建（fork）一个与当前进程一模一样的子进程来进行持久化，这个子进程的所有数据（变量，环境变量，程序计数器等）都和原进程一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，是一个全量的过程。
整个过程，主进程不进行任何的io操作，这就确保了极高的性能。
问题1：这个持久化文件在哪里？
rdb有两个参数：
- dir 存储路径 /. 表示在哪里启动，文件在哪里生成
- rdbdfilename 存储文件的名字
问题2：它什么时候fork子进程，或者什么时候触发rdb持久化机制？
- shutdown时，如果没有开启aof，会触发。
- 配置文件中默认的快照配置 :
- save 900 1 900秒内执行1次增删改 就会触发rdb
- save 300 10 300秒内执行10次增删改 就会触发rdb
- save 60 10000 60秒内执行10000次增删改 就会触发rdb
- 如果是集群的话，master就会把这些关掉（注释掉）
- 执行命令 save 或者 bgsave ：
- save只保管，其他不管，全部阻塞；
- bgsave redis会在后台异步进行快照操作，同时可以响应客户端的请求。
1.执行flushall命令，但是里面是空的，无意义。（清空16个数据库的数据）
2.2 手动触发
手动触发分别对应save和bgsave命令。
- ·save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
- ·bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
3 AOF持久化
3.1 aof 是什么
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不记录，以文本的方式记录，可以打开文件看到详细的操作记录。是以增量的方式进行持久化，即一点点的进行持久化，不是一下子把所有数据都记录下来。
原理是将redis的操作日志以追加的方式写入文件，读操作不记录下来。
如：set k1 1 写到文件，再运行这个文件，所有写操作都做一遍。
问题1： 这个持久化文件在哪里？
aof的参数：
- dir 存储路径 /. 表示在哪里启动，文件在哪里生成
- appendonly：默认no，如果设置为yes，就打开了实时存储
- appendfilename 存储文件的名字
问题2： 触发机制是什么？
根据配置文件配置项：
- no：表示等操作系统进行数据缓存同步到磁盘（快，持久化没保证）
- always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全）
- everysec：表示每秒同步一次（快，但是可能会丢失1s的数据）
3.2 appendfile 文件说明：
*2 说明下面有2组命令，*
$6 代表长度为6，$
SELECT
0 代表数据放入0库
*3
$3
set
$2
kk
$2
vv
3.3 aof 重写机制
- 当AOF文件增长到一定大小的时候，redis能够调用
bgrewriteaof对日志文件进行重写。当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100
- 当AOF文件增加到一定大小的时候，redis能够调用bgrewriteaof对日志文件进行重写。当AOF文件大小大于该配置项时自动开启重写。
auto-aof-rewrite-min-size 64mb
bgrewriteaof 是重写的命令
3.4 redis 4.0 后混合持久化机制
- 4.0 版本的混合持久化默认关闭，通过 auto-use-rdb-preamble 配置参数控制。
- yes 表示开启，no 表示禁用。
- 5.0 之后默认开启。
混合持久化是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后再将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的AOF文件。
简单说：新的AOF文件前半段是RDB格式的全量数据；后半段是AOF格式的增量数据。
优点：混合持久化结合了RDB持久化和AOF持久化的优点，由于绝大部分都是RDB格式，加载速度快，同时结合AOF。增量的数据以AOF方式保存了，数据更少丢失。
缺点：兼容性差，一旦开启了混合持久化，在4.0之前版本都不能识别该aof文件，同时由于前部分是RDB格式，阅读性比较差。
4 AOF和RDB的总结
1、redis提供了rdb持久化方案，为什么还要aof？
优化数据丢失问题，rdb会丢失最后一次快照后的数据，aof丢失不会超过2s的数据。
2、如果aof 和rdb同时存在，听谁的？
aof
3、rdb和aof的优劣势
1 RDB：
使用RDB好处：
- redis 数据库只有这一个文件，方便备份，可以很容易将一个RDB文件移动到其他存储介质上。
- RDB恢复大数据集的速度比AOF快。
- RDB可以最大化redis的性能：父进程在保存RDB文件时唯一要做的就是 fork 一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘 I/O 操作。
使用RDB坏处：
- 需要尽量避免在服务区故障时丢失数据，虽然redis 允许设置不同的save point 来控制保存RDB文件的频率，但是RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。你可能会至少五分钟才保存一次RDB文件，在这种情况下，一旦发生故障停机，就会丢失好几分钟的数据。
- 每次保存RDB的时候，Redis都要fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大地时候，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且CPU时间非常紧张，那么这种停止时间甚至可能会长达整整一秒。虽然AOF重写也需要进行 fork() ，但是无论AOF重写的执行间隔有多长，数据的耐久性都不会有任何损失。
总结RDB：
rdb适合大规模数据恢复，对数据完整性和一致性不高，在一定间隔时间做一次备份，如果redis意外down机的话，就会丢失最后一次快照后的所有操作。
2 AOF：
使用AOF的好处：
- 让redis变得非常耐久（nuch nore durable）
2.AOF文件是一个只进行追加操作的日志文件（append only log），因此对AOF文件的写入不需要进行 seek，即使日志因为某些原因而包含未写入完整的命令（比如写入时磁盘已满，写入中途停机等），redis-check-aof 工具也可以轻易地修复这种问题。
3.redis 可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写，重写后的新 AOF 文件包含了恢复当前数据集所需要的最小命令集合。重写操作绝对安全。 - AOF 文件有序地保存了对数据库执行的所有的写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析也很轻松，导出AOF也很简单。
使用AOF的坏处：
- 对于相同的数据集来说，AOF 文件的体积通常要大于RDB文件的体积
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。
- 在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间。
官方建议：两种方式同时开启，优先使用aof。
4、性能建议（只针对单机版redis持久化做性能建议）：
- 因为RDB文件只用作后备用途，只要15min备份一次就够了，只保留 save 900 1 这条规则。
- 如果Enable AOF，好处就是在最恶劣情况下也只会丢失不超过2s的数据，启动脚本较简单，只load自己的aof文件就可以了。
- 代价一是带来了持续的IO，二是AOF rewrite 的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎不可避免。
- 只要硬盘许可，应该尽量减少AOF rewrite 频率，AOF 重写基础可以设到5G以上。