redis持久化RDB/AOF两种方式

RDB 快照持久化：保存某个时间点的全量数据快照

手动触发持久化通过2个命令生成dump.rdb文件：

1. save:阻塞redis的服务器进程，直到rdb文件生成完毕（少用）
2. bgsave:检查是否存在子进程正在持久化数据，不存在则fork出一个子进程来创建rdb文件，不阻塞服务器进程
   具体：会派生出一个子进程接收bgsave当前数据库状态，父进程继续处理接收到的命令，子进程完成后会给父进程发送命令，父进程在接收命令的同时通过轮询方式接收子进程的信号。基本上就是通过后台的方式保存rbd文件，调用此命令后会like返回OK，父进程会立刻fork子进程处理，并立刻恢复对客户端的服务，子进程会将内容写入临时rdb文件中，最后替换原rdb文件。
   使用lastsave命令会返回上一次执行save/bgsave的时间（一串数字）
   实际上在创建子进程的过程只创建了虚拟空间，父子进程使用的同一个物理空间，只有当父子进程发生更改才会为子进程分配独立的物理空间（Copy-on-Write），这种方式称之为写时复制。
   写时复制参考：https://blog.youkuaiyun.com/u010712083/article/details/8963202

自动触发条件：

1. 根据redis.conf配置的save m n定式触发（用是bgsave）
2. 主从复制时，主节点自动触发
3. 执行debug reload
4. 执行shutdown且没有开启AOF持久化

缺点：无法保存最近一次快照之后的数据
优点：全量数据快照，文件小，恢复快

AOF持久化：保存写状态

记录下除了查询以外的所有变更数据库状态的指令，以增量的形式追加保存到AOF文件中 appendonly.aof，会随着数据量的增大导致aof文件大小不断增大，aof 默认就是文件的无限追加，文件会越来越大！
可通过日志重写解决文件大小问题 原理：调用fork()创建一个子进程，子进程将新的AOF写到一个临时文件里，不依赖原来的AOF文件，主进程会持续将新的变动同时写到内存和原来的AOF里，主进程获取子进程重写AOF完成的信号，往新AOF同步增量变动，使用新的AOF文件替换掉旧的AOF文件

可以通过手动方式触发重写
也可以在配置文件中配置：如果aof文件大于64m触发

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

缺点：文件体积大，恢复时间长
优点：可读性高，适合保存增量数据，数据不易丢失

RDB和AOF文件共存的情况下恢复方式

redis会扫描是否存在aof文件，如果存在则加载aof，如果不存在载检查是否存在rdb文件进行加载

redis4.0之后推出RDB-AOF混合持久化方式
使用bgsave做镜像全量持久化，aof做增量持久化。