辛德蕾拉|面试官:Redis缓存了解吗?面对这11道题是否有很多问号?( 五 )


你必须得用 redis 的持久化机制 , 将数据写入内存的同时 , 异步的慢慢的将数据写入磁盘文件里 , 进行持久化 。
如果 redis 宕机重启 , 自动从磁盘上加载之前持久化的一些数据就可以了 , 也许会丢失少许数据 , 但是至少不会将所有数据都弄丢 。
这个其实一样 , 针对的都是 redis 的生产环境可能遇到的一些问题 , 就是 redis 要是挂了再重启 , 内存里的数据不就全丢了?能不能重启的时候把数据给恢复了?
面试题剖析持久化主要是做灾难恢复、数据恢复 , 也可以归类到高可用的一个环节中去 , 比如你 redis 整个挂了 , 然后 redis 就不可用了 , 你要做的事情就是让 redis 变得可用 , 尽快变得可用 。
重启 redis , 尽快让它对外提供服务 , 如果没做数据备份 , 这时候 redis 启动了 , 也不可用啊 , 数据都没了 。
很可能说 , 大量的请求过来 , 缓存全部无法命中 , 在 redis 里根本找不到数据 , 这个时候就死定了 , 出现缓存雪崩问题 。 所有请求没有在redis命中 , 就会去mysql数据库这种数据源头中去找 , 一下子mysql承接高并发 , 然后就挂了…
如果你把 redis 持久化做好 , 备份和恢复方案做到企业级的程度 , 那么即使你的 redis 故障了 , 也可以通过备份数据 , 快速恢复 , 一旦恢复立即对外提供服务 。
redis 持久化的两种方式

  • RDB:RDB 持久化机制 , 是对 redis 中的数据执行周期性的持久化 。
  • AOF:AOF 机制对每条写入命令作为日志 , 以 append-only 的模式写入一个日志文件中 , 在 redis重启的时候 , 可以通过回放 AOF 日志中的写入指令来重新构建整个数据集 。
通过 RDB 或 AOF , 都可以将 redis 内存中的数据给持久化到磁盘上面来 , 然后可以将这些数据备份到别的地方去 , 比如说阿里云等云服务 。
如果 redis 挂了 , 服务器上的内存和磁盘上的数据都丢了 , 可以从云服务上拷贝回来之前的数据 , 放到指定的目录中 , 然后重新启动 redis , redis 就会自动根据持久化数据文件中的数据 , 去恢复内存中的数据 , 继续对外提供服务 。
如果同时使用 RDB 和 AOF 两种持久化机制 , 那么在 redis 重启的时候 , 会使用 AOF 来重新构建数据 , 因为 AOF 中的数据更加完整 。
RDB 优缺点
  • RDB 会生成多个数据文件 , 每个数据文件都代表了某一个时刻中 redis 的数据 , 这种多个数据文件的方式 , 非常适合做冷备 , 可以将这种完整的数据文件发送到一些远程的安全存储上去 , 比如说 Amazon的 S3 云服务上去 , 在国内可以是阿里云的 ODPS 分布式存储上 , 以预定好的备份策略来定期备份 redis中的数据 。
  • RDB 对 redis 对外提供的读写服务 , 影响非常小 , 可以让 redis 保持高性能 , 因为 redis 主进程只需要 fork 一个子进程 , 让子进程执行磁盘 IO 操作来进行 RDB 持久化即可 。·
  • 相对于 AOF 持久化机制来说 , 直接基于 RDB 数据文件来重启和恢复 redis 进程 , 更加快速 。
  • 如果想要在 redis 故障时 , 尽可能少的丢失数据 , 那么 RDB 没有 AOF 好 。 一般来说 , RDB 数据快照文件 , 都是每隔 5 分钟 , 或者更长时间生成一次 , 这个时候就得接受一旦 redis 进程宕机 , 那么会丢失最近 5 分钟的数据 。
  • RDB 每次在 fork 的进程来执行 RDB 快照数据文件生成的时候 , 如果数据文件特别大 , 可能会导致对客户端提供的服务暂停数毫秒 , 或者甚至数秒 。
AOF 优缺点