redis 持久化 Redis 711 茶与酒 2020-09-17 17:30:36 # 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 文件，先将之删除。如下：  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 参数。