RDB和AOF高可用

定时执行RDB快照，既实现了块，也实现了持久化。 有两种情况会触发RDB快照持久化。

1. 手动触发：执行save（主线程执行会阻塞）或bgsave（fork一个子进程用于写入临时RDB文件，持久化交给子进程来处理，阻塞只会发生在fork阶段，生成RDB文件的默认配置使用的就是该命令）
2. 自动触发：
   1. 在redis.conf配置save m n，在m秒内至少有n个key更改，自动触发bgsave
   2. 主从复制：从节点需要从主节点进行全量复制时会触发bgsave操作，把生成的RDB文件发送给从节点。
   3. shutdown命令，如果没有开启AOF持久化，那么也会触发bgsave
   4. 执行debug reload命令重新加载Redis会触发bgsave。

如果配置 save ""，则表示关闭RDB快照 在对内存数据做RDB快照时，并不会暂停写操作。 使用了多进程写时复制技术（COW）来实现RDB快照持久化。（通过fork产生子进程） 在子进程产生时，它和父进程共享内存里面的代码段和数据段。 bgsave的子进程可以共享主线程的所有内存数据，所以能读取主线程的数据并写入RDB文件。 优点：

1. RDB文件采用二进制格式数据和数据压缩的方式写磁盘，文件体积远小于内存大小，适合备份和全量复制。
2. RDB文件加载恢复数据的速度远远快于AOF文件。

缺点：

1. 实时性不够，无法做到秒级持久化。
2. 通过bgsave调用fork函数创建子进程，子进程属于重量级操作，频繁执行成本高。

AOF持久化记录的是服务器接收的每个写操作，在服务器启动，重放还原数据集。 AOF采用的是 先写内存，后写日志 。 在MYSQL InnoDB引擎，在实际修改数据前 先记录修改redolog ，再修改数据，这种是 先写日志（WAL） appendonly yes AOF的配置项：

1. always:同步写回，写命令执行完毕立刻将aof_buf缓冲区的内容写到aof文件。
2. everysec：每秒写回，写命令执行完，日志只会写到AOF文件缓冲区，每隔一秒就把缓冲区的内容同步到磁盘。
3. no:操作系统控制，写命令执行完，把日志写到AOF文件内存缓冲区，由操作系统决定何时同步到磁盘。

AOF可以将多个命令压缩成一条。 通过主线程fork出一个bgrewriteaof 且7.0之后，主线程将新来的写命令写入到新的INCR AOF文件，子进程在cow写时复制得到内存快照数据，写入到新的Base AOF文件，重写结束后，将两个文件合并并记录为新的，原来的记录为history。 优点：

1. 持久化实时性高
2. 是一种追加日志，不会出现随机磁盘读写。
3. 易于理解和解析的格式，包含所有操作的日志。
4. 写操作执行成功才记录日志，避免了命令语法检查开销，同时不会阻塞当前写命令。

缺点：

1. 由于AOF记录的是一个个命令，因此故障恢复时要执行所有命令，如果命令太大，那么整个恢复过程会很缓慢。
2. 文件系统对文件大小有限制，且追加效率随文件大小增加而降低。
3. 写日志之前宕机，那么会丢失数据

混合方式： RDB文件以一定的频率执行，使用AOF文件记录两次快照之间的所有写操作。