AOF（Append-Only-File）持久化：保存写状态 记录下除了查询以外的所有变更数据库状态的指令，以append的形式追加保存到AOF文件中（增量）
vim redis.conf appendonly yes appendfileName "appendonly.aof"配置AOF写入方式： #appendfsync always 一旦缓存区的内容发生变化，就总是及时地将缓存区的内容写入到aof中 appendfsync everysec 将缓存区的内容每隔一秒写入到aof文件里 #appendfsync no 将写入aof的操作交给操作系统来决定
日志重写解决AOF文件大小不断增大的问题原理： redis首先fork()去产生一个子进程，子进程把新的AOF文件写到一个临时文件里，新的AOF的重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析或者进行命令的合并。主进程持续把新的变动写到内存里的buffer，同时也会把这些新的变动写到旧的AOF里面，这样即使重写失败也能保证数据的安全。当子进程完成文件的重写之后，主进程会获得一个信号，然后把内存里的buffer追加到子进程生成的新的AOF文件里。之后用新的AOF文件替换掉原先的AOF文件，这样就完成了一次日志重写的整个过程。
RDB和AOF的优缺点： RDB优点：全量数据快照，文件小，恢复快 RDB缺点：无法保存最近一次快照之后的数据 AOF优点：可读性高，适合保存增量数据，数据不易丢失 AOF缺点：文件体积大，恢复时间长
RDB-AOF混合持久化方式： 子进程在做AOF重写时，会通过管道从父进程读取增量数据并缓存下来，在以RDB格式保存全量数据时，也会从管道读取数据，同时不会造成管道的阻塞。也就是说AOF文件的前半段是RDB格式的全量数据，而后半段是redis命令格式的增量数据。
RDB-AOF混合式持久化方式： 是目前较为推荐的redis持久化方式，此种方式使用BGSAVE做镜像做全量持久化，AOF做增量持久化。因为BGSAVE会耗费较长时间不够实时，在停机的时候会导致大量丢失数据的问题，所以需要AOF来配合使用。在redis服务重启时会使用BGSAVE做持久化文件重新构建内容，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。
