zoukankan      html  css  js  c++  java
  • redis持久化

    两种持久化方案RDB AOF

    1.RDB持久化

    可以在指定的时间间隔内生成数据集的时间点快照
    优点:速度快、适合于用做备份。主从复制也是基于RDB持久化功能实现的
    缺点:会有数据丢失
    rdb持久化核心配置参数:
    vim /data/6379/redis.conf
    dir /data/6379
    dbfilenam dump.rdb
    save 900 1
    save 300 10
    save 60 10000

    配置分别表示:
      900秒内有1个更改
      300秒内有10个更改
      60秒内有10000个更改
      就自动进行保存。具体怎么设置,看自己的应用场景需求。

    手动保存rdb文件命令:save
    RDB持久化机制工作流程
    (1)redis根据配置自己尝试生成一个rdb快照文件
    (2)fork一个子进程进来,子进程进来将数据dum到快照文件中
    (3)完成新的rdb快照文件之后,就替换之前旧的快照文件
    Redis RDB持久化机制会阻塞主进程,这样主进程就无法响应客户端请求
    redis自4.0版本以后支持rdb增量复制。
    恢复数据:将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

    2.AOF持久化

    记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些明利来还原数据集
    AOF文件中的命令全部以redis协议的格式来保存,新命令会被追加到文件的末尾
    优点:可以最大程度保证数据不丢
    缺点:日志记录量级比较大
    AOF持久化配置(要添加到配置文件)
    appendonly yes
    #下面三个任选一个 #是否打开aof日志功能
    appendfsync always #每次修改都立即记录
    appendfsync everysec #每秒记录一次日志。一般来说写这个选项
    appendfsync no #写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof

    vim /data/6379/redis.conf
    appendonly yes
    appendfsync everysec

    两种持久化功能是不冲突的,可以一起用。具体用哪种,看业务场景需求。
    RDB和AOF一起用的情况很少。

    3.二者优缺点

    RDB的优点
    1). 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数 据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。
    2). 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
    3). 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
    4). 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。
    RDB的缺点
    1). 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
    2). 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

    AOF的优点
    1). 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其 效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变 化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。
    2). 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操 作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题。
    3). 如果日志过大,Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
    4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。
    AOF的缺点
    1). 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
    2). 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

    二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(aof),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save的时候,再做备份(rdb)。rdb这个就更有些 eventually consistent的意思了。

    4.redis恢复数据的机制

    如果只配置 AOF ,重启时加载 AOF 文件恢复数据;
    如果同时配置了 RDB 和 AOF ,启动时只加载 AOF 文件恢复数据;
    如果只配置 RDB,启动时将加载 dump 文件恢复数据。
    也就是说,只要选择了持久化方案,重新启动会自动恢复数据。

  • 相关阅读:
    三数之和
    罗马数字与整数
    Oracle 开启或关闭归档
    Oracle RMAN scripts to delete archivelog
    Oracle check TBS usage
    Oracle kill locked sessions
    场景9 深入RAC运行原理
    场景7 Data Guard
    场景4 Data Warehouse Management 数据仓库
    场景5 Performance Management
  • 原文地址:https://www.cnblogs.com/xufengnian/p/11917366.html
Copyright © 2011-2022 走看看