Redis 持久化机制

简述

Redis 持久化机制有三种：

1. RDB，快照的方式

2. AOF 只追加文件的方式

3. 二者结合（4.0之后新增）

RDB（快照）

第一种是 RDB，通过创建快照的方式创建数据某个时间段的副本，可以用来主从复制，也可以用来恢复数据。根据默认配置，RDB 触发的条件是在某个时间段内，发生一定数量的 key 的变化，就会触发 RDB 持久化。

RDB 执行持久化方式有两种：

1. save 方法，同步执行，会阻塞主线程

2. bgsave 方法，当执行持久化时，执行 fork 操作，创建一个子线程，使用子线程执行持久化，主线程可响应其他操作。

AOF（只追加文件）

第二种 AOF 只追加文件的方式，当执行命令时，Redis 会将这条命令写入到 AOF 缓存区中，然后写入到 AOF 文件中，最后根据持久化策略同步到磁盘中。

持久化流程

1. 追加命令 append。所有的命令会写入到 AOF 缓冲区。

2. 文件写入 write。将 AOF 缓冲区的命令写到 AOF 文件中，此时文件并没有同步到磁盘中，根据之后的持久化机制来同步文件到磁盘中。

3. 文件同步 fsync。根据持久化方式将 AOF 文件同步到磁盘中。

4. 文件重写。随着持续的写入，文件会越来越大，所以需要对 AOF 文件进行重写。

5. 重启加载。当 Redis 重启时，可以加载 AOF 文件数据恢复。

持久化方式（刷盘时机）

1. Always。主线程调用 write 执行写操作之后，立刻将文件同步到磁盘。会影响性能。

2. everysec。执行 write 之后，由后台线程每秒钟同步文件。

3. no。主线程执行 write 操作之后立刻返回。操作系统自己决定同步时机。

AOF 重写

当文件过大时，需要进行 AOF 文件重写，压缩空间。Redis 会开启一个子线程进行 AOF 文件重写。同时，还会维护一个 AOF 重写缓冲区，当 AOF 文件重写期间执行的所以命令都记录在内，直到重写完毕后会将这些记录接着写在新的 AOF 文件中，使得新的文件和数据库中数据保持一致。最后用新的 AOF 文件替换掉旧得 AOF 文件即可。

数据恢复流程

1. 数据恢复，首先检查是否存在 AOF 文件，主要使用检验 校验和  的方式来检查 AOF 文件是否完整，是否有数据丢失。校验和就是当文件修改时会计算一个数字，文件一改，校验和也会改。

2. AOF 不存在，检查是否存在 RDB ，使用 RDB 进行数据恢复

3. 都不存在，恢复失败。

两种方法的比较

1. 文件大小

RDB 是二进制快照形式的文件，占用空间较小，AOF 存储的是命令记录，文件较大，所有需要定期执行AOF 文件重写，用以压缩文件大小。

2. 文件恢复

RDB 记录的是快照形式的数据集，恢复数据时，通过解析数据集来获取到数据，在大数据量时优势明显。AOF 文件记录的时命令，需要执行一条条命令来进行数据恢复，速度较慢。

3. 安全性

AOF 文件因为会记录每一个命令，安全性比较好，RDB 可能出现丢失最后一次快照之后的所有修改。AOF 因为要定期执行文件重写，写入负载会比较大。

具体使用根据实际情况而定，大数据量的情况适合 RDB，安全性适合 AOF。

有错误烦请指出。