redis 支持RDB 和AOF 两种持久化机制，持久化功能可以避免进程退出造成的数据丢失问题，可以利用持久化的文件实现数据恢复
RDB
RDB 持久化是把当前进程数据生成快照保存到硬盘的过程
触发机制
手动触发：
save命令：阻塞当前redis服务器，直到RDB完成，内存较大的redis实例会造成阻塞长时间，已弃用
bgsave命令：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段，一般时间很短
自动触发：
1.使用save相关的配置，eg ‘ save m n’ 表示m秒内数据存在n次修改时，自动触发bgsave
2.如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB快照并发送给从节点
3.执行debug reload 重启加载redis时，自动触发
4.默认情况下执行shutdown 命令时，如果没有开启AOF持久化功能则会自动执行
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename 配置指定，可通过执行 config set dir {newDir} 和 config set dbfilename {newFileName} 运行时配置，当下次运行RDB时就会保存到新目录，
也可在redis.conf中进行配置，重启后生效
如果redis突然断电导致RDB文件损坏时，redis再次重启后会拒绝重启，可以使用redis-check-dump 工具检测RDB文件，并获取对于的错误报告
RDB的优缺点
优点
RDB是个紧凑的压缩二进制文件，代表的是磨一时间点的数据快照，非常适合用于备份，全量复制的场景，RDB数据加载速度好于AOF
缺点
没办法做到实时/秒级持久化，因为bgsave每次都要fork子进程，属于重量级操作，频繁执行成本过高，RDB使用特点的二进制文件，对新老版本有不兼容问题
AOF
AOF(append only file ) 持久化：记录写命令，每次重启时再重新执行AOF文件中的命令，主要解决数据持久化的实时性，一般配合RDB使用
开启aof：appendonly yes，默认文件名：appendonly.aof 保存路径和rdb一致
工作流程：
1.所有的写命令会追加到aof_buff中
2.aof 缓冲区根据对应的策略向硬盘做同步操作
3.aof文件越来越大时 ，要定期对aof进行重写，达到压缩的目的
4.redis重启时，可以加载aof文件进行数据恢复（RDB同时存在时，优先使用aof）
AOF为什么把命令追加到aof_buff ，而不直接写入文件
redis使用单线程响应命令，如果每次都把命令直接写入文件，那么redis的性能就取决于磁盘的IO性能，先写入aof buff缓冲区，还可以提供多种缓冲区同步磁盘策略
AOF文件同步策略
aof同步策略由参数appendfsync 控制
always : 命令写入aof_buf 后调用系统fsync 操作同步到aof文件，fsync完成后线程返回
everysec : 命令写入aofbuff后调用系统write操作，write完成后线程返回，fsync同步文件操作由专门线程每秒调用一次（建议）
no: 命令写入aofbuff后调用系统write操作,不对AOD文件做fsync同步，同步磁盘操作由系统负责，通常同步周期最长30秒
