Redis 持久化

原创
10/18 17:46
阅读数 1

Redis是一种高级key-value数据库。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富:分别是字符串(String)、哈希(Hash)、列表(List)、集合(Set)和有序集合(Sorted Set)。Redi还支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。

Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(AOF)里面(这称为“全持久化模式”)。 

由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,于是需要开启redis的持久化功能,将数据保存到磁盘上,当redis重启后,可以从磁盘中恢复数据。

redis主要提供的持久化方式:     RDB和AOF具体实现原理和细节

  • 一种是RDB持久化(原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化),也称 半持久化模式。RDB持久化的触发分为手动触发和自动触发两种。手动触发通过redis的save命令和bgsave命令,都可以生成RDB文件。自动触发最常见的情况是在配置文件中通过save m n,指定当m秒内发生n次变化时,会触发bgsave。save m n的含义:当时间到m秒时,如果redis数据发生了至少n次变化,则执行bgsave;是将数据先存储在内存,然后当数据累计达到某些设定的伐值的时候,就会触发一次DUMP操作,将变化的数据一次性写入数据文件(RDB文件)。
  • 另外一种是AOF(Append Only File)持久化(原理是将Reids的操作日志以追加的方式写入文件),也称 全持久化模式。类似mysql的基于语句的binlog方式,即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中,也就是说这个log文件就是Redis的持久化数据。此模式记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写(rewrite),使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。AOF持久化的触发分为手动触发和自动触发两种。
  • Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下, 当 Redis 重启时, 它会优先使用 AOF 文件来还原数据集, 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

正确关闭服务器:redis-cli shutdown 或者 kill,都会graceful shutdown,保证写RDB文件以及将AOF文件fsync到磁盘,不会丢失数据。 如果是粗暴的Ctrl+C,或者kill -9 就可能丢失。

RDB的优势:

  1.  RDB 是一个非常紧凑(compact)的文件,它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份。采用该方式,你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。
  2. 非常适用于灾难恢复(disaster recovery):它只有一个文件,并且内容都非常紧凑,可以(在加密后)将它传送到别的数据中心或者其它存储介质上。
  3. 性能最大化。对于Redis的服务进程而言,在开始持久化时,父进程唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
  4. 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。

RDB的劣势:

  1. 如果你想保证数据的高可用性,最大限度的避免数据丢失,那么RDB不是很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。虽然 Redis 允许你设置不同的保存点(save point)来控制保存 RDB 文件的频率, 但是, 因为RDB 文件需要保存整个数据集的状态, 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下, 一旦发生故障停机, 你就可能会丢失好几分钟的数据。
  2.  由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,在数据集比较庞大时,fork() 可能会非常耗时,造成服务器在某某毫秒内停止处理客户端;如果数据集非常巨大,并且 CPU 时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ,但无论 AOF 重写的执行间隔有多长,数据的耐久性都不会有任何损失。

AOF的优势:

  1. 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于不同步,效率最高,但是数据不会被持久化。
  2. 由于该机制对日志文件的写入操作采用的是append模式,因此对 AOF 文件的写入不需要进行 seek,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容 ,即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满,写入中途停机,等等),redis-check-aof 工具也可以轻易地修复这种问题。
  3. Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
  4. AOF 文件有序地保存了对Redis执行的所有写入操作,这些写入操作以 Redis 协议的格式保存,因此 AOF 文件的内容非常容易被人读懂,对文件进行分析也很轻松,导出AOF 文件也非常简单。 例如:如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写,那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令,并重启 Redis ,就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF的劣势:

  1. 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
  2. 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下,每秒 fsync 的性能依然非常高,而关闭 fsync 可以让 AOF 的速度和 RDB 一样快,即使在高负荷之下也是如此。不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。
  3. AOF 在过去曾经发生过这样的 bug : 因为个别命令的原因,导致 AOF 文件在重新载入时,无法将数据集恢复成保存时的原样。(阻塞命令 BRPOPLPUSH source destination timeout 就曾经引起过这样的 bug 。) 测试套件里为这种情况添加了测试: 它们会自动生成随机的、复杂的数据集, 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见,但是对比来说,RDB 几乎是不可能出现这种 bug 的。

二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(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内存快照。
stop-writes-on-bgsave-error yes: #当bgsave出现错误时,Redis是否停止执行写命令;设置为yes,则当硬盘出现问题时,可以及时发现,避免数据的大量丢失;
                                   设置为no,则Redis无视bgsave的错误继续执行写命令,当对Redis服务器的系统(尤其是硬盘)使用了监控时,该选项考虑设置为no 
rdbcompression yes:    #是否开启RDB文件压缩 
rdbchecksum yes:       #是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现 
dbfilename dump.rdb:   #RDB文件名 
dir ./:                #RDB文件和AOF文件所在目录 

关闭RDB:

  • 关闭rdb的命令:config set save ""   执行命令后,无需重启服务,即可生效。
  • 修改Save配置注释掉,并打开save "",修改完成后,重启Redis服务即可。
#Save 900 1     
#Save 300 10   
#Save 60 10000   
Save ""

AOF持久化配置

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

appendonly:           #是否打开AOF持久化功能,appendonly默认是 no, 改成appendonly yes。
appendfilename         #AOF文件名称
appendfsync always     #每次有数据修改发生时都会写入AOF文件。 同步频率
appendfsync everysec   #每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no         #从不同步。高效但是数据不会被持久化。
auto-aof-rewrite-min-size:   #如果文件大小小于此值不会触发AOF,默认64MB 
auto-aof-rewrite-percentage: #Redis记录最近的一次AOF操作的文件大小,如果当前AOF文件大小增长超过这个百分比则触发一次重写,默认100​​​​​​
  • 启用AOF:   appendonly yes  
  • 关闭AOF:命令行关闭:config set appendfsync no         配置文件关闭:将appendonly设置为no,默认是  appendonly no 
展开阅读全文
rdb
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部