Redis 基础教程

Redis 命令

Redis 高级教程

Redis 笔记

Redis 持久化


Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。

Redis在实际使用中采用多种不同级别的持久化方式:

  1. RDB持久化方式,它可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。

  2. AOF持久化方式,它会在执行写命令时,将被执行的写命令复制到硬盘里。AOF全称append-only file,记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。AOF 文件中的命令全部以Redis协议的格式来保存,新命令会被追加到文件的末尾。Redis还可以在后台对AOF文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

  3. Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下,当Redis重启时,它会优先使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

  4. 你甚至可以关闭持久化功能,让数据只在服务器运行时存在。

Redis RDB持久化


快照(snapshotting),它可以将存在于某一时刻的所有数据都写入磁盘里面。 

RDB快照

在默认情况下, Redis将数据库快照保存在名字为dump.rdb的二进制文件中。

你可以对Redis进行设置,让它在“N秒内数据集至少有M个改动”这一条件被满足时,自动保存一次数据集。

你也可以通过调用SAVE或者BGSAVE,手动让Redis进行数据集保存操作。

RDB配置参数

save <seconds> <changes>  
stop-writes-on-bgsave-error yes  
rdbcompression yes  
dbfilename dump.rdb  
dir ./ 
  • save:在X秒内如果key有至少X次改变就触发持久化,例如save 900 1的话就是在900秒如果key有至少1次改变就触发持久化。如果想关闭此功能的话,可以把全部save行都注释或删除或者使用save ""。

  • stop-writes-on-bgsave-error:在bgsave遇到error的时候是否停止持久化,默认是yes代表是,no代表不是。

  • rdbcompression:是否压缩,默认是yes代表是,no代表不是,如果想节省CPU的话就设为no,但是rdb文件会比较大。

  • dbfilename:持久化的文件名字,默认是dump.rdb。

  • dir:持久化的目录名字,默认是redis.conf所在的目录./。

RDB运作方式 

当Redis需要保存dump.rdb文件时,服务器执行以下操作:

  1. Redis调用fork(),同时拥有父进程和子进程。

  2. 子进程将数据集写入到一个临时RDB文件中。

  3. 当子进程完成对新RDB文件的写入时,Redis用新RDB文件替换原来的RDB文件,并删除旧的RDB文件。

这种工作方式使得Redis可以从写时复制(copy-on-write)机制中获益。

Redis AOF持久化


快照功能并不是非常耐久(durable),如果Redis因为某些原因而造成故障停机,那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

AOF追加文件

尽管对于某些程序来说,数据的耐久性并不是最重要的考虑因素,但是对于那些追求完全耐久能力(full durability)的程序来说,快照功能就不太适用了。从1.1版本开始,Redis增加了一种完全耐久的持久化方式, AOF 持久化。

AOF配置参数

appendonly no  
appendfilename "appendonly.aof"  
appendfsync everysec 
dir ./ 
  • appendonly:是否启动aof,默认是no代表不启用,yes代表启用。

  • appendfilename:aof的文件名,默认是appendonly.aof。

  • appendfsync:配置Redis多久才将数据fsync到磁盘一次。该配置有3个选项,默认是everysec代表每秒,足够快(和使用RDB持久化差不多),并且在故障时只会丢失1秒钟的数据;另外还有always代表有改变都触发(每次有新命令追加到AOF文件时就执行一次fsync),性能最差但数据最安全;no代表让OS自己决定什么时候执行,性能最好但数据不安全。推荐(并且也是默认)的措施为每秒fsync一次,这种fsync策略可以兼顾速度和安全性

  • dir:和上述是同一个参数(共用),持久化的目录名字,默认是redis.conf所在的目录./。

 

AOF重写/压缩

因为AOF的运作方式是不断地将命令追加到文件的末尾,所以随着写入命令的不断增加,AOF文件的体积也会变得越来越大。

举个例子,如果你对一个计数器调用了100次INCR,那么仅仅是为了保存这个计数器的当前值,AOF文件就需要使用100条记录(entry)。

然而在实际上,只使用一条SET命令已经足以保存计数器的当前值了,其余99条记录实际上都是多余的。

为了处理这种情况,Redis支持一种有趣的特性:可以在不打断服务客户端的情况下,对AOF文件进行重建(rebuild)。

执行BGREWRITEAOF命令,Redis将生成一个新的AOF文件,这个文件包含重建当前数据集所需的最少命令。Redis2.2需要自己手动执行BGREWRITEAOF命令; Redis 2.4则可以自动触发AOF重写。

AOF重写相关配置:

no-appendfsync-on-rewrite no  
auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb 
  • no-appendfsync-on-rewrite:在aof rewrite的时候上述appendfsync是否暂时停止,默认是no代表不停止,yes代表停止,不会造成I/O资源竞争,性能较前者好。在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。

  • auto-aof-rewrite-percentage:自动触发aof rewrite的百分比,默认是100%,就是比上次rewrite的1倍。

  • auto-aof-rewrite-min-size:自动触发aof rewrite的最小size,默认是64mb,就是如果size超过64mb,而且是上次执行的1倍,就会自动触发。

AOF运作方式

AOF重写和RDB创建快照一样,都巧妙地利用了写时复制机制。

以下是AOF重写的执行步骤:

  1. Redis执行fork(),现在同时拥有父进程和子进程。

  2. 子进程开始将新AOF文件的内容写入到临时文件。

  3. 对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有AOF文件的末尾,这样即使在重写的中途发生停机,现有的AOF文件也还是安全的。

  4. 当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新AOF文件的末尾。

  5. 搞定!现在Redis原子地用新文件替换旧文件,之后所有命令都会直接追加到新AOF文件的末尾。

如果AOF文件出错了,怎么办?

服务器可能在程序正在对AOF文件进行写入时停机,如果停机造成了AOF文件出错,那么Redis在重启时会拒绝载入这个AOF文件,从而确保数据的一致性不会被破坏。

当发生这种情况时,可以用以下方法来修复出错的AOF文件:

  1. 为现有的AOF文件创建一个备份。

  2. 使用Redis附带的redis-check-aof程序,对原来的AOF文件进行修复。

    $ redis-check-aof --fix
  3. (可选)使用diff -u对比修复后的AOF文件和原始AOF文件的备份,查看两个文件之间的不同之处。

  4. 重启Redis服务器,等待服务器载入修复后的AOF文件,并进行数据恢复。

RDB和AOF比较


Redis的RDB持久化方式和AOF持久化方式各自都有其优缺点。

RDB的优点

  • RDB是一个非常紧凑(compact)的文件,它保存了Redis在某个时间点上的数据集。这种文件非常适合用于进行备份,比如说,你可以在最近的24小时内,每小时备份一次RDB文件,并且在每个月的每一天,也备份一个RDB文件。这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。

  • RDB非常适用于灾难恢复(disaster recovery),它只有一个文件,并且内容都非常紧凑,可以(在加密后)将它传送到别的数据中心,或者亚马逊S3中。

  • RDB可以最大化Redis的性能,父进程在保存RDB文件时唯一要做的就是fork出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘I/O操作。

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

RDB的缺点

  • 如果你需要尽量避免在服务器故障时丢失数据,那么RDB不适合你。虽然Redis允许你设置不同的保存点(save point)来控制保存RDB文件的频率,但是,因为RDB文件需要保存整个数据集的状态,所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下,一旦发生故障停机,你就可能会丢失好几分钟的数据。

  • 每次保存RDB的时候,Redis都要fork()出一个子进程,并由子进程来进行实际的持久化工作。在数据集比较庞大时,fork()可能会非常耗时,造成服务器在某某毫秒内停止处理客户端;如果数据集非常巨大,并且CPU时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒。虽然AOF重写也需要进行fork(),但无论AOF重写的执行间隔有多长,数据的持久化都不会有任何损失。

AOF的优点

  • 使用AOF持久化会让Redis变得非常durable,你可以设置不同的fsync策略,比如无fsync,每秒钟一次fsync,或者每次执行写入命令时fsync。AOF的默认策略为每秒钟fsync一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据(fsync会在后台线程执行,所以主线程可以继续努力地处理命令请求)。

  • AOF文件是一个只进行追加操作的日志文件(append only log),因此对AOF文件的写入不需要进行seek,即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满,写入中途停机,等等),redis-check-aof工具也可以轻易地修复这种问题。

  • Redis可以在AOF文件体积变得过大时,自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的,因为Redis在创建新AOF文件的过程中,会继续将命令追加到现有的AOF文件里面,即使重写过程中发生停机,现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕,Redis就会从旧AOF文件切换到新AOF文件,并开始对新AOF文件进行追加操作。

  • AOF文件有序地保存了对数据库执行的所有写入操作,这些写入操作以Redis协议的格式保存,因此AOF文件的内容非常容易被人读懂,对文件进行分析(parse)也很轻松。导出(export)AOF文件也非常简单,举个例子,如果你不小心执行了FLUSHALL命令,但只要 AOF文件未被重写,那么只要停止服务器,移除AOF文件末尾的FLUSHALL命令,并重启Redis,就可以将数据集恢复到FLUSHALL执行之前的状态。

AOF的缺点

  • 对于相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积。根据所使用的fsync策略,AOF的速度可能会慢于RDB。在一般情况下,每秒fsync的性能依然非常高,而关闭fsync可以让AOF的速度和RDB一样快,即使在高负荷之下也是如此。不过在处理巨大的写入载入时,RDB可以提供更有保证的最大延迟时间(latency)。

  • AOF在过去曾经发生过这样的bug,因为个别命令的原因,导致AOF文件在重新载入时,无法将数据集恢复成保存时的原样。(举个例子,阻塞命令BRPOPLPUSH就曾经引起过这样的bug )。测试套件里为这种情况添加了测试,它们会自动生成随机的、复杂的数据集,并通过重新载入这些数据来确保一切正常。虽然这种bug在AOF文件中并不常见,但是对比来说,RDB几乎是不可能出现这种bug的。

RDB和AOF,应如何选择?

一般来说,如果想达到足以媲美PostgreSQL的数据安全性,你应该同时使用两种持久化功能。

如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失,那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化,但我们并不推荐这种方式,因为定时生成RDB快照(snapshot)非常便于进行数据库备份,并且RDB恢复数据集的速度也要比AOF恢复的速度要快,除此之外,使用RDB还可以避免之前提到的AOF程序的bug。

因为以上提到的种种原因,未来可能会将AOF和RDB整合成单个持久化模型(这是一个长期计划)。

如何从RDB持久化切换到AOF持久化?

在Redis 2.2或以上版本,可以在不重启的情况下,从RDB切换到AOF:

  1. 为最新的dump.rdb文件创建一个备份。

  2. 将备份放到一个安全的地方。

  3. 执行以下两条命令:

    redis-cli> CONFIG SET appendonly yes
    
    redis-cli> CONFIG SET save ""
  4. 确保命令执行之后,数据库的键的数量没有改变。

  5. 确保写命令会被正确地追加到AOF文件的末尾。

步骤3执行的第一条命令开启了AOF功能,Redis会阻塞直到初始AOF文件创建完成为止,之后Redis会继续处理命令请求,并开始将写入命令追加到AOF文件末尾。

步骤3执行的第二条命令用于关闭RDB功能。这一步是可选的,如果你愿意的话,也可以同时使用RDB和AOF这两种持久化功能。

别忘了在redis.conf中打开AOF功能!否则的话,服务器重启之后,之前通过CONFIG SET设置的配置就会被遗忘,程序会按原来的配置来启动服务器。

如何协调RDB和AOF的相互作用?

在版本号大于等于2.4的Redis中,BGSAVE执行的过程中,不可以执行BGREWRITEAOF。反过来说,在BGREWRITEAOF执行的过程中,也不可以执行BGSAVE。

这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行,并且用户显示地调用BGREWRITEAOF命令,那么服务器将向用户回复一个OK状态,并告知用户,BGREWRITEAOF已经被预定执行,一旦BGSAVE执行完毕,BGREWRITEAOF就会正式开始。

当Redis启动时,如果RDB持久化和AOF持久化都被打开了,那么程序会优先使用AOF文件来恢复数据集,因为AOF文件所保存的数据通常是最完整的。