2.Redis持久化

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程推出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

一、RDB

1.1 触发机制

• save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
• bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

1.2 流程说明

bgsave是主流的触发RDB持久化方式，下面根据图5-1了解它的运行流程。

1. 执行bgsave命令，Redis父进程判断当前是否存在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。（意味着同时只能存在一个RDB的子进程）。
2. 父进程执行fork操作创建子进程， fork操作过程中父进程会阻塞。
3. 父进程fork完成后，可以继续响应其他命令。
4. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。
5. 子进程发送信号给父进程表示完成，父进程更新统计信息。

1.3 RDB的优缺点

优点：

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。
• Redis加载RDB恢复数据远远快于AOF的方式。

缺点：

• RDB没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。？？？？？？？？？？？？？是因为fork，而不是全量复制吗？？？？

  针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

二、AOF

AOF持久化：以独立日志的方式记录每次写命令，重启时再次再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

2.1 AOF整体流程

AOF整体的工作流程：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load），如图5-2所示。

流程如下：

1. **所有的写入命令会追加到aof_buf（缓冲区）**中。
2. AOF缓冲区根据对应的策略向硬盘做同步操作。
3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

2.2 文件同步

Redis提供了多种AOF缓冲区同步文件策略：

• always：每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置。
• no：同步硬盘操作由操作系统负责，通常同步周期最长是30秒，数据安全性无法保证。
• everysec：每秒同步一次，是建议的同步策略，也是默认配置，能做到兼顾性能和数据安全性。

2.3 重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制来压缩文件体积。

重写之后的AOF文件为什么可以变小？有如下原因：

1. 进程内已经超时的数据不再写入文件。
2. 旧的OF文件有无效命令，如del key1、srem keys、set a 111、set a 222等。重写新的AOF只保留最终数据的写入命令即可。
3. 多条写入命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为lpush list a b c。

2.4 重启加载

AOF和RDB文件都可以用于服务器重启时的数据恢复。如下图所示

流程如下：

1. 如果开启了AOF持久化并且存在AOF文件时，优先加载AOF文件。
2. AOF关闭或者AOF文件不存在时，加载RDB文件
3. 加载AOF/RDB文件成功后，Redis启动成功
4. AOF/RDB存在错误时，Redis启动失败并打印错误信息。