关于redis:redis持久化AOF和RDB的区别分别解决什么场景问题

什么是 Redis 长久化？

长久化就是把内存的数据写到磁盘中去，避免服务宕机了内存数据失落。

Redis 提供了两种长久化形式: RDB（默认）和 AOF。

RDB 快照

rdb 是 Redis DataBase 缩写。

性能外围函数 rdbSave(生成 RDB 文件)和 rdbLoad（从文件加载内存）两个函数。

RBD 长久化通过保留数据库中的键值对来记录数据库状态。

RBD 配置文件的开启

save 900 1      // 900s 内, 有 1 条写入, 则产生快照

save 300 1000   // 如果 300 秒内有 1000 次写入, 则产生快照

save 60 10000  // 如果 60 秒内有 10000 次写入, 则产生快照
(这 3 个选项都屏蔽，则 rdb 禁用)

stop-writes-on-bgsave-error yes  // 后盾备份过程出错时, 主过程是否进行写入

rdbcompression yes    // 导出的 rdb 文件是否压缩。倡议没有必要开启，毕竟 Redis 自身就属于 CPU 密集型服务器，再开启压缩会带来更多的 CPU 耗费，相比硬盘老本，CPU 更值钱。rdbchecksum   yes //  导入 rbd 复原数据时，是否验证 rdb 的完整性

dbfilename dump.rdb  // 导出来的 rdb 文件名

dir ./  //rdb 的搁置门路

RDB 原理

针对 RDB 形式的长久化，手动触发能够应用：

save：会阻塞以后 Redis 服务器，直到长久化实现，线上应该禁止应用。

bgsave：该触发形式会 fork 一个子过程，由子过程负责长久化过程，因而阻塞只会产生在 fork 子过程的时候。

而主动触发的场景次要是有以下几点：

• 依据咱们的 save m n 配置规定主动触发；
• 从节点全量复制时，主节点发送 rdb 文件给从节点实现复制操作，主节点会触发 bgsave；
• 执行 debug reload 时；
• 执行 shutdown 时，如果没有开启 aof，也会触发。

因为 save 根本不会被应用到，咱们重点看看 bgsave 这个命令是如何实现 RDB 的长久化的。

这里留神的是 fork 操作会阻塞，导致 Redis 读写性能降落。咱们能够管制单个 Redis 实例的最大内存，来尽可能升高 Redis 在 fork 时的事件耗费。以及下面提到的主动触发的频率缩小 fork 次数，或者应用手动触发，依据本人的机制来实现长久化。

BGSAVE 命令执行时的服务器状态

首先, 在 BGSAVE 命令执行期间, 客户端发送的 SAVE 命令会被服务器回绝, 服务器禁止 SAVE 命令和 BGSAVE 命令同时执行是为了防止父过程 (服务器过程) 和子过程同时执行两个 rdbSave 调用, 避免产生竞争条件。

其次, 在 BGSAVE 命令执行期间, 客户端发送的 BGSAVE 命令会被服务器回绝, 因为同时执行两个 BGSAVE 命令也会产生竞争条件。

最初, BGREWRITEAOF 和 BGSAVE 两个命令不能同时执行:

• 如果 BGSAVE 命令正在执行, 那么客户端发送的 BGREWRITEAOF 命令会被提早到 BGSAVE 命令执行结束之后执行。
• 如果 BGREWRITEAOF 命令正在执行, 那么客户端发送的 BGSAVE 命令会被服务器回绝。

因为 BGREWRITEAOF 和 BGSAVE 两个命令的理论工作都由子过程执行, 所以这两个命令在操作方面并没有什么抵触的中央, 不能同时执行它们只是一个性能方面的思考 - 并
收回两个子过程, 并且这两个子过程都同时执行大量的磁盘写入操作, 这怎么想都不会是一个好主见。

AOF

Aof 是 Append-only file 缩写。

AOF 长久化通过保留 redis 服务器所执行的写命令来记录数据库状态。

AOF 长久化的实现：

AOF 长久化可分为命令追加、文件写入、文件同步三个步骤。

从长久化中复原数据

RDB 文件的载入工作是在服务器启动时主动执行的, 所以 Redis 并没有专门用于载入 RDB 文件的命令, 只有 Redis 服务器在启动时检测到 RDB 文件存在, 它就会主动载入 RDB 文件。

服务器在载入 RDB 文件期间，会始终处于阻塞状态，直到载入实现。

另外值得一提的是, 因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高, 保留的数据更残缺，AOF 基本上最多损失 1s 的数据。所以:

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

每当执行服务器 (定时) 工作或者函数时 flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作
aof 写入保留：
WRITE：依据条件，将 aof\_buf 中的缓存写入到 AOF 文件
SAVE：依据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保留到磁盘中。
那么这里为什么要先写入 buf 在同步到磁盘呢？如果实时写入磁盘会带来十分高的磁盘 IO，影响整体性能。

aof 重写是为了缩小 aof 文件的大小，能够手动或者主动触发

手动触发：bgrewriteaof，主动触发 就是依据配置规定来触发，当然主动触发的整体工夫还跟 Redis 的定时工作频率有关系。

上面来看看重写的一个流程图：

对于上图有四个关键点补充一下：

1. 在重写期间，因为主过程仍然在响应命令，为了保障最终备份的完整性；因而它仍然会写入旧的 AOF file 中，如果重写失败，可能保证数据不失落。
2. 为了把重写期间响应的写入信息也写入到新的文件中，因而也会为子过程保留一个 buf，避免新写的 file 失落数据。
3. 重写是间接把以后内存的数据生成对应命令，并不需要读取老的 AOF 文件进行剖析、命令合并。
4. AOF 文件间接采纳的文本协定，次要是兼容性好、追加不便、可读性高可认为批改修复。
5. 不论是 RDB 还是 AOF 都是先写入一个临时文件，而后通过 rename 实现文件的替换工作。

Aof 的配置

appendonly no # 是否关上 aof 日志性能
# 文件名称
appendfilename "appendonly.aof"

appendfsync always   # 每 1 个命令, 都立刻同步到 aof. 平安, 速度慢
#appendfsync everysec # 折衷方案, 每秒写 1 次
#appendfsync no      # 写入工作交给操作系统, 由操作系统判断缓冲区大小, 对立写入到 aof. 同步频率低, 速度快,

no-appendfsync-on-rewrite  yes: # 正在导出 rdb 快照的过程中，是否进行同步 aof

auto-aof-rewrite-percentage 100 #aof 文件大小比起上次重写时的大小, 增长率 100% 时, 重写

auto-aof-rewrite-min-size 64mb #aof 文件, 至多超过 64M 时, 才重写

AOF 和 RDB 比拟

1. aof 文件比 rdb 更新频率高，优先应用 aof 还原数据。
2. aof 比 rdb 更平安也更大
3. rdb 性能比 aof 好
4. 如果两个都配了优先加载 AOF

定时工作执行的频率能够在配置文件中通过 hz 10 来设置（这个配置示意 1s 内执行 10 次，也就是每 100ms 触发一次定时工作）。该值最大可能设置为：500，然而不倡议超过：100，因为值越大阐明执行频率越频繁越高，这会带来 CPU 的更多耗费，从而影响主过程读写性能。
定时工作应用的是 Redis 本人实现的 TimeEvent，它会定时去调用一些命令实现定时工作，这些工作可能会阻塞主过程导致 Redis 性能降落。因而咱们在配置 Redis 时，肯定要整体思考一些会触发定时工作的配置，依据理论状况进行调整。