聊聊 Redis 数据持久化备份

缓存应用在服务中我们经常都会使用的，其中尤其是 Redis，今天给大家聊聊 Redis 的数据持久化。

Redis 持久化主要有两种方式，一种是 RDB，一种是 AOF。

其中 RDB （ Redis DataBase ）持久化是以快照（ snapshotting ）方式进行，把存在某一时刻的所有数据写入硬盘过程。

AOF （ append-only file ）是以追加文件方式持久化，它以日志文件的方式记录每次的写命令，在服务重启再重新执行 AOF 文件命令来恢复数据。

这两种数据备份方式即可以同时使用，又可以单独使用。

RDB 快照持久化

首先我们看下 RDB 快照方式，这种持久化方式主要分为手动触发和被动触发。

手动触发分为 SAVE 和 BGSAVE，由于 SAVE 会阻塞 Redis 服务，直到 RDB 过程完成，所以生产环境我们主要使用 BGSAVE 操作，执行 BGSAVE 之后，Redis 进程会执行 fork 子进程，让子进程负责，直到自动结束。

被动触发是由于我们配置文件进行了 save 配置选项，如果用户设置了多个配置 save 配置选项那么任何一个条件满足就会触发 BGSAVE。

我们可以看下下面的一段配置：

1. save 60 10000 # 60s 有 10000 次写入（修改）被动触发 BGSAVE
2. save 900 10  # 900s 有 10 次就触发 BGSAVE，保存到硬盘（两个满足一个就触发）
3. stop-writes-on-bgsave-error no # 创建快照失败是否继续写命令
4. rdbcompression yes # 是否进行压缩（默认压缩）
5. dbfilename dump.rdb # 生成文件名

其中 save 的配置需要我们进行合理评估，过频繁会浪费资源，过于稀少可能会有丢失大量数据隐患。

在这里我们需要知道通过快照持久化的方式来保存数据，如果服务发生故障，用户将会丢失最近一次生成快照之后更改的所有数据。

当然如果缓存数据小于或者只有几个 GB 时候，使用快照进行保存数据没有啥问题的。

AOF 追加持久化

由于 RDB 快照持久化适合小规模或丢失一部分数据也不会造成问题的应用，但是大多数场景里面，我们需要尽量保证数据完整性，所以这里我们有了 AOF 这种方式。

AOF 持久化会将执行的命令写到 AOF 文件的末尾，来记录数据发生的变化，所以只需要将 AOF 的文件命令在 Redis 重新执行一遍就能恢复 AOF 文件的数据。

但是 AOF 文件会随着命令的不断增加，文件会越来越大，所以 Redis 有了重写机制，通过重写机制来压缩控制文件大小。

重写机制的原理就是合并多个命令，比如同样 inc 操作了 100 次，那么就可以合并为 1 次进行，或者之前添加了某个数据，后面又删除了就可以删除之前无效的命令等等。

AOF 重写这种方式和 RDB 触发同样分为手动触发和被动触发。

手动触发方式：bgrewriteaof 被动触发方式：auto-aof-rewrite-percentage, auto-aof-rewrite-min-sieze

我们可以看下下面的配置：

appendonly no  # 是否进行 aof 持久化
appendfsync everysec # 每秒同步一次，有 always，no 选项
no-appendfsync-on-rewrite no # aof 重写期间是否同步
auto-aof-rewrite-percentage 100 # 当前文件是上一次大小的两倍的时候触发重写
auto-aof-rewrie-min-size 64mb # 文件最小体积触发重写

AOF 重写和 RDB 快照方式一样，都会创建子进程，然后 AOF 子进程进行文件重写，所以快照持久化因为创建子进程导致性能和内存问题在 AOF 一样存在。

通过 AOF 的方式能相对更完善保留数据，让我们更为放心。

在这儿我们需要知道服务重启之后 Redis 默认加载流程，优先加载 AOF 文件，如果没有再考虑加载 RDB 文件。

最后

我们来简单总结一下 RDB 和 AOF 优缺点：

RDB 优点：压缩二进制适合备份，加载恢复数据比 AOF 快 RDB 缺点：没法做到实时持久化，频繁操作消耗资源

AOF 优点：通过追加命令可以实时持久化 AOF 缺点：加载恢复数据慢

有了这两种持久化方式，我们服务在重启或者宕机的时候就能更加完整保留数据，除了进行持久化操作外，我们也应该尽量把数据文件备份到不同服务器，避免在出现严重问题的时候不会丢失数据。

原文: 聊聊 Redis 数据持久化备份 | sitin's blog