关于redis:Redis第七章节持久化

1次阅读

共计 2989 个字符，预计需要花费 8 分钟才能阅读完成。

概述
RDB
AOF
如何抉择长久化机制

Redis 是内存数据库，如果不能将内存中的数据保留到磁盘中，那么一旦服务器过程退出，服务器的数据库数据也会隐没，所以 Redis 提供了长久化的性能,redis 分为两种长久化形式：RDB和AOF。有以下几个特点：

1.RDB 长久化形式可能在指定的工夫距离能对你的数据进行快照存储。
2.AOF 长久化形式记录每次对服务器写的操作，当服务器重启的时候会从新执行这些命令来复原原始的数据，AOF 命令以 redis 协定追加保留每次写的操作到文件开端。Redis 还能对 AOF 文件后盾重写，使得 AOF 文件的体积不至于过大。
3. 如果你只心愿你的数据在服务器运行的时候存在，你也能够不应用任何长久化的形式。
4. 你也能够同时开启两种长久化形式，在这种状况下，当 redis 重启的时候会优先载入 AOF 文件来复原原始的数据。因为在通常状况下 AOF 文件保留的数据集要比 RDB 文件保留的数据集要残缺。

1、概念

在指定的工夫距离内将内存中的数据集快照写入磁盘中，它复原的时候是将快照中的文件间接读取到内存中。

2、长久化机制 -BGSAVE

通常，会立刻返回 ok,Redis 过程会执行 fork 操作创立子过程，Redis 在 fork 时，父过程会持续为客户端提供服务，子过程会将数据长久化到硬盘上，而后退出。如果曾经在后盾执行保留或者正在运行另一个非后盾保留的过程，特地是正在进行 AOF 写入时，则会返回谬误。如果应用了 bgsave 工作，而正在进行 AOF 写入时，该命令将立刻返回 ok, 并打算在下一次机会运行后盾保留。阻塞只会在 fork 阶段。
客户端能够应用 lastsave 命令查看操作是否胜利。

3、长久化机制 -SAVE

不会承受客户端执行的操作命令，等长久化工作实现之后，会将新的文件替换旧的文件。

4、长久化机制 - 主动触发

在 redis.conf 中能够配置，让用户自定义 save 属性，让服务器每一段时间内执行一次 bgsave 操作。

  # 服务器在 900 秒内，对数据库进行了至多 1 次批改
  save 900 1
  
  # 服务器在 300 秒内，对数据库进行了至多 10 次批改
  save 300 10
  
  # 服务器在 60 秒内，对数据库进行了至多 10000 次批改
  save 60 10000
  
  # bgsave 产生谬误时是否进行写入，个别为 yes
  stop-writes-on-bgsave-error yes
  
  # 长久化时是否应用 LZF 压缩字符串对象?
  rdbcompression yes
  
  # 是否对 rdb 文件进行校验和测验，通常为 yes
  rdbchecksum yes
  
  # RDB 长久化文件名
  dbfilename dump.rdb
  
  # 长久化文件存储目录
  dir ./

5、复原数据机制

只须要将 rdb 文件放在咱们 redis 启动目录就能够了，redis 启动的时候会主动查看文件并复原其中的数据。

6、长处

RDB 是一个十分紧凑的文件，它保留了某个工夫点得数据集，十分实用于数据集的备份，比方你能够在每个小时报保留一下过来 24 小时内的数据，同时每天保留过来 30 天的数据，这样即便出了问题你也能够依据需要复原到不同版本的数据集。
RDB 是一个紧凑的繁多文件，很不便传送到另一个远端数据中心或者亚马逊的 S3（可能加密），十分实用于劫难复原。
RDB 在保留 RDB 文件时父过程惟一须要做的就是 fork 出一个子过程，接下来的工作全副由子过程来做，父过程不须要再做其余 IO 操作，所以 RDB 长久化形式能够最大化 redis 的性能。
与 AOF 相比，在复原大的数据集的时候，RDB 形式会更快一些。

7、毛病

如果你心愿在 redis 意外进行工作（例如电源中断）的状况下失落的数据起码的话，那么 RDB 不适宜你。尽管你能够配置不同的 save 工夫点(例如每隔 5 分钟并且对数据集有 100 个写的操作)，是 Redis 要残缺的保留整个数据集是一个比拟沉重的工作，你通常会每隔 5 分钟或者更久做一次残缺的保留，万一在 Redis 意外宕机，你可能会失落几分钟的数据。
RDB 须要常常 fork 子过程来保留数据集到硬盘上，当数据集比拟大的时候，fork 的过程是十分耗时的，可能会导致 Redis 在一些毫秒级内不能响应客户端的申请。如果数据集微小并且 CPU 性能不是很好的状况下，这种状况会继续 1 秒，AOF 也须要 fork，然而你能够调节重写日志文件的频率来进步数据集的耐久度。

1、概念

以日志的模式来记录每个写操作，将 Redis 执行过的所有指令记录下来（读操作不记录），只许追加文件但不能够改写文件，Redis 启动之初会读取该文件从新构建数据，换言之，Redis 重启的话就会依据日志文件的内容将写的指令从前到后执行一次以实现数据的复原工作。

2、长久化原理

所有操作的命令会追加在文件中。

3、开启 AOF 长久化

   
   # 开启 aof 长久化形式，默认 no
   appendonly no
   
   # aof 长久化生成的文件名称
   appendfilename "appendonly.aof"
   
   # 三种长久化机制
   # appendfsync always
   appendfsync everysec
   # appendfsync no

4、三种触发长久化机制

always

同步长久化，每次产生数据变更会被立刻长久化到硬盘中，性能比拟差，然而数据完整性好。

everysec

异步操作，每秒长久化数据到硬盘一次，可能会失落一秒的数据。

no

从不长久化到硬盘。

5、AOF 文件损坏

如果 aof 文件被毁坏，redis 服务是启动不了的。redis 自身提供了修复了工具。redis-check-aof --fix appendonly.aof

5、长处

依据配置不同的策略，让你抉择长久化的形式。
AOF 文件是一个只进行追加的日志文件，所以不须要写入 seek，即便因为某些起因 (磁盘空间已满，写的过程中宕机等等) 未执行残缺的写入命令，你也也可应用 redis-check-aof 工具修复这些问题。
Redis 能够在 AOF 文件体积变得过大时，主动地在后盾对 AOF 进行重写：重写后的新 AOF 文件蕴含了复原以后数据集所需的最小命令汇合。整个重写操作是相对平安的，因为 Redis 在创立新 AOF 文件的过程中，会持续将命令追加到现有的 AOF 文件外面，即便重写过程中产生停机，现有的 AOF 文件也不会失落。而一旦新 AOF 文件创建结束，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保留了对数据库执行的所有写入操作，这些写入操作以 Redis 协定的格局保留，因而 AOF 文件的内容非常容易被人读懂，对文件进行剖析（parse）也很轻松。导出（export）AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只有 AOF 文件未被重写，那么只有进行服务器，移除 AOF 文件开端的 FLUSHALL 命令，并重启 Redis，就能够将数据集复原到 FLUSHALL 执行之前的状态。

6、毛病

对于雷同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
依据所应用的 fsync 策略，AOF 的速度可能会慢于 RDB。在个别状况下，每秒 fsync 的性能仍然十分高，而敞开 fsync 能够让 AOF 的速度和 RDB 一样快，即便在高负荷之下也是如此。不过在解决微小的写入载入时，RDB 能够提供更有保障的最大延迟时间（latency）。

开启两种长久化形式，依据本人的业务需要针对 redis 进行配置的调整。

正文完