Redis持久化——RDB和AOF

在运行情况下, Redis 以数据结构的形式将数据维持在内存中, 为了让这些数据在 Redis 重启之后仍然可用, Redis 分别提供了 RDB 和 AOF 两种持久化模式。


RDB

指定的时间间隔内将内存中的数据集快照写入磁盘,即snapshot,数据恢复时是将快照文件直接读到内存里。


Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。

如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。

RDB的缺点是最后一次持久化后的数据可能丢失。

关于RDB相关配置可在redis.conf(Linux下)中的SNAPSHOTTING部分进行修改

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

以上的save 900 1 等参数分别表示

900秒内执行1个写命令时,启用快照备份

300秒内执行10个写命令时,启用快照备份

60秒内执行10000个写命令时,启用快照备份


除了以上的自动备份以外,还可以使用命令进行备份,

Redis提供了两种命令进行保存,SAVE和BGSAVE

SAVE

SAVE 直接调用 rdbSave ,阻塞 Redis 主进程,直到保存完成为止。在主进程阻塞期间,服务器不能处理客户端的任何请求。


BGSAVE

fork 出一个子进程,子进程负责调用 rdbSave ,并在保存完成之后向主进程发送信号,通知保存已完成。因为 

rdbSave 在子进程被调用,所以 Redis 服务器在 BGSAVE 执行期间仍然可以继续处理客户端的请求。


此外执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义。

还可以通过配置dbfilename,修改rdb文件名称,默认为dump.rdb


AOF

以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。


同步命令到 AOF 文件的整个过程可以分为三个阶段:

  1. 命令传播:Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
  2. 缓存追加:AOF 程序根据接收到的命令数据,将命令转换为网络通讯协议的格式,然后将协议内容追加到服务器的 AOF 缓存中。
  3. 文件写入和保存:AOF 缓存中的内容被写入到 AOF 文件末尾,如果设定的 AOF 保存条件被满足的话, fsync 函数或者 fdatasync 函数会被调用,将写入的内容真正地保存到磁盘中。

默认情况下AOF的备份方式是没有开启的,需要修改redis.conf文件中的appendonly no修改为appendonly yes

生成的文件默认为配置appendfilename "appendonly.aof"中的appendonly.aof,在Redis重新启动后会重新加载。

当遇到aof文件被损坏时(如:aof文件中包含错误指令等),可以使用redis-check-aof --fix进行修复。

rewrite

AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof


AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),
遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

重写的触发条件同样在redis.conf文件中存在配置

auto-aof-rewrite-percentage 100 表示与上次重写的AOF文件大小相比,当前文件增长量超过上次AOF文件大小的100%时,触发重写

auto-aof-rewrite-min-size 64mb 指定触发重写的AOF文件大小,若AOF文件小于该值,即使满足auto-aof-rewrite-percentage 100 条件,也不会触发自动重写。

两个条件同时满足才重写

通过修改以上两个配置,可以改变触发重写的条件


对比总结

RDB

优势:  1.适合大规模的数据恢复
            2.对数据完整性和一致性要求不高

            

劣势: 1.在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改

            2.fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑

AOF

优势:每修改同步:appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘,性能较差但数据完整性比较好

每秒同步:appendfsync everysec    异步操作,每秒记录   如果一秒内宕机,有数据丢失
不同步:appendfsync no   从不同步

            

劣势: 1.aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

            2.相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值