简介：
在指定的时间间隔中，将内存中的数据集快照写入磁盘。
Redis提供了两种不同的持久化方式
RDB（Redis Database）
Redis会单独创建（folk）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
备份：
Redis内存 -> 临时文件 -> dump.rdb
读取:
dump.rdb -> Redis内存
Fork：
保证数据一致性
Fork
Fork的作用是复制一个与当前进程，用到了写时复制技术。
Dump.rdb
是用来存储数据的文件，持久化。
在redis.conf – snapshotting（快照）中可以找到相关配置
打开save后才会启用持久化
dbfilename [filename] // 文件名
dir./[路径] // 文件生成的路径，默认为桌面
stop-writes-on-bgsave-error [yes/no] // 当Redis无法写入磁盘时，关闭redis，默认为yes
rbdchecksum [yes/no] // 检查完整性 CRC64算法数据校验 ~10%性能消耗 默认为yes
save [interval] [changes] // 在间隔中如果数据库的变化的key计数到达设定值，保存快照。保存时会阻塞所有其他请求，不建议。
优势：
适合大规模的数据恢复
对数据完整性和一致性要求不高
节省磁盘空间
恢复速度快
劣势：
Fork的时候，内存中的数据被克隆，要考虑空间资源的占用
写实复制计数在数据庞大时，仍会比较消耗性能。
在备份周期的一定间隔时间做一次备份，如果Redis意外下线，可能会造成最后一次备份的数据丢失
AOF（Append Only File）
简介：
以日志的形式来记录每个 写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许以append方式修改文件，redis启动时会读取该文件重新构建数据。
AOF 持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区中
- AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘的AOF文件中
- AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
- Redis重启时，会重新load加载AOF文件，达到恢复数据的目的
AOF默认设置
在redis.conf中开启AOF并配置文件名称，默认为appendonly.aof
appendonly yes
appendfilename "[filename]"
// 和rdb文件路径相同
AOF和RDB优先级
如果AOF和RDB同时开启，系统会优先取AOF的数据（因为它包含了更详细的写日志操作）
从Redis 4.0开始，Redis引入了混合持久化（Hybrid Persistence），将RDB快照和AOF日志结合在一起，以同时利用两者的优点。RDB用于快速恢复，AOF用于保证数据的完整性。这可以大大减少数据恢复时间。
AOF启动 / 修复 / 恢复
是以文件形式保存，只需要拷贝就可以读取。 如果AOF文件损坏，redis-server不能正常启动
如遇到AOF文件损坏，通过在/usr/local/bin 目录下执行 redis-check-aof –fix appendonly.aof 恢复
根据语法恢复。
AOF同步频率设置
appendfsync always 始终同步，每次Redis的写入都会立即写入日志
性能较差但完整性好
appendfsync everysec 每一秒都会同步
appendfsync no AOF更新时机由主机决定
AOF Rewrite重写机制
AOF采用文件追加（append）方式，文件会越来越大。重写机制在AOF文件的大小超过设定的阈值时，Redis会对AOF文件进行内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof，AOF会fork出一条新进程重写文件，类似rdb的快照。
Redis会记录上次重写后的AOF大小，默认配置是当AOF文件大小事上次rewrite后大小的一倍且文件大于基准值时触发，也可以自行配置。
auto-aof-rewrite-min-size [num] 设置重写的基准值
RDB和AOF，用哪个？
如果对数据恢复要求高，容忍少量数据丢失，可以使用RDB 如果对数据丢失非常敏感，AOF会比RDB更好。
官方推荐两个都启用。