Redis持久化的运行机制和优缺点是什么

共计 3605 个字符，预计需要花费 10 分钟才能阅读完成。

Redis 持久化的运行机制和优缺点是什么，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

前言

大家都知道 Redis 一个内存数据库, 它支持 2 种持久化方式：RDB(Snapshot 内存快照)，AOF(append only file)。持久化功能将内存中的数据同步到磁盘来避免 Redis 发生异常导致数据丢失的情况。当 Redis 实例重启时，即可利用之前持久化的文件实现数据恢复。

接下来，丸趣 TV 小编介绍两种持久化的运行机制和优缺点。

一 RDB

RDB 是默认的持久化方式，按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。

每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘 io 操作，可能会严重影响性能。

1.1 快照持久化过程

1.2 触发机制

1. save 命令

当客户端向 Redis server 发送 save 命令请求进行持久化时，由于 Redis 是用一个主线程来处理所有,save 命令会阻塞 Redis server 处理其他客户端的请求，直到数据同步完成。

2. bgsave 命令

与 save 命令不同，bgsave 是异步执行的，当执行 bgsave 命令之后，Redis 主进程会 fork 一个子进程将数据保存到 rdb 文件中，同步完数据之后，对原有文件进行替换，然后通知主进程表示同步完成。

3. 自动触发

除了手动触发 RDB 持久化，Redis 内部还存在自动触发机制，

在配置中集中配置 save m n 的方式，表示 m 秒内数据集存在 n 次修改时，系统自动触发 bgsave 操作。 

# 900s 内至少达到一条写命令  save 900 1 # 300s 内至少达至 10 条写命令  save 300 10 # 60s 内至少达到 10000 条写命令  save 60 10000

从节点执行全量复制操作，主节点自动执行 bgsave 生成 RDB 文件并发送给从节点

默认情况下执行 shutdown 命令时，如果没有开启 AOF 持久化功能，系统会自动执行 bgsave 命令。执行 debug reload 命令重新加载 Redis 时，也会自动触发 save 操作。

1.3 相关参数  

#  持久化  rdb 文件遇到问题时，主进程是否接受写入，yes  表示停止写入，如果是 no  表示 redis 继续提供服务。 stop-writes-on-bgsave-error yes #  在进行快照镜像时, 是否进行压缩。yes: 压缩，但是需要一些 cpu 的消耗。no: 不压缩，需要更多的磁盘空间。 rdbcompression yes #  一个 CRC64 的校验就被放在了文件末尾，当存储或者加载 rbd 文件的时候会有一个 10% 左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。 rdbchecksum yes #  快照的文件名  dbfilename dump.rdb #  存放快照的目录  dir /var/lib/redis

1.4 RDB 的优缺点

优点

RDB 文件小，非常适合定时备份，用于灾难恢复。

因为 RDB 文件中直接存储的是内存数据，而 AOF 文件中存储的是一条条命令，需要应用命令。Redis 加载 RDB 文件的速度比 AOF 快很多。

缺点

RDB 持久化方式不能做到实时 / 秒级持久化。实时持久化要全量刷内存到磁盘，成本太高。每秒 fork 子进程也会阻塞主进程，影响性能。

RDB 文件是二进制文件，随着 Redis 不断迭代有多个 rdb 文件的版本，不支持跨版本兼容。老的 Redis 无法识别新的 RDB 文件格式。

二 AOF

AOF(Append-only file) 针对 RDB 的缺点做了优化，在使用 AOF 持久化方式时，Redis 会将每一个收到的写操作命令都通过 Write 函数追加到文件最后，类似于 MySQL 的 binlog。当 Redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

2.1 AOF 持久化过程

1. 客户端发出 bgrewriteaof 命令。

2. redis 主进程 fork 子进程。

3. 父进程继续处理 client 请求，除了把写命令写入到原来的 aof 文件中。同时把收到的写命令缓存到 AOF 重写缓冲区。这样就能保证如果子进程重写失败的话并不会出问题。

4. 子进程根据内存快照，按照命令合并规则写入到新 AOF 文件中。

5. 当子进程把内存快照写入临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。

6. 现在父进程可以使用临时文件替换老的 aof 文件，并重命名，后面收到的写命令也开始往新的 aof 文件中追加。

2.2 相关参数  

#  是否开启 AOF，默认关闭  appendonly yes #  指定  AOF  文件名  appendfilename appendonly.aof # Redis 支持三种刷写模式： # appendfsync always #每次收到写命令就立即强制写入磁盘，类似 MySQL 的 sync_binlog=1, 是最安全的。但该模式下速度也是最慢的，一般不推荐使用。 appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。 # appendfsync no #完全依赖 OS 的写入，一般为 30 秒左右一次，性能最好但是持久化最没有保证，不推荐。 #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成 DISK IO 上的冲突。 #设置为 yes 表示 rewrite 期间对新写操作不 fsync, 暂时存在内存中, 等 rewrite 完成后再写入，默认为 no，建议 yes no-appendfsync-on-rewrite yes #当前 AOF 文件大小是上次日志重写得到 AOF 文件大小的二倍时，自动启动新的日志重写过程。 auto-aof-rewrite-percentage 100 # 当前 AOF 文件启动新的日志重写过程的最小值，避免刚刚启动 Reids 时由于文件尺寸较小导致频繁的重写。 auto-aof-rewrite-min-size 64mb

2.3 日志重写

AOF 机制将客户端的每一个写操作都追加到 aof 文件末尾，比如将一个 key 多次执行 incr,set 命令, 会写入多次命令到 aof 文件，aof 文件会越来越大，部分核心业务每天的写入量有几十 G 的大小。 

incr k1 1 set k2 a set k2 b incr k1 2 incr k1 3 set k2 c del k3 ... incr k1 100

恢复 Redis 实例时，加载非常大的 aof 文件耗时会很长。为了解决这个问题，Redis 支持 aof 文件重写 – 把 Redis 进程内的数据转化为写命令同步到新 AOF 文件中的过程。通过重写，可以生成一个最小的命令集合。比如上面的几个命令可以合并为

incr k1 100 set k2 c

写入数据的规则

1. 进程内过期的数据不用在写入

2. 旧 AOF 文件含有的无效命令 del k1, set a 1, set a 2。重写使用进程内的数据直接生成，aof 文件就保留最新的命令集合。

3. 多条命令可以合并为一个命令，为了防止单个命令过大造成客户端缓冲区溢出，对于 list,set,hash,zset 等类型的操作，以 64 个元素为界拆分为多条。

触发机制

1. 手动触发 执行 bgrewriteaof 命令。

2. 根据配置自动触发

auto-aof-rewrite-min-size 表示运行 AOF 重写是文件最小的大小。默认 64M，小于 64M 就会不自动重写了。

auto-aof-rewrite-percentage 表示（aof_current_size- aof_base_size）/ aof_base_size 的比值。

aof 文件重写之后当前文件大小增长多少就触发重写

自动触发时机 :

aof_current_size auto-aof-rewrite-min-size

(aof_current_size – aof_base_size) /  aof_base_size = auto-aof-rewrite-percentage

三 RDB VS AOF 对比

具体使用哪种持久化方式，下面是来自官方的建议：

通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用 RDB。很多用户仅使用了 AOF，但是我们建议，既然 RDB 可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用 RDB。

生产上的实例大多不会是单点，而是主从，也有利用 slave 作为持久化方式，同时满足 HA 的需求。读者朋友可以分享一下各自遇到的和 redis 持久化相关的问题。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。