redis有2种持久化方法
1.RDB
手动触发为bgsave命令
1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞。
3）父进程fork完成后，可以继续响应其他命令。
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。
5）进程发送信号给父进程表示完成
RDB的优点/缺点
优点
Redis加载RDB恢复数据远远快于AOF的方式缺点
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
2.AOF
以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的主要作用是解决了数据持久化的实时性。
1）所有的写入命令会追加到aof_buf（缓冲区）中。
AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。
2）AOF缓冲区根据对应的策略向硬盘做同步操作
同步文件策略
always
每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置。everysec
是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。no
由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
3）AOF文件重写
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。
4）重启加载
AOF和RDB文件都可以用于服务器重启时的数据恢复。下图表示Redis持久化文件加载流程
