Redis持久化机制RDB和AOF详解

Redis持久化机制
1. 持久化的原因

​ 我们都知道Redis是基于内存的非关系型数据库,内存存储既有优点也有缺点。内存中的数据读取迅速,但是一旦关闭计算机电源或故障断电,其中的数据就会丢失。这个时候,就需要使用持久化机制,将数据以文件形式保存到磁盘中,保证下一次开机能够对数据进行恢复。理解和掌握Redis的持久化机制,对Redis的日常开发和运行维护都是非常必要的。

2. 持久化的方法

​ Redis提供两种持久化机制:

  • RDB(Redis DataBase):将当前系统中的数据一快照的形式保存在磁盘上。所谓快照,可以理解为在某一时间点将数据全部拍照并保存下来。
  • AOF(Append Only File):记录每次对内存修改的操作指令序列,以日志文件形式保存到磁盘上。

在这里插入图片描述

  1. RDB持久化

    ​ 触发机制:RDB 的触发有三种机制,在客户端执行save命令和执行bgsave命令,在redis.config中配置自动化。在这三种机制中save命令会阻塞Redis的主线程(由于Redis是单线程程序,进行RDB文件保存的同时,不能处理其他命令),bgsave可以不阻塞主线程,但仍然需要在客户端执行命令。在redis.config中配置可以实现自动化,自动持久化保存rdb文件。

    ​ 优点:

    (1)RDB文件是以二进制形式保存,结构紧凑,它保存了某个时间点的数据集,适用于备份和灾难恢复。

    (2)RDB可以最大化Redis性能,fork的子线程能处理保存工作,父进程无需进行任何保存相关的磁盘IO操作。

    (3)RDB在恢复大数据集时的速度比AOF恢复的速度要快。

    在这里插入图片描述

  2. AOF持久化

    触发机制:AOF持久化有三种持久化方案,always、everysec和no。分别代表每次发生数据修改会立即记录到AOF文件并保存到磁盘中,每一秒同步一次和不进行AOF持久化方案(默认)。always方案虽然不会有丢失数据的风险,但IO开销很大,性能较差。everysec方案每秒同步一次,如果一秒内宕机,会丢失一秒内的数据。

    127.0.0.1:6379> config set appendonly yes #设置采用aof持久化机制
    OK
    127.0.0.1:6379> config set appendfsync everysec #设置aof的触发方案为everysec
    OK
    127.0.0.1:6379> config get * #查看所有Redis的所有配置
    125) "appendonly"
    126) "yes"
    127) "dir"
    128) "/"
    129) "save"
    130) "900 1 300 10 60 10000"
    131) "client-output-buffer-limit"
    132) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
    133) "unixsocketperm"
    134) "0"
    135) "slaveof"
    136) ""
    137) "notify-keyspace-events"
    138) ""
    139) "bind"
    140) "0.0.0.0"
    

    优点:

    (1)AOF 持久化的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生宕机,也最多也只会丢失掉一秒钟内的数据。

    (2)AOF 持久化后的文件是一个只进行追加操作的日志文件(append only log), 因此对 AOF 文件的写入不需要进行 seek , 即使日志因为某些原因而包含了未写入完整的命令, redis-check-aof 工具也可以轻易地修复这种问题。

    (3)Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写。

    (4)AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常易懂。

    缺点:

    (1)对于相同的数据量来说,AOF 文件的体积通常要大于 RDB 文件的体积。

    (2)根据所使用的 fsync 方案,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。

    在这里插入图片描述

3 .持久化方法的选择

​ 根据RDB和AOF的持久化机制优缺点分析,RDB持久化机制在宕机时可能导致几分钟内的数据丢失,AOF持久化保存的信息较完整。分析如下:

  • 如果数据不敏感,而且不需要保存数据,只需要程序运行中使用,可以关闭持久化机制。
  • 如果只是作为缓存,能够承受几分钟的数据丢失,可以只适用RDB持久化机制。
  • 如果是用做内存数据,要使用Redis的持久化,RDB和AOF混合使用。当两种持久化机制都开启时,会优先使用AOF恢复数据,因为AOF保存的文件比RDB文件更完整。
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值