三种持久化策略
AOF
ps：AOF的诞生是为了解决早期的RDB无法及时持久化的问题
redis执行写命令操作后，会把其命令追加到AOF文件里，AOF是文本格式文件，AOF持久化默认是默认关闭
AOF的刷盘时机有三种，具体是由config里的appendfsync 参数控制的
1.always：每执行一条写命令就写入一次（每次write，每次fsync）
2.Everysec：每秒执行追加到文件一次，会先将命令写到AOF对应的内核缓冲区，后每隔一秒再写入
磁盘中的文件（每次write，每秒fsync）
3.no：由操作系统来决定啥时候刷盘（每次write）
AOF重写
它这个就是说当AOF文件大小到达某些阈值后（可配置），会读取redis中的所有键值对，生成命令写入 新的AOF文件里，然后用新的替换旧的
目的：给文件瘦身，比如说一开始有set saki 69，set saki 91两个命令，重写后就只有set saki 91一条
命令了
为什么要用新的文件替换旧的文件，而不是直接覆盖呢
怕重写一般失败了，污染了旧文件
写入是在主线程执行的，因为写入的量不多。但重写是会fork子进程来完成的，这其中会把父进程的数据拷贝一份
….(待补充)
为了避免子进程在重写时，主进程的数据发生了变化，导致AOF文件里的数据和内存里的对应起来不一致。redis对其进行了一层优化，即将重写阶段新来的数据写入AOF的重写缓冲区里，等到AOF重写完成后，再把AOF重写缓冲区里的数据追加到新的AOF文件中。
RDB快照
RDB快照就是指记录某一时间段的内存数据，记录的是实际数据，因此在做内存恢复时效率是要比AOF高不
少的。
RDB可以直接读入内存就好了，不用像AOF那样需要执行命令
RDB是紧凑的二进制文件
RDB还提供了两种命令来生成RDB文件
save：主线程直接执行，会阻塞正常命令的执行
bgsave：操作系统fork子进程执行，可以避免主线程的阻塞
生成RDB时，不会保存过期的key
导入RDB时，主节点会对过期key进行过滤，而从不会
bgsave和AOF重写一致，都会fork子进程，但在bgsave期间新来的数据是不会被保存到此时的RDB的，只能等到下一次RDB
其他生成
正常停机时生成一次RDB
内部触发机制 比如save/bgsave 91 1：代表91秒内至少有1个key被修改，就RDB一次
redis默认的持久化策略：采用RDB
save 900 1
save 300 10
save 60 10000
appendonly no
注意：这个save不会阻塞主线程，**Redis 自动触发 ****bgsave** 来生成快照