Redis持久化策略

发表时间:2018-03-13 18:59:46 浏览量( 14 ) 留言数( 0 )

学习目标:

1、了解Redis的持久化的使用

1、掌握Redis的持久化的配置

学习过程:

    Redis是内存数据库,所以在服务器重启或者断电时,内存数据肯定会丢失,对于某些应用来说这是不可接收,例如如果使用Redis作为订单号的生成器,每一次都会逐次增1,如果断电重启后,订单号必须能够接着增1,而不是从0开始。所以Redis有必要持久化数据。当然如果你的业务仅仅只是用于简单的缓存,那么你也可以禁用持久化以提升效率。  

Redis的有两种持久化策略:

  • rdb:快照形式是直接把内存中的数据保存到一个dump文件中,定时保存,保存策略

  • aof:把所有的对redis的服务器进行修改的命令都存到一个文件里,命令的集合


一、rdb方式

    快照rdb持久化方式时安装redis时的默认方式,将内存中的数据以快照的方式写入二进制文件中,默认的文件名是dump.rdb,这些也都可以通过配置文件修改的。

redis.conf常见配置:

dbfilename "dump.rdb" 

dir "/data/dbs/redis/6381"

save 900 1 

save 300 10

save 60 10000

意义如下:

    dbfilename "dump.rdb"          #持久化文件名称

    dir "/data/dbs/redis/6381"    #持久化数据文件存放的路径

    默认是如上配置:900秒之内,如果超过1个key被修改,则发起快照保存;

    300秒内,如果超过10个key被修改,则发起快照保存

    1分钟之内,如果1万个key被修改,则发起快照保存

    rdb持久化工作原理简单:当redis需要做持久化时,redis会fork一个子进程;子进程将数据写到磁盘上一个临时RDB文件中;当子进程完成写临时文件后,将原来的RDB替换掉,这样的好处就是可以copy-on-write。

   RDB持久化也分两种:SAVE和BGSAVE

  1、SAVE是阻塞式的RDB持久化,当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件(即上面的dump.rdb)中,直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。

 2、BGSAVE属于非阻塞式的持久化,它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里,同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程,这等于两个相同大小的redis进程在系统上运行,会造成内存使用率的大幅增加。这种方式尤其需要注意的。如果redis本身内存使用率就60%,总的内存使用率在80%左右,持久化的时候立马占到100%以上的。

可以使用命令操作的。

127.0.0.1:6379> bgsave

Background saving started

127.0.0.1:6379> save

OK

   从上面的配置可知,rdb方式不能完全保证数据持久化,因为是定时保存,所以当redis服务down掉,就会丢失一部分数据,而且数据量大,写操作多的情况下,会引起大量的磁盘IO操作,会影响性能。


二、aof方式

    使用aof做持久化,每一个写命令都通过write函数追加到appendonly.aof中.配置方式:启动aof持久化的方式 

    appendonly yes  

    Append-only方法可以做到全部数据不丢失,但redis的性能就要差些。AOF就可以做到全程持久化,只需要在配置文件中开启(默认是no),appendonly yes开启AOF之后,redis每执行一个修改数据的命令,都会把它添加到aof文件中,当redis重启时,将会读取AOF文件进行“重放”以恢复到redis关闭前的最后时刻。

    LOG Rewriting随着修改数据的执行AOF文件会越来越大,其中很多内容记录某一个key的变化情况。因此redis有了一种比较有意思的特性:在后台重建AOF文件,而不会影响client端操作。在任何时候执行BGREWRITEAOF命令,都会把当前内存中最短序列的命令写到磁盘,这些命令可以完全构建当前的数据情况,而不会存在多余的变化情况(比如状态变化,计数器变化等),缩小的AOF文件的大小。所以当使用AOF时,redis推荐同时使用BGREWRITEAOF。

    AOF文件刷新的方式,有三种,参考配置参数appendfsync :

    appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件,非常非常慢,但也非常安全;

    appendfsync everysec每秒钟都调用fsync刷新到AOF文件,很快,但可能会丢失一秒以内的数据;

    appendfsync no依靠OS进行刷新,redis不主动刷新AOF,这样最快,但安全性就差。默认并推荐每秒刷新,这样在速度和安全上都做到了兼顾。

appendonly yes              //启用aof持久化方式

# appendfsync always      //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用

appendfsync everysec     //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐 

# appendfsync no    //完全依赖os,性能最好,持久化没保证


    可能由于系统原因导致了AOF损坏,redis无法再加载这个AOF,可以按照下面步骤来修复:首先做一个AOF文件的备份,复制到其他地方;修复原始AOF文件,执行:$ redis-check-aof –fix ;可以通过diff –u命令来查看修复前后文件不一致的地方;重启redis服务。

redis-check-aof --fix  appendonly.aof   


总结:

   两种方式你可以自己根据需要选择,也可以同时开启两种持久化方式:

1、在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2、RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要使用AOF呢?那要看情况而定,如果缓存信息比较重要,那么可以使用AOF,因为RDB更适合用于备份数据库,这也是大部分的使用场景。


三、取消持久化

    其实我们也可以把持久化取消,以达到最高的运行效率,当然数据一旦断电也就会没有,我们可以使用主从配置或者集群的方式提高稳定性。所以很多时候也会在取消持久化功能的

  1. 注释掉原来的持久化规则

#save 900 1

#save 300 10

#save 60 10000


2.设置为空

save ""

   取消持久化需要注意的一点:如果你以前有使用过持久化功能,那么需要把以前的持久化文件删除才行。最好运行flushall命令清楚旧数据了。