redis的基础知识我们已经准备的差不多了,接下来两篇文章,我想和大家聊聊redis持久化这个话题。
本文是Redis系列的第八篇文章,了解前面的文章有助于更好的理解本文:
1.Linux上安装Redis
2.Redis中的五种数据类型简介
3.Redis字符串(STRING)介绍
4.Redis字符串(STRING)中BIT相关命令
5.Redis列表与集合
6.Redis散列与有序集合
7.Redis中的发布订阅和事务
redis持久化
整体上来说,redis持久化有两种方式,快照持久化和AOF,在项目中我们可以根据实际情况选择合适的持久化方式,也可以不用持久化,这关键看我们的redis在项目中扮演了什么样的角色。那么我将分别用两篇文章来介绍这两种不同的持久化方式,本文我们先来看看第一种方式。
快照持久化
快照持久化,顾名思义,就是通过拍摄快照的方式实现数据的持久化,redis可以在某个时间点上对内存中的数据创建一个副本文件,副本文件中的数据在redis重启时会被自动加载,我们也可以将副本文件拷贝到其他地方一样可以使用。
如何配置快照持久化
redis中的快照持久化默认是开启的,redis.conf中相关配置主要有如下几项:
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./
前面三个save相关的选项表示备份的频率,分别表示900秒内至少一个键被更改则进行快照,300秒内至少10个键被更改则进行快照,60秒内至少10000个键被更改则进行快照,
stop-writes-on-bgsave-error表示在快照创建出错后,是否继续执行写命令,rdbcompression则表示是否对快照文件进行压缩,dbfilename表示生成的快照文件的名字,dir则表示生成的快照文件的位置,在redis中,快照持久化默认就是开启的。我们可以通过如下步骤验证快照持久化的效果:
1.进入redis安装目录,如果有dump.rdb文件,先将之删除。如下:
![p299]()
2.启动redis,随便向redis中存储几个数据,然后关闭redis并退出,如下:
[root@localhost redis-4.0.8]# redis-server redis.conf
[root@localhost redis-4.0.8]# redis-cli
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> SHUTDOWN
not connected> exit
3.退出来后,我们发现刚刚删掉的dump.rdb文件又回来了,这就是生成的备份文件。
4.此时再次启动redis并进入,发现刚刚存储的数据都还在,这是因为redis在启动时加载了dump.rdb中的数据。好了,关闭redis并退出。
5.将redis目录下的dump.rdb文件删除。
6.再次启动redis并进入到控制台,所有的数据都不存在了。
快照持久化操作流程
通过上面的介绍,小伙伴们对快照持久化都有一个大致的认识了,那么这个东西到底是怎么运行的?持久化的时机是什么?我们来仔细扒一扒。
1.在redis运行过程中,我们可以向redis发送一条save命令来创建一个快照,save是一个阻塞命令,redis在接收到save命令之后,开始执行备份操作之后,在备份操作执行完毕之前,将不再处理其他请求,其他请求将被挂起,因此这个命令我们用的不多。save命令执行如下:
127.0.0.1:6379> SAVE
OK
2.在redis运行过程中,我们也可以发送一条bgsave命令来创建一个快照,不同于save命令,bgsave命令会fork一个子进程,然后这个子进程负责执行将快照写入硬盘,而父进程则继续处理客户端发来的请求,这样就不会导致客户端命令阻塞了。如下:
127.0.0.1:6379> BGSAVE
Background saving started
3.如果我们在redis.conf中配置了如下选项:
save 900 1
save 300 10
save 60 10000
那么当条件满足时,比如900秒内有一个key被操作了,那么redis就会自动触发bgsava命令进行备份。我们可以根据实际需求在redis.conf中配置多个这种触发规则。
4.还有一种情况也会触发save命令,那就是我们执行shutdown命令时,当我们用shutdown命令关闭redis时,此时也会执行一个save命令进行备份操作,并在备份操作完成后将服务器关闭。
5.还有一种特殊情况也会触发bgsave命令,就是在主从备份的时候。当从机连接上主机后,会发送一条sync命令来开始一次复制操作,此时主机会开始一次bgsave操作,并在bgsave操作结束后向从机发送快照数据实现数据同步。
快照持久化的缺点
快照持久化有一些缺点,比如save命令会发生阻塞,bgsave虽然不会发生阻塞,但是fork一个子进程又要耗费资源,在一些极端情况下,fork子进程的时间甚至超过数据备份的时间。定期的持久化也会让我们存在数据丢失的风险,最坏的情况我们可能丢失掉最近一次备份到当下的数据,具体丢失多久的数据,要看我们项目的承受能力,我们可以根据项目的承受能力配饰save参数。
OK,快照持久化我们就介绍这么多,更多资料小伙伴们可以参考官方文档http://www.redis.net.cn/tutorial/3501.html。小伙伴在看官方文档时,有什么问题欢迎留言讨论。
更多资料请关注公众号:
本文分享自微信公众号 - 江南一点雨(a_javaboy)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。