* 介绍
* 提供了AOF和RDB两种持久化机制，持久化功能有效避免了进程退出造成的数据丢失问题，当下次重启时利用之前的持久化文件即可实现数据的恢复。
* RDB
* 是把当前进程数据生成快照保存到磁盘的过程
* 触发机制
* 手工触发
* save命令:阻塞当前redis服务器，直到rdb过程完成为止。
* bgsave命令
* redis进程执行fork操作创建子进程，rbd持久化过程由子进程负责，完成后自动回复，阻塞只发生在fork阶段。
* bgsave借助写复制技术，在生成快照的同时，依然正常处理命令。
* bgsave子进程是由主进程fork的，可以共享主线程的所有内存数据
* 自动触发
* m秒内数据集至少n个改动
* 文件处理
* 保存
* rdb文件保存在dir配置文件的目录下，文件名通过dbfilename配置，可以通过执行config set dir {newdir}在运行期动态执行。
* 压缩：默认采用lzf算法对rdb文件做压缩处理
* 通过config set rdbcompression yes|no配置
* 优缺点
* 优点
* 紧凑压缩的二进制文件
* 仅代表redis在某个时间点上的数据快照
* 非常适合备份、全量复制场景
* 比如说每天某个时间点执行bgsave，并把rdb文件拷贝到远程机器或者文件系统，用于灾难恢复
* 缺点
* 无法做到秒级/实时的持久化
* 每次执行bgsave执行fork创建子进程，都属于重量级
* rdb文件使用了二进制格式保存，redis版本演进过程中有多个格式的rdb版本，存在老版本redis服务器无法兼容新版本格式的问题
* AOF
* 每次写命令都会记录独自的日志，重启时候再重新执行AOF文件中的命令达到恢复数据的目的。
* AOF主要作用是解决了数据持久化的实时性
* 流程
* 所有的写入命令追到aof_buf缓存区中
* aof缓存区根据对应的策略向磁盘做同步操作
* 随着AOF文件越来越大、需要定期对AOF进行文件重写，达到压缩目的
* 当redis服务器重启时、可以加载AOF文件进行恢复
* 如何使用
* 开启AOF功能需要配置 appendonly:yes
* 默认是不开启
* 工作流程
* 命令写入
* 文件同步
* redis提供了多种AOF缓存区同步文件策略，由参数appendfsync控制：
* always
* 命令写入aof_buf后调用系统fsync操作同步到AOF，fsync完成后线程返回
* everysec
* fsync同步文件操作由专门线程每秒调用一次
* no
* 由操作系统完成，通常同步周期是30s
* 重写机制
* 随着命令不断写入AOF，文件会越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件体积。
* AOF重写过程可以手动触发和自动触发
* 手动触发
* 直接调用bgrewriteaof命令
* 自动触发
* 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
* 重启加载
* 文件校验
