• aof 机制
• 如何配置 AOF？aof 写回策略aof 重写机制
• redis 利用 aof 还原数据的过程
• rdb 机制（快照）触发方式如何保存和载入
• 搭建
• redis 和 mysql 对比

为什么有持久化机制背景

通过 redis 操作数据时，更多的时候是通过内存和 cpu 打交道，所以会特别快，但是内存有个缺点就是，一断电内存中的数据就没有了，那 redis 作者还是想尽可能的不丢失内存中的数据，所以 redis 也有自己的持久化机制。

aof 机制

redis 执行完命令，会将执行成功的命令写入 aof 日志，当 redis 宕机后，恢复数据可以通过 aof 日志重新执行命令即可。

如何配置 AOF？

默认情况下，Redis 是没有开启 AOF 的，可以通过配置 redis.conf 文件来开启 AOF 持久化，关于 AOF 的配置如下：

# appendonly参数开启AOF持久化 默认不开启
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 写回策略
# 每次执行命令保存一次
# appendfsync always
# 每秒保存一次
appendfsync everysec
# 由操作系统决定何时保存
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

aof 写回策略

因为 redis 写 aof 日志到磁盘具有风险：

1. 命令执行完，aof 日志还没来得及写入磁盘，宕机了，那么这个时间段内的数据不能被恢复。
2. 因为写入 aof 日志是使用主线程，如果写入磁盘数据变慢，会影响下面的命令操作。

所以开发者将 aof 日志写回磁盘的策略提取出来，方便不同场景来不同使用

• Always 同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
• Everysec 每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
• No 操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

写回策略视情况而定，如果你的系统要求数据一点也不能丢，对性能没有太高的要求 可以选择 Always,如果系统可以接受丢失一点数据，那么最好选择Everysec,No不推荐，可能会发生自己控制不了的结果。

aof 重写机制

因为 redis aof 日志不断地 append 会越来越大，影响效率；

1. 影响插入效率，命令执行的效率；
2. 使用 aof 日志恢复的消耗的时间也会变；

所以有了重写日志机制

大概逻辑：将相同键的操作，移除之前的，保留最新的一条（清除冗余命令）

aof 重写过程

一个拷贝，两处日志

1. 拷贝：主线程 fork 子进程，将主线程的内存拷贝一份（这时候只是拷贝数据结构和指针，真正开辟内存空间是在主线程执行写命令的时候）
2. 两处日志：主线程执行写操作命令时，会同时写入 aof 日志的缓存区和新的 aof 重写日志的缓存区，缓存区的数据都会刷入到各自的磁盘文件中，如果 aof 重写日志同步完后，重命名然后替换原来的 aof 文件

注意上图的不是子线程，而是子进程！

使用子进程，而不是子线程是为了减少对资源的竞争

redis 利用 aof 还原数据的过程

1. 建立无网络连接的伪客户端
2. 读取 aof 文件一条命令
3. 伪客户端执行命令
4. 重复（2,3）直到全部执行完毕

rdb 机制（快照）

RDB 是 Redis 用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。RDB 文件是一个经过压缩的二进制文件，由多个部分组成。

触发方式

手动执行命令和自动执行命令

如何保存和载入

保存命令

SAVE

save 命令会阻塞 redis 服务器进程，这时 redis 会拒绝其他命令，直到 save 命令结束

BGSAVE

bgsave 命令会 fork 一个子线程，用来执行保存 rdb 日志操作，父进程仍然可以执行命令

自动性间隔保存

redis save 策略配置

save 900 1：表示900秒（15分钟）内至少有1个key的值发生变化，则执行
save 300 10：表示300秒（5分钟）内至少有1个key的值发生变化，则执行
save 60 10000：表示60秒（1分钟）内至少有10000个key的值发生变化，则执行
save ""： 该配置将会关闭RDB方式的持久化

redis 当中会有 saveparams 数组 保存下策略，redis 会有一个定时任务（默认 100ms）去检查保存条件是否满足，满足则执行 bgsave 命令

redis 记录 rdb 快照时，如何不阻塞主线程？

一般我们拍照时，如果有人晃动了，那照片也得重新拍，所以拍照时必要保证被拍照的人静止，也就是内存中的数据不变。

redis 保存快照也是这样，先说保存快照的过程：

当进行快照记录时，主线程会 fork 出子进程，fork 会阻塞主线程，子进程和主线程此时共享一块内存空间，主线程可以继续接受命令，执行命令，子进程对内存中的数据进行日志记录，但是这就会有一个问题，子进程不能对正在修改的数据进行日志记录（如果数据一直变动，那岂不是每次记录还得校验下每块数据是否有变动，大大降低记录的效率，这感觉有点像 java 的 list 集合，遍历时不允许对集合中的数据做删除，添加操作）

你可能会想到，可以用 bgsave 避免阻塞啊。这里我就要说到一个常见的误区了，避免阻塞和正常处理写操作并不是一回事。此时，主线程的确没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。

redis 的作者利用了操作系统提供的 COW (copy on write)技术，当主线程对某一块数据进行操作（增删改）时，这时主线程会复制一份副本出来，子线程的数据地址修改为新的副本的地址，这样主线程和子进程就会不影响，既主线程可以接受命令，子进程进行日志记录啦。

载入 rdb 文件

redis 启动默认会自动载入 rdb 日志，载入时服务器会一直处于阻塞状态，直到载入完成

载入的优先级

因为一般 aof 的日志更加全面（更新频率通常比 rdb 高），所以 redis 会优先加载 aof 日志，如果开启 aof 优先使用 aof 日志还原数据库数据

aof 关闭时，会采用 rdb 文件恢复日志

bgsave 命令和 save bgsave bgrewriteaof 命令之间执行的关系

• bgsave 和 save 不能同时执行，因为 save 会阻塞服务器进程
• bgsave 和 bgsave 也不能同时进行，因为 bgsave 会 fork 出子进程，可能会有资源竞争情况
• bgsave 和 bgrewriteaof ，按道理不影响，但是出于性能考虑，不建议出现两个进程大量写操作。

搭建

docker 方式搭建 redis（版本为 7.0.5）

事先在/etc/redis/ 放 redis.conf 文件 可以在redis.conf 文件下载

启动忘记指定 redis.conf 文件 还得半天没有出现 aof 日志 因为 aof 默认是关闭的

docker run -p 6379:6379 --name myredis -v /usr/local/docker/redis/redis.conf:/etc/redis/redis.conf -v /usr/local/docker/redis/data:/data -d registory.dongshanxia.top:35000/redis:latest redis-server /etc/redis/redis.conf --appendonly yes

查看 aof 文件内容

cat appendonly.aof.1.incr.aof

查看 rdb 文件内容 打印出来的是十六进制 可以使用onlinehexeditor转换

od -A x -t x1c -v dump.rdb

redis 开启混合持久化

redis 和 mysql 对比

mysql: 在事务提交时，数据写入缓存池，redo log 文件写入磁盘才算事务结束，mysql 服务宕机时，会利用 redo log 恢复 已提交事务 但是未写入磁盘的数据。先写日志，再写磁盘

redis: aof 先执行命令，再写 aof 日志（好处就是 1.避免错误命令被记录，导致恢复数据有问题，2.不会阻塞命令执行操作）先写磁盘，再写日志

引用 《redis 设计与实现》

欢迎关注 ggball blog 公众号