什么是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快照的过程中，是否进行同步aofauto-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时，肯定要整体思考一些会触发定时工作的配置，依据理论状况进行调整。