redis 持久化

redis 持久化（RDB 和 AOF）

为什么要持久化：redis 宕机之后数据恢复

RDM（Redis DataBase）redis 默认方式

RDB 的触发方式：

• 根据配置的规则定时触发

• 执行 save 或者时 bgsave 命令

• 执行 flushall 命令

• 执行主从复制时第一次

1. redis 父进程首先判断是否有正在执行 save 或者 bgsave 、bgrewriteaof（aof 重写命令），如果有正在执行的则之间放回 bgsave 命令

2. 父进程执行 fork 命令（调用操作系统的 fork 命令复制主进程），执行 fork 时主线程阻塞，不执行客户端的任何命令

3. 父进程执行复制了之后返回 bgsave 命令（BackGround saveng start）就继续工作，不阻塞，子进程则生成 RDB 文件，并且对原有文件进程原子替换。

4. 复制完成后给父进程回复，父进程进行更新信息

RDB 优缺点：

优点：1、rdb 文件位压缩文件，比较小；2、fork 子进程进行生成文件，性能比较好。

缺点：会丢失数据（在下一次复制前 redis 宕机，会丢失部分数据）

AOF(append only file)

触发方式（三种配置）

• AOF_FSYNC_NO 不保存，每次调用 flushAppendOnlyFile 函数， 都只执行 write（只写内存 aof_buf），不执行 save（调用 fsync 或 fdatasync 函数 ，存入磁盘），但是在 redis 关闭或者时关闭 aof 功能时会执行 save，此时会阻塞主进程

• AOF_FSYNC_EVERYSEC 每秒保存一次每隔一秒钟执行一次，write 与 save 都会执行，主进程 fork 子进程进行，不阻塞主进程。

• AOF_FSYNC_ALWAYS l 每次执行命令都执行 write 与 save，阻塞主进程。

执行流程：

1.命令传播 -> redis 将执行的命令以及参数等信息发送到 aof 程序中。

2.缓存追加-> aof 程序根据收到的命令数据，将命令转换位网络通讯协议的格式，然后将协议内容追加到服务器的 aof 缓冲区；

3.文件写入与保存：aof 把缓存中的内容写入到文件末尾，如果设定的 aof 保存条件满足时，则执行 fsync 函数或者时 fdatasync 函数，写入磁盘中；

文件保存与写入：

write ：根据条件将 aof_buf 中的缓存写入到 aof 文件中；

save：根据条件调用 sfync 或者时 fdatasync 函数，将 aof 文件写入到磁盘中；

优缺点：

优点：不丢失数据；

缺点：冗余数据多，文件会很大，恢复比较慢，redis 性能有影响。

AOF 重写：

当 aof 文件经过长时间的追加后会变的越来越大，有很多过期的或者时重复无用的命令，所以需要整理当前的有效的命令，也不能说时重写 aof 因为，这时写的文件是根据数据库中的键值来写一份新的 aof 文件；

触发条件--> 1、根据 conf 中的配置，当达到配置的大小时重写；2、bgrewriteaof 命令

redis 为了在重写期间继续对外服务，所以会 fork 一个子进程来进行在后台执行，这样的好处：

1、子进程在处理 aof 重写期间，主进程是可以继续对外提供服务；2、子进程带有主进程的数据副本，可以避免锁的情况下数据安全。

待解决问题：子进程字重写 aof 的期间，主进程进行处理的命令可能对现有数据有修改，这就会导致新的 aof 文件会与数据库不一致的情况：

解决方法：引入了 aof 写入缓存，在 fork 子进程时会开启一个缓存，主进程在处理命令时会追加在原有的 aof 文件，并且往缓存中写如一份，等子进程重写 aof 文件完成时会通知主进程，主进程把缓存中的文件追加到新 aof 文件，然后修改新 aof 文件名，替换原有的 aof 文件，因为在重写 aof 期间往久的文件也会追加命令，所以就算重写期间宕机，数据也不会丢失。

混合持久化：

rdb 与 aof 各有特点，redis4.0 开始支持混合持久化，把混合持久化配置打开时，aof 在 rewrite 的时候就会把 rdb 的内容写入到 aof 文件开头。