zoukankan      html  css  js  c++  java
  • redis持久化的俩种方式特点及应用场景

    由于redis的数据都放在内存中,如果不持久化数据,redis重启后数据就会丢失,所以要进行持久化。

    一、RDB方式

    rdb持久化实际上是指在指定时间间隔内将内存中的数据集快照异步写进磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。

    优势:

    1、采用该方式以后,整个redis数据库将只包含一个文件,这对于文件备份是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。

    2、对于灾难恢复而言,RDB是非常不错的选择,因为我们可以非常轻松把一个单独的文件备份。

    3、性能最大化,对于redis的服务进程而言,在开始持久化时,他唯一需要做的就是fork出子进程,之后由子进程完成这些持久化工作,这样就可以极大的避免服务进程执行IO操作了。

    4、相对于AOF机制,如果数据集过大,RDB的启动效率会更高。

    缺点:

    1、如果想最大限度的避免数据丢失,那么RDB不是一个很好的选择,因为系统一旦在持久化之前出现死机现象,此前没有来得及写入磁盘的数据将全部丢失。

    2、RDB是使用fork的子进程来协助完成数据持久化的,数据集过大时,可能会使整个服务器停止好几百毫秒,甚至一秒钟。

    二、AOF方式

    AOF持久化时指将redis的操作日志以追加的方式写入文件。

    优势:

    1、数据安全性更高,持久化更高。redis提供3种同步策略,每秒同步,每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。

    2、由于该机制对日志文件使用的事append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

    3、 如果日志过大,Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

    4、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。

    缺点:

    1、 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

    2、根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

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

    4、常用配置

    RDB持久化配置

    Redis会将数据集的快照dump到dump.rdb文件中。此外,我们也可以通过配置文件来修改Redis服务器dump快照的频率,在打开6379.conf文件之后,我们搜索save,可以看到下面的配置信息:

    save 900 1              #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。

    save 300 10            #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。

    save 60 10000        #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。

    AOF持久化配置

    在Redis的配置文件中存在三种同步方式,它们分别是:

    appendfsync always     #每次有数据修改发生时都会写入AOF文件。

    appendfsync everysec  #每秒钟同步一次,该策略为AOF的缺省策略。

    appendfsync no          #从不同步。高效但是数据不会被持久化。

       . 如何修复坏损的AOF文件:

        1). 将现有已经坏损的AOF文件额外拷贝出来一份。
        2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
        3). 用修复后的AOF文件重新启动Redis服务器。
        
       . Redis的数据备份:

        在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中,之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说,在任意时刻copy数据文件都是安全的和一致的。鉴于此,我们就可以通过创建cron job的方式定时备份Redis的数据文件,并将备份文件copy到安全的磁盘介质中。 

  • 相关阅读:
    Amazon Route 53
    监控应用程序负载均衡器ALB
    DynamoDB 流
    DynamoDB 中的限制
    Amazon SNS 消息属性
    关于基于 SAML 2.0 的联合身份验证
    Amazon EBS 性能提示
    Laravel5.1注册中间件的三种场景
    编译LNMP环境
    傻瓜式搭建LAMP环境
  • 原文地址:https://www.cnblogs.com/zt666/p/8949979.html
Copyright © 2011-2022 走看看