乐趣区

关于redis:对比-Redis-中-RDB-和-AOF-持久化

jiezi

概念

Redis 是内存数据库，数据存储在内存中，一旦服务器过程退出，数据就失落了，所以 Redis 须要想方法将存储在内存中的数据长久化到磁盘。

Redis 提供了两种长久化性能：

  1. RDB (Redis Database)：生成 RDB 文件，保留的是 key-value 的模式。
  2. AOF (Append Only File)：保留 Redis 执行过程中的写命令。

生成

RDB 的生成

  1. SAVE 命令会阻塞 Redis 服务过程，直到 RDB 文件创建结束为止，在服务器过程阻塞期间，服务器不能解决任何命令申请。
  2. BGSAVE 命令会派生出一个子过程，而后由子过程负责创立 RDB 文件，服务器过程（父过程）持续解决命令申请。

如果两个 key 值的批改具备事务性，须要手动加事务，不然备份时可能会导致两个值不统一。

除了被动执行命令，咱们还能够通过 save 选项设置多个保留条件，只有任意一个条件满足，服务器就会执行 BGSAVE 命令：

save 900 1
save 300 10
save 60 10000

那么只有满足以下三个条件中的任意一个，BGSAVE 命令就会被执行：

  1. 服务器在 900 秒之内，对数据库进行了至多 1 次批改。
  2. 服务器在 300 秒之内，对数据库进行了至多 10 次批改。
  3. 服务器在 60 秒之内，对数据库进行了至多 10000 次批改。

AOF 的生成

只有关上 AOF 长久化性能，服务器在执行完一个写命令后，会以协定格局将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的开端。

古代操作系统中，用户在写文件时，操作系统通常会将写入数据临时保留在一个内存缓冲区外面，等到缓冲区被填满，或者超过了指定时限之后，才真正将缓冲区中的数据写入磁盘。这就有可能导致缓冲区内的数据还未写入磁盘，计算机产生停机，导致数据失落。

appendfsync 选项的值能够决定 AOF 长久化性能的效率和安全性：

  1. always 每次都同步到磁盘，效率低，安全性高；
  2. everysec 每隔一秒同步到磁盘，效率足够快，安全性高，只失落一秒的数据；
  3. no 由操作系统管制同步到磁盘的机会，速度最快，安全性最低。

AOF 的重写

因为 AOF 保留的是写命令，随着服务器的运行，同一个键值被操作的次数越多，单个键值就会产生多条写命令，AOF 文件就会越大，还原的工夫就会越久。

为了解决 AOF 体积收缩的问题，Redis 提供了 AOF 文件重写（rewrite）性能。

AOF 重写并不是对旧的 AOF 文件进行压缩。Redis 会从数据库中读出数据，生成对应的写命令，并写入新的 AOF 文件中，当新的 AOF 文件重写了所有数据的写命令，就能够替换掉旧 AOF 文件。

AOF 重写能够在后盾进行，在重写过程中新产生的数据，会写入 AOF 重写缓冲区中，当重写完结再把缓冲区的写命令追加到新的 AOF 文件中即可。

载入

RDB 的载入

RDB 文件的载入工作是在服务器启动时主动执行的，所以 Redis 没有专门用于载入的命令。

因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，所以：

  1. 如果服务器启动了 AOF 长久化性能，那么服务器会优先应用 AOF 文件来还原数据库状态。
  2. 只有在 AOF 长久化性能处于敞开状态时，服务器才会应用 RDB 文件来还原数据库状态。

AOF 的载入

AOF 中蕴含了所有的写命令，服务器只有读入并从新执行一遍 AOF 文件里保留的写命令，就能够还原服务器敞开前的状态。

Redis 读取 AOF 文件并还原数据库状态的具体步骤：

  1. 创立一个不带网络连接的伪客户端：因为 Redis 的命令只能在客户端上下文中执行，而载入 AOF 文件时所应用的命令间接来源于 AOF 文件而不是网络连接，所以用来还原数据的伪客户端不须要网络连接；
  2. 从 AOF 文件中剖析并读取出一条写命令；
  3. 应用伪客户端执行读出的写命令；
  4. 循环执行步骤 2 和步骤 3，直到 AOF 文件中的所有命令都被执行。

材料

Redis 设计与实现 - 黄健宏 - 微信读书

本文首发于我的集体博客 https://chaohang.top

作者张小超

转载请注明出处

欢送关注我的微信公众号【超超不会飞】，获取第一工夫的更新。

退出移动版