持久化即将数据保存到可永久保存的存储设备中。我们知道 Redis 为了保证效率而把数据都缓存在内存中,但当我们重启系统或关闭系统后,缓存在内存中的数据都会消失,所以为了让有些数据能保留下,Redis 持久化存储就应运而生。Redis 提供了两种方式进行持久化,一种是RDB 持久化,另一种是 AOF(append only file) 持久化,下面我们逐一介绍。
RDB 是 Redis 默认的持久化机制,它的工作原理是把当前内存中的数据生成快照 (snapshot) 的方式写入磁盘中的二进制文件中,默认的文件名为 dump.rdb。恢复时将快照文件直接读到内存中。RDB 有两种触发方式,分别是自动触发和手动触发。
自动触发使用 save 相关配置触发,比如 “save m n”,表示在 m 秒内数据库存在 n 次修改时,自动触发BGSAVE (BGSAVE 命令在手动触发时会介绍)。Redis 默认配置如下:
save 900 1 # 在 900 秒内如果至少有 1 个 key 的值变化,则触发
save 300 10 # 在 300 秒内如果至少有 10 个 key 的值变化,则触发
save 60 10000 # 在 60 秒内如果至少有 10000 个 key 的值变化,则触发
当实际操作满足配置的 save 形式时就会进行 RDB 持久化,将当前的数据快照保存。
手动触发进行 RDB 持久化涉及到两个 Redis 服务器命令:
SAVE 命令由于是同步操作,因此会阻塞当前 Redis 服务器知道 RDB 持久化过程完成为止,对于内存比较大的实例会造成长时间阻塞,不建议在线上环境使用。BGSAVE 命令会执行 fork 操作创建一个子进程,由子进程完成 RDB 持久化过程,完成后自动结束,阻塞只发生在 fork 过程,一般时间很短。基本上 Redis 内部的 RDB 操作都是采用 BGSAVE 命令。
RDB 的优点:
RDB 的缺点:
差别于通过保存数据库中的键值对的 RDB 持久化方式,AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态,重启时再重新执行 AOF 文件中的命令以完成数据恢复。AOF 的主要作用是解决了数据持久化的实时性,目前已经是 Redis 持久化的主流方式。
Redis 中 AOF 是默认关闭的,使用前要将配置参数 appendonly 改为 yes(5.3 中会涉及一些配置参数,配置文件是安装目录下的 redis.windows.conf,参数在 APPEND ONLY FILE 一栏)。AOF 文件的保存文件名通过参数 appendfilename 参数配置,默认是 appendonly.aof。AOF 持久化策略的选择由 appendfsync 参数进行选择,有下面几种:
AOF 的工作流程操作:命令写入 (append)、文件同步 (sync)、文件重写 (rewrite)、重启加载 (load)。首先,所有的写入命令都会被追加到 AOF 缓冲区中,然后 AOF 缓冲区根据对应的持久化策略对磁盘进行文件同步操作。当 AOF 文件的大小超过所设定的重写阈值时对 AOF 文件进行重写。当需要重写时,父进程会进行 fork 操作创建一个子进程,子进程带有父进程的数据副本,由子进程完成重写过程,在此期间父进程仍然可以处理其他命令。当我们重启 Redis 服务器时,可以加载 AOF 文件进行数据恢复,流程如下:
持久化
从上图我们也可以得知,在同时开启了 RDB 和 AOF 的情况下,Redis 会优先 AOF 文件的加载。遇到异常时,可以使用修复命令 redis-check-aof--fix 进行修复。在上述流程中,我们有几点需要注意与知晓的:
AOF 的优点:
AOF 的缺点:
介绍了 Redis 持久化的两种方式,那么我们在实际中应该如何选择呢?对于数据库而言,数据是相当重要的,RDB 相比于 AOF 而言出现异常丢失数据可能会更严重,除此之外,选择 RDB 是更好的,定时生成快照是常用的数据库备份方式,并且 RDB 文件是二进制文件,在恢复数据集时速度更快,使用 RDB 方式也可以规避 AOF 方式中的一些隐藏 bug。但是在一般情况下,我们应该同时开启两种持久化方式,而不是单独使用某一种持久化机制。由于通常情况下 AOF 方式保存的数据更具实时性且更完整,因此相比 RDB 文件,Redis 重启时会优先使用 AOF 文件来恢复数据。