Redis学习手册(持久化)

一、Redis提供了哪些持久化机制:

    1). RDB持久化:

    该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。    

    2). AOF持久化:

    该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的。

    3). 无持久化:

    我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了。

    4). 同时应用AOF和RDB。

    

二、RDB机制的优势和劣势:

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

三、AOF机制的优势和劣势:

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

四、其它:

   1. Snapshotting:
    缺省情况下,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内存快照。
    
   2. Dump快照的机制:
    1). Redis先fork子进程。
    2). 子进程将快照数据写入到临时RDB文件中。
    3). 当子进程完成数据写入操作后,再用临时文件替换老的文件。
    
   3. AOF文件:
    上面已经多次讲过,RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点,我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言,其缺省的机制是RDB,如果需要使用AOF,则需要修改配置文件中的以下条目:
    将appendonly no改为appendonly yes
    从现在起,Redis在每一次接收到数据修改的命令之后,都会将其追加到AOF文件中。在Redis下一次重新启动时,需要加载AOF文件中的信息来构建最新的数据到内存中。
    
   4. AOF的配置:
    在Redis的配置文件中存在三种同步方式,它们分别是:
    appendfsync always     #每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec  #每秒钟同步一次,该策略为AOF的缺省策略。
    appendfsync no          #从不同步。高效但是数据不会被持久化。
    
   5. 如何修复坏损的AOF文件:
    1). 将现有已经坏损的AOF文件额外拷贝出来一份。
    2). 执行”redis-check-aof –fix <filename>”命令来修复坏损的AOF文件。
    3). 用修复后的AOF文件重新启动Redis服务器。
    
   6. Redis的数据备份:

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


原文链接:http://www.cnblogs.com/stephen-liu74/archive/2012/04/02/2365017.html


原创文章,作者:追马,如若转载,请注明出处:http://www.178linux.com/513

(0)
追马追马
上一篇 2015-02-25
下一篇 2015-02-25

相关推荐

  • N21—-第一周课程练习题

    1、描述计算机的组成及其功能。 我们现在通常理解为计算机是由硬件系统+软件系统组成的,根据冯·诺依曼体系结构。计算机主要由五大部件组成:      运算器(Datapath): 计算机中执行各种算术和逻辑运算操作的部件      控制器(Control):是整个计算机的中枢神经,…

    Linux干货 2016-07-12
  • Shell脚本-循环基础

    Shell脚本-循环基础 背景: 正在学习Shell脚本之循环,发现Shell的循环和其他编程语言大同小异,逻辑上都是相通的,但在使用格式上却有点不同,在学习完Shell循环后,将学习的心得体会记录下来,以备今后复习。 介绍: 什么是Shell脚本:       shell script是利用shell的功能…

    2017-08-26
  • tomcat之-从AT到Cluster

    本文导航 一、    LAMT搭建以及部署应用        1、LAMT部署                   (1)、安装Apache     …

    2017-02-13
  • vim编辑器进阶

    1、vim介绍    vim(Visual Interface Improved)是一款异常强大的文本编辑器,如果大家对它的认识还停留在编辑文件,再退出的阶段的话,那就太对不起vim了,反倒不如用nano来的爽快。不过学习vim刚开始的阶段必然是痛苦的,如果想要一蹴而就,那就是你想多了。所以还需大家结合实际情况,勤加练习,认真揣摩。这里是…

    Linux干货 2016-08-11
  • linux哲学思想

    有关运维,在哲学上的思想。 正确的哲学思想在我看来就是公理,就是像1+1=2一样大家都必须得遵守的公理。 当然,所有的公理都是有前提的,而有关linux的哲学思想当然是在linux环境这个大前提下。才是公理。在我看来,公理就是在学习知识之前所要依靠的准则,linux下的一切都在这些准则下。 比如: 一切接文件  linux下所有都是以文件的形式保存…

    2017-07-22