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中相关配置主要有如下几项:
1 | save 900 1 |
前面三个 save 相关的选项表示备份的频率,分别表示 900 秒内至少一个键被更改则进行快照,300 秒内至少 10 个键被更改则进行快照,60 秒内至少 10000 个键被更改则进行快照, stop-writes-on-bgsave-error 表示在快照创建出错后,是否继续执行写命令, rdbcompression 则表示是否对快照文件进行压缩, dbfilename 表示生成的快照文件的名字,dir 则表示生成的快照文件的位置,在 redis 中,快照持久化默认就是开启的。我们可以通过如下步骤验证快照持久化的效果:
1.进入 redis 安装目录,如果有 dump.rdb 文件,先将之删除。如下:
2.启动 redis ,随便向 redis 中存储几个数据,然后关闭redis并退出,如下:
1 | [root@localhost redis-4.0.8]# redis-server redis.conf |
3.退出来后,我们发现刚刚删掉的 dump.rdb 文件又回来了,这就是生成的备份文件。
4.此时再次启动 redis 并进入,发现刚刚存储的数据都还在,这是因为 redis 在启动时加载了 dump.rdb 中的数据。好了,关闭 redis 并退出。
5.将 redis 目录下的 dump.rdb 文件删除。
6.再次启动 redis 并进入到控制台,所有的数据都不存在了。
快照持久化操作流程
通过上面的介绍,小伙伴们对快照持久化都有一个大致的认识了,那么这个东西到底是怎么运行的?持久化的时机是什么?我们来仔细扒一扒。
1.在 redis 运行过程中,我们可以向 redis 发送一条 save 命令来创建一个快照,save 是一个阻塞命令,redis 在接收到 save 命令之后,开始执行备份操作之后,在备份操作执行完毕之前,将不再处理其他请求,其他请求将被挂起,因此这个命令我们用的不多。save 命令执行如下:
1 | 127.0.0.1:6379> SAVE |
2.在 redis 运行过程中,我们也可以发送一条 bgsave 命令来创建一个快照,不同于 save 命令,bgsave 命令会 fork 一个子进程,然后这个子进程负责执行将快照写入硬盘,而父进程则继续处理客户端发来的请求,这样就不会导致客户端命令阻塞了。如下:
1 | 127.0.0.1:6379> BGSAVE |
3.如果我们在 redis.conf 中配置了如下选项:
1 | save 900 1 |
那么当条件满足时,比如 900 秒内有一个 key 被操作了,那么 redis 就会自动触发 bgsava 命令进行备份。我们可以根据实际需求在 redis.conf 中配置多个这种触发规则。
4.还有一种情况也会触发 save 命令,那就是我们执行 shutdown 命令时,当我们用 shutdown 命令关闭 redis 时,此时也会执行一个 save 命令进行备份操作,并在备份操作完成后将服务器关闭。
5.还有一种特殊情况也会触发 bgsave 命令,就是在主从备份的时候。当从机连接上主机后,会发送一条 sync 命令来开始一次复制操作,此时主机会开始一次 bgsave 操作,并在 bgsave 操作结束后向从机发送快照数据实现数据同步。
快照持久化的缺点
快照持久化有一些缺点,比如 save 命令会发生阻塞,bgsave 虽然不会发生阻塞,但是 fork 一个子进程又要耗费资源,在一些极端情况下,fork 子进程的时间甚至超过数据备份的时间。定期的持久化也会让我们存在数据丢失的风险,最坏的情况我们可能丢失掉最近一次备份到当下的数据,具体丢失多久的数据,要看我们项目的承受能力,我们可以根据项目的承受能力配饰 save 参数。
OK,快照持久化我们就介绍这么多,更多资料,小伙伴们可以参考官方文档。小伙伴在看官方文档时,有什么问题欢迎留言讨论。