Redis 两类持久化方式,快照和全量追加日志的不同处理方式
redis 如同其他的存储组件一样,提供了两类持久化方式:快照,和全量追加日志。
rdb - 快照
在默认情况下, redis 将数据库快照保存在名字为dump.rdb
的二进制文件中。
你可以对 redis 进行设置, 让它在“ n 秒内数据集至少有 m 个改动”这一条件被满足时, 自动保存一次数据集。
你也可以通过调用 save
或者 bgsave
, 手动让 redis 进行数据集保存操作。
这种持久化方式被称为快照 snapshotting
.
-
save
:暂停服务,写dump.rdb,比如停止时执行 -
bgsave
:通过fork
系统调用创建子进程写 dump.rdb
# 配置写入策略(针对bgsave): save 900 1 #(900秒内至少1个key被写) save 300 10 #(300秒内至少10个key被写) save 60 10000 #(60秒内至少1000个key被写) # 如果不需要rdb,可以设置: save "" # 设置 rdb 文件名称 和 存储目录 dbfilename dump.rdb dir /var/lib/redis/6379
aof - 只追加操作的文件(append-only file,aof)
快照功能并不是非常耐久(durable): 如果 redis 因为某些原因而造成故障停机, 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
从 1.1 版本开始, redis 增加了一种完全耐久的持久化方式: aof 持久化。
appendonly yes #(开启aof) appendfilename "appendonly.aof"
每当 redis 执行一个改变数据集的命令时(比如 set), 这个命令就会被追加到 aof 文件的末尾。
这样的话, 当 redis 重新启时, 程序就可以通过重新执行 aof 文件中的命令来达到重建数据集的目的。
fsync 同步刷盘策略
你可以配置 redis 多久才将数据 fsync 到磁盘一次。有三种方式:
- 每次有新命令追加到 aof 文件时就执行一次 fsync :非常慢,也非常安全
- 每秒 fsync 一次:足够快(和使用 rdb 持久化差不多),并且在故障时只会丢失 1 秒钟的数据。
- 从不 fsync :将数据交给操作系统来处理。更快,也更不安全的选择。
- 推荐(并且也是默认)的措施为每秒 fsync 一次, 这种 fsync 策略可以兼顾速度和安全性。
# fsync同步刷盘策略 # appendfsync always #(立刻同步刷盘,最慢,也最安全) appendfsync everysec #(每秒才触发一次同步刷盘,推荐) # appendfsync no # (不采用同步刷盘,最快,相对不安全)
日志重写
因为 aof 的运作方式是不断地将命令追加到文件的末尾, 所以随着写入命令的不断增加, aof 文件的体积也会变得越来越大。
举个例子, 如果你对一个计数器调用了 100 次 incr , 那么仅仅是为了保存这个计数器的当前值, aof 文件就需要使用 100 条记录(entry)。
然而在实际上, 只使用一条 set 命令已经足以保存计数器的当前值了, 其余 99 条记录实际上都是多余的。
为了处理这种情况, redis 支持一种有趣的特性: 可以在不打断服务客户端的情况下, 对 aof 文件进行重建(rebuild)。
执行 bgrewriteaof
命令, redis 将生成一个新的 aof 文件, 这个文件包含重建当前数据集所需的最少命令。
# 配置:aof文件每次增长指定大小的百分比后,就会触发bgrewriteaof auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
从 redis 4.0 开始,aof重写逻辑变动了:
-
老数据采用 rdb 的
fork
写入 aof文件的头部 -
以后增量的命令追加到aof文件尾部
这样的方式,aof是一个混合体,利用了rdb的快,利用了日志的全量,使得 redis 持久化更加安全和完善。
上一篇: Redis 字符串 SDS
下一篇: mysql 存储引擎