o编辑整理，欢迎转载，转载请声明文章来源。欢迎添加echo微信(微信号：t2421499075)交流学习。 百战不败，依不自称常胜，百败不颓，依能奋力前行。——这才是真正的堪称强大！！！

Redis持久化的方案其实是很多人接触的比较少的，因为相对应的数据故障不会很多，一次初始化的设置就能保证后续故障的全部顺利解决。本文讲述一下该机制的主要设置方法和持久化方案的对比，同时也会讲述一些持久化的原理。如果对于Redis持久化比较熟悉的希望能够给到你帮助，如果不熟悉的，你大可参考本文对你的Redis进行设置。

什么是Redis的持久化？

可能很多人很少接触这个词，总觉的我们Redis的所有数据都是全部能够永久存储的。然而你可能不知道的是，Redis的数据都是在内存当中的，如果没有持久化策略，你关闭Redis或者之后，你的数据有可能全部都丢失了。我们每再一次登录Redis访问上一次数据的时候，我们都看到了原来的数据，就是得益于Redis的持久化。Redis的持久化简单说就是，将Redis存在内存中的值存储到可以永久存储的地方（磁盘等）

Redis的持久化方案

  • RDB Redis DataBase
  • AOF Append Only File

RDB [Redis DataBase]

RDB 是 Redis 默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢复数据。dump.rdb是我们redis文件当中的一个，位置如下图：
在这里插入图片描述

RDB是怎么实现持久化的

RDB是按照规则来触发持久化存储的，在我们的redis.conf中我们可以看到如下的几个配置：

save 900 1 # 900 秒内至少有一个 key 被修改（包括添加） save 300 10 # 300 秒内至少有 10 个 key 被修改 save 60 10000 # 60 秒内至少有 10000 个 key 被修改

在这里插入图片描述

这几个配置是不冲突的，只要满足任意一个都会触发。

  • RDB方式的优点
    • RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心，非常适用于灾难恢复。
    • 与AOF相比,在恢复大的数据集的时候，RDB 方式会更快一些。
  • RDB方式的缺点
    • RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要
      执行 fork 操作创建子进程，频繁执行成本过高。
    • 在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后
      一次快照之后的所有修改（数据有丢失）。如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。

RDB持久化的演示

如果我们都按照正常程序走的话，我们是很难看到没有持久化，或者出现持久化问题的故障现场的。所以我们要学会持久化操作，或者只管看到持久化就需要手动触发持久化问题。这里主要演示两种情况，一种是数据正常备份，一种是数据丢失，我们恢复备份数据。

注意

这两个操作都算是危险操作，我们需要在操作之前进行一下设置一下Redis快照，Redis
提供了两条命令：

  • save: 在生成快照的时候会阻塞当前 Redis 服务器， Redis 不能处理其他命令。如果
    内存中的数据比较多，会造成Redis长时间的阻塞。生产环境不建议使用这个命令。为了解决这个问题，Redis 提供了第二种方式。
  • bgsave:执行 bgsave 时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请
    求。具体操作是 Redis 进程执行fork操作创建子进程（copy-on-write），RDB持久化过程由子进程负责，完成后自动结束。它不会记录fork之后后续的命令。阻塞只发生在fork阶段，一般时间很短。用 lastsave 命令可以查看最近一次成功生成快照的时间。

使用shutdown 持久化

我们先在Redis库中设置如下几个值

set k1 1 set k2 2 set k3 3 set k4 4 set k5 5  # 操作完成上面的步骤之后我们停止服务器，触发RDB的自动保存save shutdown  # 然后再次启动Redis服务 redis-server redis.conf  # 启动完成，查看我们那些刚刚保存的数据是否被持久化了 keys *

执行完上面的步骤之后，我们可以看到我们的数据都在，就说明我们的触发备份是成功的。

使用flushall模拟数据丢失

该操作有一定的风险性，如果是演示练习按照操作来基本不会出现问题，但是生产上慎重操作。我们做该操作之前，一定要注意先备份RDB对应的持久化问题dump.rdb

# 先备份dump.rdb cp dump.rdb dump.rdb.bak  # 备份完成之后我们确定备份成功在进行下一步操作---清空库 flushall  #