1. 使用场景
在我们正式的线上环境中,如果不是用的云服务器,而是客户本地的服务器,那出现服务器突然断电的情况是很正常的,有些项目比较依赖于Redis,或者某些数据较多的项目,依赖于Redis去做了一些缓存,方便查询数据的速率,这时候如果断电恢复过来,redis里面没有数据的话,就有点缓存雪崩的意思了。
2.持久化方式介绍
2.1 RDB
Redis给我们提供的第一种持久化的方式就是RDB方式,这种方式默认是将我们Redis在缓存中数据的二进制存入到文件中的,相当于是对我们的缓存做了一个快照,可想而知,如果我们使用这种方式进行数据的恢复的化,直接将数据恢复到缓存,速度是很快的,但是同样,因为是直接克隆我们的缓存,那么在生成这个文件的过程是很慢的,没办法做到实时的生成,否则会严重影响服务器的性能,这样就存在一个问题,如果是1个小时克隆一次,那么如果服务器断电,可能就会丢失1个小时的数据。
2.2 AOF
第二种方式称为AOF,这种方式是将我们redis的操作指令存储到文件中,弥补上一种方式的缺点,它可以做到1秒记录一次,或者每当执行命令时,都记录一次,只是将我们的指令记录到文件,不会过多影响服务器的性能,但是这种方式同样有它的缺点,那就是,如果我们在Redis里面存储了很多很多数据,并且已经进行过了很多的操作了,如果一个Key我先存了进去,后面又把它删了,按道理,这种数据我已经不要了,就不用在帮我恢复了,但是指令已经在文件中生成了,set和del的命令,它会再帮你执行一遍,可想而知,这种恢复的速度是特别慢的
综上所述,生成环境中要根据自己的项目类型,和存储Redis中的数据来判断应该选择那种持久化的方式,各自有各自的有点和缺点。
3.持久化方式的操作
3.1 使用RDB进行持久化存储
3.1.1 自动化进行RDB存储
打开Redis的配置文件找到上面这些内容,window下的配置文件是redis.windows.conf,linux的配置文件是redis.conf,Redis已经默认帮助我们开启了RDB的持久化方式
save 900 1 表示的含义是 900秒内,如果有1个key进行了更新,那就更新RDB文件
save 300 10 表示的含义是 300秒内,如果有10个key进行了更新,那就更新RDB文件
save 60 10000 表示的含义是 60秒内,如果有10000个key进行了更新,那就更新RDB文件
为了测试,我这里加了一个5秒内如果更新了一个Key那就帮我更新RDB文件
启动Redis指定配置文件
redis-server ./redis.windows.conf
往redis里面塞了一个key
set first 111
在redis的安装目录内,就可以看到生成了一个dump.rdb的文件
这里面记录的就是我们的rdb的数据了。
另外,如果我们正常的退出redis,Redis也会帮我们进行RDB的存储
3.1.2 手动进行RDB备份
可以使用save和bgsave两个命令触发RDB持久化。
3.1.3 备份的恢复
我们正常启动Redis,它会自动检测有没有rdb的文件,如果有的话,redis就会自动帮我们把rdb的数据恢复过来。
3.2 AOF持久化存储
继续打开配置文件,找到上述的内容
appendonly no Redis默认关闭了AOF的持久化的方式,如果使用将no改成yes
appendfilename “appendonly.aof” aof文件名称
appendfsync always 表示每当我们有了一次操作,它就帮我们同步到AOF文件中
appendfsync everysec 表示每秒帮我们同步一次
appendfsync no 不使用sync,依靠操作系统的刷写。
我们将AOF持久化打开(将no换成yes)
让redis指定配置文件启动
redis-server ./redis.windows.conf
可以看到我们就算不进行操作,也帮我们生成了aof的文件,因为我们设置的是每秒执行,但是文件里面是空的,我们往redis里面设置一个值的时候,我们打开aof的文件看一下
虽然不知道什么意思,但是大致可以看出来,帮我们执行了set first 111 还有 del first这样的指令
3.2.2 手动触发
可以通过bgrewriteaof命令触发aof文件的重写
3.2.3 数据恢复
当我们指定配置文件启动时,redis会从我们的配置文件中,检测一下,我们的aof功能有没有开启,如果开启的话,会优先使用aof的方式进行数据的恢复,就不会使用rdb的方式,进行数据的恢复了。
好了,Redis的持久化就说的这么多了,后面的章节中,我将介绍一下,Redis集群环境的数据同步,以及集群环境下碰到的各种问题及解决方案,如果这篇文章对你有用的话,别忘了关注,点赞,评论和收藏哦!