1. Redis提供两种持久化方式 ： RDB 和AOF

bgsave 命令的运作流程

RDB优点：

是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照非常实用于备份，全量复制等场景。比如每6小时执行bgsave备份，并吧文件拷贝到远程机器或者文件系统中 hdfs ,用于灾难恢复。

RDB恢复数据远远快于AOF方式

缺点：

RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法箭筒新版RDB格式的问题。

AOF工作流程

AOF解决了实时性持久化数据问题 采用文本协议格式

原因是： 很好的兼容性、开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销、

文本协议具有可读性，方便直接修改和处理。

AOF为啥把命令追加到aof_bug中？

redis使用单线程响应命令，如果每次写AOF文件命令都直接加到硬盘，那么性能完全取决于当前硬盘负载。写写入缓冲区aof_bug中，可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

2.RDB使用一次性生成内存快照的方式，无法做到实时持久化，一般用于数据冷备和复制传输。

3.AOF通过追加写命令到文件实现持久化，通过appendfsync 参数可以控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。

4. save命令会阻塞主线程不建议使用，bgsave命令通过fork操作创建子进程生成RDB避免阻塞。

5.AOF重写可以通过 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数控制自动触发，也可以使用bgrewriteaof命令手动触发。

 AOF重写运作流程

6. 子进程执行期间使用copy-on-write 机制与父进程共享内存，避免内存消耗翻倍。AOF重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。

7.持久化阻塞主线程场景有： fork阻塞 和 AOF 追加阻塞。 fork 阻塞时间跟内存量和系统有关，AOF追加阻塞说明硬盘资源紧张。

8..单机下部署多个实例时，为了防止出现多个子进程执行重写操作，建议做隔离控制，避免CPU和IO资源竞争。

everysec 刷盘策略的过程

轮询控制AOF重写