Redis数据长久化

Redis作为一个内存数据库，数据是以内存为载体存储的，即断电即失（一旦Redis服务器过程退出，服务器中的数据也会隐没）。为了解决这个问题，Redis提供了长久化机制，也就是把内存中的数据保留到磁盘当中，防止数据意外失落

Redis提供了两种长久化计划：RDB长久化和AOF长久化，一个是快照的形式，一个是相似日志追加、历史记录的形式

一、RDB（Redis DataBase）

RDB是快照长久化，即通过快照SnapShot的形式，在指定的工夫距离内将内存中的数据集快照写入磁盘。在创立快照之后，用户能够备份该快照，能够将快照复制到其余服务器以创立雷同数据的服务器正本，或者在重启服务器后复原数据。RDB是Redis默认的长久化形式

RDB长久化会生成rdb文件，该文件是一个压缩过的二进制文件，能够通过该文件还原快照时的数据库状态，即生成该rdb文件时的服务器数据。rdb文件默认为当前工作目录下的dump.rdb，能够依据配置文件redis.conf中SNAPSHOTTING局部的dbfilename和dir设置rdb的文件名和文件地位。默认其实能够不须要改变。只有dump.rdb文件在redis的启动目录下，redis启动的时候就会主动查看dump.rdb复原数据。

# 设置 dump 的文件名dbfilename dump.rdb# 工作目录# 例如下面的 dbfilename 只指定了文件名，# 然而它会写入到这个目录下。这个配置项肯定是个目录，而不能是文件名。dir ./

获取redis装置目录

127.0.0.1:6379> config get dir1) "dir"2) "/usr/local/bin" #如果在这个目录下存在dump.rdb文件，启动redis就会主动复原数据

1、快照触发机会：

  • 执行save和bgsave命令
  • 配置文件中save <seconds> <changes>规定，主动间隔性执行bgsave命令，如下图

示意在seconds秒内，至多有changes次变动，就会主动触发gbsave命令

  • 主从复制时，从库全量复制同步主库数据，主库会执行bgsave
  • 执行flushall命令清空服务器数据
  • 执行shutdown命令敞开Redis时，默认会执行save命令（能够手动shutdown nosave就不执行save命令）

2、save和bgsave命令：

执行save和bgsave命令，能够手动触发快照，生成rdb文件，两者的区别如下

应用save命令会阻塞Redis服务器过程，服务器过程在rdb文件创建实现之前是不能解决任何的命令申请

127.0.0.1:6379> saveOK复制代码

而应用bgsave命令不同的是，bgsave命令会fork一个子过程，而后该子过程会负责创立rdb文件，而服务器过程会持续解决命令申请。

fork()是由操作系统提供的函数，作用是创立以后过程的一个正本作为子过程

fork一个子过程，子过程会把数据集先写入临时文件，写入胜利之后，再替换之前的rdb文件，用二进制压缩存储，这样能够保障rdb文件始终存储的是残缺的长久化内容

【补充】

在生产环境中，通常咱们会将dump.rdb文件进行备份。

3、优缺点

长处：

  • 适宜大规模的数据恢复
  • 对数据完整性和一致性要求不高

毛病：

  • 在肯定间隔时间做一次备份，如果redis意外宕机，会丢掉最初一次快照后的所有批改
  • RDB应用fork()产生子过程进行数据的长久化，如果数据比拟大的话可能就会破费点工夫，造成Redis进行服务几毫秒。如果数据量很大且CPU性能不是很好的时候，进行服务的工夫甚至会到1秒。

二、AOF（Append Only File）

AOF长久化会把被执行的写命令写到AOF文件的开端，记录数据的变动。默认状况下，Redis是没有开启AOF长久化的，开启后，每执行一条更改Redis数据的命令，都会把该命令追加到AOF文件中，这就相当于是把redis执行过的所有指令记录下来（读操作不记录），有点相似历史记录，复原数据时将这个文件全副执行一遍。这会升高Redis的性能，但大部分状况下这个影响是可能承受的，另外应用较快的硬盘能够进步AOF的性能。AOF保留的是appendonly.aof文件

在配置文件中redis.conf开启AOF和对于AOF的配置操作：

# appendonly参数开启AOF长久化，默认是noappendonly no# AOF长久化的文件名，默认是appendonly.aofappendfilename "appendonly.aof"# AOF文件的保留地位和RDB文件的地位雷同，都是通过dir参数设置的dir ./# 同步策略# appendfsync always 示意每次写入都执行fsync，以保证数据同步到磁盘。appendfsync everysec #示意每秒执行一次fsync，可能会导致失落这1s数据。# appendfsync no 示意不执行fsync，由操作系统保证数据同步到磁盘，速度最快。# aof重写期间是否同步,默认no即可，保障数据安全no-appendfsync-on-rewrite no# 重写触发配置，设置重写的基准值auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb# 加载aof出错如何解决aof-load-truncated yes# RDB和AOF的混合长久化aof-use-rdb-preamble yes# 文件重写策略aof-rewrite-incremental-fsync yes

1、AOF的实现

AOF须要记录Redis的每个写命令，步骤为：命令追加（append）、文件写入（write）和文件同步（sync）

命令追加(append)

开启AOF长久化性能后，服务器每执行一个写命令，都会把该命令以协定格局先追加到aof_buf缓存区的开端，而不是间接写入文件，防止每次有命令都间接写入硬盘，缩小硬盘IO次数

文件写入(write)和文件同步(sync)

对于何时把aof_buf缓冲区的内容写入保留在AOF文件中，Redis提供了多种策略

  • appendfsync always：将aof_buf缓冲区的所有内容写入并同步到AOF文件，每个写命令都同步写入磁盘
  • appendfsync everysec：将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操作由一个线程专门负责
  • appendfsync no：将aof_buf缓存区的内容写入AOF文件，什么时候同步由操作系统来决定

appendfsync选项的默认配置为everysec，即每秒执行一次同步

对于AOF的同步策略是波及到操作系统的write函数和fsync函数的，在《Redis设计与实现》中是这样阐明的

为了进步文件写入效率，在古代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。

这样的操作尽管进步了效率，但也为数据写入带来了平安问题：如果计算机停机，内存缓冲区中的数据会失落。为此，零碎提供了fsync、fdatasync同步函数，能够强制操作系统立即将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

从下面的介绍咱们晓得，咱们写入的数据，操作系统并不一定会马上同步到磁盘，所以Redis才提供了appendfsync的选项配置。

  • 当该选项时为appendfsync always时，数据安全性是最高的，然而会对磁盘进行大量的写入，Redis解决命令的速度会受到磁盘性能的限度；
  • appendfsync everysec选项则兼顾了数据安全和写入性能，以每秒一次的频率同步AOF文件，即使呈现零碎解体，最多只会失落一秒内产生的数据；
  • 如果是appendfsync no选项，Redis不会对AOF文件执行同步操作，而是有操作系统决定何时同步，不会对Redis的性能带来影响，但如果零碎解体，可能会失落不定数量的数据

2、AOF重写

随着工夫的推移，Redis执行的写命令会越来越多，AOF文件也会越来越大，过大的AOF文件可能会对Redis服务器造成影响，如果应用AOF文件来进行数据还原所需工夫也会越长。因而为避免出现此种状况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留能够复原数据的最小指令集。

文件重写能够主动触发也能够手动触发执行bgrewriteaof 命令

主动触发会依据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size 64mb配置来主动执行bgrewriteaof命令

# 示意当AOF文件的体积大于64MB，且AOF文件的体积比上一次重写后的体积大了一倍（100%）时，会执行`bgrewriteaof`命令auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

手动触发执行bgrewriteaof，该命令的执行跟bgsave触发快照时相似的，都是先fork一个子过程做具体的工作

执行bgrewriteaof命令，重写的流程：

  • 重写会有大量的写入操作，所以服务器过程会fork一个子过程来创立一个新的AOF文件
  • 在重写期间，服务器过程持续解决命令申请，如果有写入的命令，追加到aof_buf的同时，还会追加到aof_rewrite_bufAOF重写缓冲区
  • 当子过程实现重写之后，会给父过程一个信号，而后父过程会把AOF重写缓冲区的内容写进新的AOF临时文件中，再对新的AOF文件改名实现替换，这样能够保障新的AOF文件与以后数据库数据的一致性

3、Redis4.0开始反对RDB和AOF的混合长久化

能够通过配置项 aof-use-rdb-preamble 开启，默认就是yes开启的

  • 如果是redis过程挂掉，那么重启redis过程即可，间接基于AOF日志文件复原数据
  • 如果是redis过程所在机器挂掉，那么重启机器后，尝试重启redis过程，尝试间接基于AOF日志文件进行数据恢复，如果AOF文件破损，那么用redis-check-aof fix命令修复
  • 如果没有AOF文件，会去加载RDB文件
  • 如果redis以后最新的AOF和RDB文件呈现了失落/损坏，那么能够尝试基于该机器上以后的某个最新的RDB数据正本进行数据恢复

4、优缺点

长处：

  • 数据更残缺，安全性更高，秒级数据失落（取决fsync策略，如果是everysec，最多失落1秒的数据）
  • AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协定的格局保留的，内容是可读的，适宜误删紧急复原

毛病：

  • 对于雷同的数据集，AOF文件的体积要大于RDB文件，数据恢复也慢于rdb
  • 依据所应用的 fsync 策略，AOF 的速度可能会慢于 RDB。

参考：

1、https://juejin.im/post/684490... Redis长久化机制：RDB和AOF TurboSnail