redis的持久化策略(RDB与AOF)

redis的持久化策略(RDB与AOF)

前言

众所周知,Redis是一款工作在内存中的nosql(not only sql)的非关系数据库.以速度快和功能强大和数据类型丰富而出名.但是由于工作在内存中,服务崩溃重启就会导致数据丢失.而redis本身常作为缓存层,在高并发的场景下缓存数据突然丢失,那么带给后端的压力是很大的,很容易造访问服务过慢的问题,更严重的话后端机器的服务会崩溃带来严重灾难.所以我们需要将在内存的数据刷到磁盘上.从而保证redis故障恢复后能够重新加载磁盘上的数据到内存中.而redis的持久化策略是怎么做的呢?下面我们一起来学习下吧.

两种类型的持久化

redis持久化有两种策略,一种是系统默认的RDB(snapshotting快照)持久化,另外一种是AOF(append-only-file)持久化方式.RDB策略对应生成的数据文件默认名字叫dump.rdb ,AOF策略对应的数据文件名是appendonly.aof  .知道了两种类型的持久化策略,下面我们介绍他们的工作原理

持久化的工作原理

写时复制(Copy on write)

 redis会fork一个子进程 ,子进程把当前最新的aof写入一个临时文件.父进程仍把最新的数据写入到旧的aof中(防止rewrite失败,数据丢失)

当子进程完成rewrite临时文件后,父进程会收到一个信号,把之前内存中增量的数据加入到临时文件末尾.然后redis将这个旧aof重命名 ,临时文件重命名,开始新的aof写入

RDB持久化原理

redis会fork一个子进程,通过写写时复制的技术 每隔一段时间进行快照并记录这时间内的操作,在这段时间内超过多少次操作就进行持久化,然后生成dump.rdb(可以自定义名字,用于redis单机多实例的文件区分)

save N M  代表N秒内.至少发生了M此次操作则redis会进行快照然后刷到磁盘中.也可以手动执行save 或者bgsave(异步)做快照.

  • 策略

save 900 1      #当有一条Keys数据被改变时,900秒刷新到Disk一次
save 300 10    #当有10条Keys数据被改变时,300秒刷新到Disk一次
save 60 10000    #当有10000条Keys数据被改变时,60秒刷新到Disk一次

AOF持久化原理

AOF策略也是基于写时复制技术,他会根据设定的频率记录服务器执行的所有写操作,并在服务器重启后,通过执行aof数据文件中的命令来进行还原

  • 策略

appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度也是最慢的,一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,这种fsync策略可以兼顾速度和安全性,是受推荐的方式。
appendfsync no #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不被推荐。

  • 如何开启AOF?

默认aof是不开启的,想要开启配置如下:

appendonly yes       #启用AOF持久化方式

appendfilename “appendonly.aof”      #AOF文件的名称,默认是appendonly.aof,单机多实例的情况名字应该做好区分,不要相同,可以根据对应业务名或者端口号来区分

appendfsync everysec       #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,这种fsync策略可以兼顾速度和安全性,是受推荐的方式。

  • AOF的重写机制

随着命令不断从AOF内存中写入到AOF文件中,AOF文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制来压缩AOF文件。AOF文件的压缩和RDB文件的压缩原理不一样,RDB文件的压缩是使用压缩算法将二进制的RDB文件压缩,而AOF文件的压缩主要是去除AOF文件中的无效命令,比如说:
同一个key的多次写入只保留最后一个命令
已删除、已过期的key的写命令不再保留

而AOF重写的触发机制也分为手动触发和自动触发两种方式。

  • 手动触发

  bgrewriteaof 

  • 自发触发   

自动触发的原理就是通过两个参数为自动触发设置了一个条件区间   “当aof文件小于xxx时候不进行aof ,当aof文件达到了xxxx的时候.开始执行bgrewriteaof”

auto-aof-rewrite-min-size 64MB             (当aof文件小于64m时不进行重写)

auto-aof-rewrite-min-percenrage 100     (如果当前AOF文件大小比上次重写后的AOF文件大100%时,那么发生重写.)

这里说一下第二个参数:

假如上次重写前数据为4G 重写后是1.5G ,此时1.5是我们的对象A  ,而后数据又不断增加,当我们的数据变成了3G的时候 ,此时是A的二倍也就是多了100%,开始自动执行bgrewriteaof 

 

两种策略的优缺点对比

  • AOF的优点

1.AOF记录的数据相比RDB更加的完整,能够较少重要数据的丢失.

  • AOF的缺点

1.由于记录数据比较完整,aof文件会比较大,redis数据过多时或造成磁盘空间不足,可以通过bgrewriteaof命令进行aof重写减小文件体积

2.aof持久化时,对redis性能影响相对rdb来说较大

3.通过aof文件恢复数据时,相对rdb较慢

  • RDB的优点

1.对redis性能影响小

2.数据恢复速度快

3.文件占用体积小

  • rdb缺点

记录数据相对aof不够完整,如果要不允许redis数据丢失,那么rdb不是推荐的选择.

我该如何选择?

1.如果你们力求性能,而不在乎数据丢失过多那么rdb是不二选择

2.如果想要保证数据尽可能少丢失,选择AOF

3.RDB和AOF同时选择. AOF有时会因为BUG或其他原因导致文件损坏,如果只用AOF,数据就彻底丢失了.所以多个选择多种保险.

备注:

如果既选择AOF也选择了RDB.那么恢复数据时候redis优先选择AOF.因为他的数据最全!

总结

关于Redis的两种持久化方式到这里就介绍完了,这里再总结一下:

  • RDB持久化基于内存快照存储二进制文件,AOF持久化基于写命令存储文本文件。
  • RDB文件采用了压缩算法,比较小;AOF文件随着命令的叠加会越来越大,Redis提供了AOF重写来压缩AOF文件。
  • 恢复RDB文件的速度比AOF文件快很多。
  • RDB持久化方式实时性不好,所以AOF持久化更主流。
  •  合理的使用AOF的同步策略,理论上不会丢失大量的数据。

 

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Loading...