【一图流思维导图】Redis的持久化机制 RDB与AOF RDB文件创建、载入 AOF实现、载入、重写

参考 阿里二面：熟悉Redis？讲讲你理解的Redis的持久化机制(RDB、AOF)

Redis的持久化机制

背景

Redis是内存数据库

一旦Redis进程退出或者计算机停机

Redis服务器中的数据就会丢失

为了避免数据丢失，所以Redis提供了持久化机制

将存储在内存中的数据保存到磁盘中

用于快速的恢复之前Redis存储在内存中的数据

RDB持久化

RDB持久化是将某个时间点上Redis内存中的数据保存到一个RDB文件中

DB持久化也叫做快照持久化

1 创建RDB文件

• SAVE

  • 会阻塞Redis服务器进程

• BGSAVE

  • 会派生出一个子进程
  • 由子进程负责创建RDB文件
  • 服务器进程（父进程）继续处理命令请求

• SAVE默认条件

  • save 900 1

    • 服务器在900s（即15分钟）之内，
      对数据库进行了至少1次修改

  • save 300 10

    • 服务器在300s（即5分钟）之内，
      对数据库进行了至少10次修改

  • save 60 10000

    • 服务器在60s（即1分钟）之内，
      对数据库进行了至少10000次修改

• 只要满足以下3个条件中的任意1个，BGSAVE命令就会被执行：

2 载入RDB文件

• Redis服务器启动时自动执行的

• 取决于服务器是否启用了AOF持久化功能

  • 只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据。
  • 如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据

• 默认情况下，Redis服务器的AOF持久化功能是关闭的

3 服务器状态

• 说明

  • 创建和载入RDB文件，可能存在的服务器状态有以下3种

• 当执行SAVE命令时

  • Redis服务器会被阻塞，此时客户端发送的所有命令请求都会被阻塞

• 当执行BGSAVE命令时

  • Redis服务器不会被阻塞，Redis服务器仍然可以继续处理客户端发送的命令请求

• 服务器在载入RDB文件期间

  • 会一直处于阻塞状态，直到RDB文件载入成功。

AOF持久化

AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库数据的

默认情况下，AOF持久化功能是关闭的

• appendonly yes

  • appendonly.aof

1 AOF持久化的实现

• Redis服务器在执行完一个写命令之后

• 会以协议格式,将被执行的写命令追加到服务器状态的AOF缓冲区的末尾

• 服务器会根据配置文件中appendfsync选项的值

• 来决定何时将AOF缓冲区中的内容写入和同步到AOF文件里面

• appendfsync 3个值

  • always

    • always是最安全的
    • always的效率最慢
    • 每个事件循环都要将AOF缓冲区中的所有内容写入到AOF文件，并且同步AOF文件。

  • everysec

    • 数据库只会丢失一秒钟的命令数据
    • everysec模式足够快

  • no

    • 不确定性

      • 如果出现故障停机，数据库会丢失上次同步AOF文件之后的所有写命令数据
      • 务器在每个事件循环都要将AOF缓冲区中的所有内容写入到AOF文件
      • 由操作系统控制,何时对AOF文件进行同步

  • 推荐使用这个值 everysec 默认

2 载入AOF文件

• AOF文件包含了重建数据库所需的所有写命令

• edis服务器只要读入并重新执行一遍AOF文件里面保存的写命令

• 就可以还原Redis服务器关闭之前的数据

• Redis文件还原数据库步骤

  • 创建一个不带网络连接的伪客户端

    • 来执行AOF文件保存的写命令。

  • 从AOF文件中分析并读取出一条写命令。

  • 使用伪客户端执行被读取出的写命令。

  • 一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被执行完毕。

• 开启了AOF持久化功能

  • 启动时会载入AOF文件

3 AOF重写

• 随着Redis服务器运行时间的增加，AOF文件中的内容会越来越多，文件的体积会越来越大

• 如果不做控制，会有以下2点坏处

• 坏处

  • 过多的占用服务器磁盘空间，可能会对Redis服务器甚至整个宿主计算机造成影响。
  • AOF文件的体积越大，使用AOF文件来进行数据库还原所需的时间就越多。

• AOF文件重写功能

  • 创建一个新的AOF文件来替代现有的AOF文件
  • 新旧两个AOF文件所保存的数据库数据相同
  • 新AOF文件不会包含任何浪费空间的冗余命令
  • 结果上看，新AOF文件的体积通常会比旧AOF文件的体积要小很多

• AOF重写的实现原理

  • AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作

  • 通过读取服务器当前的数据库数据来实现的

  • 步骤

    • 从数据库中读取键现在的值
    • 然后用一条命令去记录键值对
    • 代替之前记录这个键值对的多条命令

• AOF后台重写

  • Redis将AOF文件重写功能放到子进程里执行

  • 有以下2个好处

    • 子进程进行AOF文件重写期间，服务器进程（父进程）可以继续处理命令请求。

    • 子进程带有服务器进程的数据副本

      • 使用子进程而不是线程
      • 可以在避免使用锁的情况下，
        保证数据的安全性

  • 几个概念

    • AOF缓冲区

      • 为了同步到原有的AOF文件

    • AOF重写缓冲区

      • 子进程在进行AOF文件重写期间，
        服务器进程还在继续处理命令请求
      • 防止数据库数据丢失

  • 命令

    • 手动

      • BGREWRITEAOF

    • 配置

      • auto-aof-rewrite-percentage 100

        • AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）

      • auto-aof-rewrite-min-size 64mb

        • 当AOF文件的体积大于64MB

      • 上面两个条件都成立，Redis将自动执行BGREWRITEAOF命令。

两种持久化的区别

实现方式

• RDB

  • 快照

• AOF

  • 保存执行的所有写命令

文件体积

• RDB

  • 记录的是结果

• AOF

  • 记录的是过程

    • 体积越来越大
    • 通过AOF重写功能来减小AOF文件体积

安全性

• RDB

• AOF

  • 安全性更高
  • 丢失的数据要少

优先级

• RDB

• AOF

  • 开启了AOF ，服务器启动时会使用AOF文件来还原数据

XMind - Trial Version