作者：贲绍华

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

本文起源：原创投稿

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

一、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$3SET$3KEY$5VALUE

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

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

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

七、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来比照一下修复前后文件的差异性