乐趣区

关于redis:技术分享-Redis-持久化之-RDB-与-AOF

作者:贲绍华

爱可生研发核心工程师,负责我的项目的需要与保护工作。其余身份:柯基铲屎官。

本文起源:原创投稿

* 爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。


一、RDB(Redis Database)简介

RDB 长久化形式可能在指定的工夫距离内(N 秒内有 M 次改变时),对实例的数据进行快照存储,也就是全备的意思。

二、RDB – 个性

2.1 长处

  • 繁多文件,不便传输,适宜灾备;
  • 复原大数据集时效率会比 AOF 快一些;
  • 备份时会由 fork 出的子过程操作,父过程不须要其余 IO 操作,性能绝对 AOF 来说占优。

2.2 毛病

  • 在距离其间发生意外宕机,会造成数据大量失落;
  • 数据量十分大时 fork 子过程十分耗时,可能会影响业务失常响应。

三、RDB – 策略

RDB 的备份触发形式有两种类型,五种触发条件,别离为:

3.1 主动触发

  • 依据 conf 内配置的 save 规定进行保留;
  • 执行 FLUSHALL(删除所有数据库外面的所有数据)命令会触发;
  • 被动退出 Redis 会触发。

3.2 手动触发

  • SAVE「同步执行」(保留数据至磁盘);
  • BGSAVE「异步执行」(保留数据至磁盘)。

3.3 操作流程

1.fork 一个子过程, 创立子过程时并不会产生数据复制,进步了复制速度升高了所需空间大小(内核级的零碎调用:fork());

2. 子过程取得所有数据指向地址的指针;

3. 此时如有数据持续减少则触发写时复制,父过程指向新值地址,子过程仍旧指向原值地址(COW(copy-on-write 写时复制));

4. 将指针指向的值写入备份;

5. 备份实现。

四、RDB – 配置

| 配置项 | 阐明 |
| — | — |
| save | N 秒内有 M 次改变时保留(触发的是 BGSAVE 异步执行)|
| stop-writes-on-bgsave-error | 快照出错时是否禁止写入操作 |
| rdbcompression | 是否压缩 RDB 文件 |
| rdbchecksum | 是否开启 RC64 校验 |
| dbfilenameRDB | 文件保留名称 |
| dirRDB | 文件保留目录 |

五、RDB – 其余

5.1 时点性

当 Redis 在指定工夫点触发全备时如果尔后数据库仍然有批改,则值还是会保留在未修改前的工夫点,这样保障了不会产生时点凌乱。

5.2 阈值倡议

倡议 Redis 应用内存管制在 10-15G 以内,过大的话会影响 RDB 落盘的速度。

5.3 RDB 文件损坏该怎么办

在 Redis 的装置目录内,提供了 redis-check-rdb 工具用于对损坏的备份文件进行修复。

六、AOF(Append Only File)简介

AOF 长久化形式即增备,记录每次对服务器写的操作,当服务器重启的时候会从新执行这些命令来复原原始的数据。

AOF 命令以 redis 协定追加保留每次写的操作到文件开端。Redis 还能对 AOF 文件进行重写压缩,使得 AOF 文件的体积不至于过大。

6.1 AOF 文件协定

上面列举一段 AOF 文件内容进行阐明:

# 假如此时客户端执行了语句 SET KEY VALUE,则 AOF 内容如下
*3
$3
SET
$3
KEY
$5
VALUE

上述内容中,看似比拟芜杂,但了解一下其实很简略

* 示意跳过 $ 行时,往下一次读几行

$ 示意下一行有多少个字符

七、AOF – 个性

7.1 长处

  • 异样宕机损失较小,可能做到数据不失落或最多失落 1 秒

7.2 毛病

  • 比照 RDB 在复原数据的效率上体现不高
  • AOF 文件会比 RDB 文件更大
  • 依据所应用的 fsync 策略不同,AOF 的速度可能会慢于 RDB

八、AOF – 策略

AOF 同样分为两种触发形式,依据配置项 appendfsync(AOF 长久化策略)的不同对应的执行机会也不同:

8.1 主动触发

  • no(从不 fsync,buffer 写满了就落盘,速度快)
  • everysec「默认」(每一秒保留一次)
  • always(每次都 fsync,速度慢,可靠性高)

8.2 手动触发

BGREWRITEAOF「异步执行」(重写 AOF 文件)

九、AOF – 配置

| 配置项 | 阐明 |
| — | — |
| appendonly | 是否开启 AOF |
| AOFappendfilename | AOF 文件名 |
| appendfsync | AOF 长久化策略 |
| no-appendfsync-on-rewrite | 在写入时是否对新记录暂缓追加 |
| auto-aof-rewrite-percentage | AOF 文件增长比例 |
| auto-aof-rewrite-min-size | 文件重写文件大小 |
| aof-load-truncated | 是否开端异样的 AOF 文件 |
| aof-use-rdb-preamble | 是否应用 RDB-AOF 混合长久化模式(4.0 版本之后)
在开启了这个性能之后,AOF 重写产生的文件将同时蕴含 RDB 格局的内容和 AOF 格局的内容,其中 RDB 格局的内容用于记录已有的数据,而 AOF 格局的内存则用于记录最近产生了变动的数据,这样 Redis 就能够同时兼有 RDB 长久化和 AOF 长久化的长处(既可能疾速地生成重写文件,也可能在呈现问题时,疾速地载入数据)产生重写之后能力变成混合体 |

十、AOF – 其余

10.1 AOF 重写的版本差异性

  • 4.0 之前:删除能够互相对消的命令,合并反复命令
  • 4.0 之后:先将内存数据都数据成 RDB,后续操作仍旧记录成 AOF

10.2 AOF 文件损坏了该怎么办

因为是增备,在数据继续写入时遇到意外宕机时很容易造成 AOF 文件的损坏,此时重启 Redis 实例会无奈载入该文件。

解决的形式如下:

1. 定时备份 AOF 文件

2. 在 Redis 的装置目录中,提供了 redis-check-aof 工具用于修复异样的 AOF 文件,能够在修复实现后 diff - u 来比照一下修复前后文件的差异性

退出移动版