持久化机制

尽管 Redis 是基于内存的 key-value 服务，但也可以进行数据的持久化，以便服务重启，数据能重新加载进来。

为了尽可能的保证数据不丢失，Redis 为我们提供了好几种持久化机制：

• RDB：即 Redis Database，在指定的时间间隔里将 Redis 内存数据镜像下来，保存到文件里。
• AOF：将服务器对数据的写操作追加到文件里，相当于将所有的逻辑操作都记录了下来。
• 无持久性：不进行持久化，性能最好。
• RDB + AOF：将 RDB 和 AOF 结合起来，组合它们各自的优点。

下面，我们来看看这些机制吧。

RDB 配置

在 redis.conf 文件里我们可以针对 RDB 持久化方式进行设置：

### 快照设置  ###


# save ""  空表示不进行持久化
save 900 1  # 900 秒内如果有1个 key 值改变，则进行持久化动作
save 300 10 # 300 秒内如果有10个 key 值改变，则进行持久化动作
save 60 10000 # 60 秒内如果有10000个 key 值改变，则进行持久化动作

# 如果持久化失败，则 Redis 不会再进行数据更新操作，直到恢复正常
stop-writes-on-bgsave-error yes

# 是否对持久化的 rdb 文件进行压缩保存
rdbcompression yes

# 是否对持久化的 rdb 文件进行校验
rdbchecksum yes

# 要持久化的 rdb 文件名
dbfilename example.rdb

# 导出目录
dir /opt/redisdata

RDB 优势

• 当 Redis 进行持久化动作时，它会先 fork 一个子进程，将数据的写入交给子进程，而父进程不会涉及到磁盘的 IO 操作，所以 RDB 的性能非常好。

• 如果是在 Unix 系统上，还能充分利用写时复制机制。也就是子进程和父进程共用相同的内存页面，只有当子进程或父进程进行修改才会进行复制。这样节省了对物理内存的使用。

• 由于 RDB 文件只存储了某个时刻的内存数据，并没有什么逻辑命令，所以在进行重启恢复时，能很快的加载进来。

RDB 缺点

• 虽然 RDB 的 fork 能使得 Redis 的持久化独立进行，但是一旦数据量比较大的，就会一直占用 CPU，可能会影响到父进程的进行。

• 前面的 RDB 配置里我们提到是按一定的时间间隔内去触发持久化的，但也正是因为这个时间间隔原因，导致我们将会有一定概率在这段时间内丢失数据。

AOF 配置

同样的，我们可以在 redis.conf 文件里对 AOF 持久化进行配置：

appendonly no # 是否开启 aof
appendfilename "appendonly.aof" # aof 文件名

# 同步到磁盘的策略 默认每秒一次

# appendfsync always  # 每次
appendfsync everysec # 每秒一次
# appendfsync no # 由操作系统执行，默认Linux配置最多丢失30秒

auto-aof-rewrite-percentage 100 # aof 文件超过比例则进行重写

auto-aof-rewrite-min-size 64mb # aof 文件超过多少则进行重写

aof-load-truncated yes # 如果 aof 最后的指令有误，则在重新恢复时忽略。

在上面的配置中，我们看到有关 aof 文件重写的配置。之所以需要对 aof 进行重写，是因为 aof 文件记录的是逻辑操作。随着系统运行越久，操作命令将越来越多，日志文件也就越来越大了，所以需要对其进行重写，以减少磁盘空间。

当 AOF 进行文件重写时，会将内存数据重新整理一遍，然后保存到新文件里，接着再将新文件替换原来的 AOF 文件。

AOF 优势

• AOF 让我们可以以每秒的速度进行持久化，这样的话可以很大程度的减少数据的丢失。
• AOF 采用追加的方式进行写文件，这样即使持久化失败，影响较少，而且能够使用 redis-check-aof 进行修复。

AOF 缺点

• 前面提到过日志会越来越大，需要靠重写来减少对磁盘的占用。

混合持久化

为了能将 AOF 和 RDB 的优势结合起来， Redis 在 4.0 之后启用了混合持久化，它的配置如下：

aof-use-rdb-preamble yes

当开启了混合持久化后，Redis 会 fork 子进程将内存数据以 RDB 格式写入 AOF 文件，后面会将重写缓冲区的增量命令以 AOF 方式写入到文件。这样的话，新的 AOF 文件就同时拥有了 2 种格式的数据。

当需要使用混合文件进行恢复时，会先判断 AOF 文件的头部是否为 RDB 格式，是的话，先使用 RDB 的方式加载数据，接着再处理后面的 AOF 数据。

这样的话就能加快数据的恢复速度，又降低了数据丢失的风险。

当然， 这种混合方式会使得 AOF 文件变得复杂，可读性差，而且得是 4.0 版本以上才能使用。

总结

Redis 的持久化都有它的特点，那我们应该选择哪种机制呢？

• 如果我们的数据允许丢失，那应该关闭持久化方式，这样性能会很好。
• 如果我们希望能尽量的保证数据的安全性，那我们应该选择混合持久化方式。
• 如果我们希望保证数据不丢失，那应该选择 appendfsync 为 always，只是这种对性能影响很大，所以一般都会直接考虑 mysql 了。

---

感兴趣的朋友可以搜一搜公众号「 阅新技术 」，关注更多的推送文章。
可以的话，就顺便点个赞、留个言、分享下，感谢各位支持！
阅新技术，阅读更多的新知识。