【Redis】持久化

文章目录

一、RDB
- 1.1、RDB的自动备份与手动备份
- - 1.1.1、自动备份
  - 1.1.2、手动备份
- 1.2、RDB优点
- 1.3、RDB缺点
- 1.4、RDB快照
- 1.5、RDB优化配置项
二、AOF
- 2.1、AOF工作流程
- 2.2、AOF写回策略
- 2.3、MP-AOF实现
- 2.4、AOF优缺点
- 2.5、AOF重写机制
三、RDB+AOF混合持久化
- 3.1、数据恢复顺序和加载流程
四、纯缓存模式

一、RDB

RDB持久化是以指定的时间间隔，将内存中的数据集快照写入磁盘。其保存的文件是 dump.rdb文件。

1.1、RDB的自动备份与手动备份

1.1.1、自动备份

RDB触发备份
将配置修改如下

save 5 2
dir /myredis/dumpfiles
dbfilename dump.rdb

redis中执行两次操作时会保存一次dump.rdb文件。
此时若使用FLUSHDB，redis会保存空数据到dump.rdb中
此时若使用SHUTDOWN，redis会把当前的数据保存到dump.rdb中

RDB 恢复备份
重启redis时，redis会通过加载redis.conf中的dump.rdb的文件路径来恢复redis数据库。
注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。

1.1.2、手动备份

Redis手动生成了两个命令来生成RDB文件，分别是SAVE和BGSAVE，其中一般使用BGSAVE
由于使用SAVE会在主程序中执行会阻塞当前redis服务器，直到持久化工作完成。执行SAVE命令期间，Redis不能处理其他命令，所以在线上禁止使用SAVE。
使用BGSAVE会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程。
并且还可以使用LASTSAVE命令获取最后一次成功执行快照的时间。

1.2、RDB优点

RDB非常适合灾难恢复，它是一个可以传输到远程数据中心的压缩文件。
RDB最大限度地提高了Redis的性能，因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将所有其余工作都完成的子进程。父进程永远不会执行磁盘I/O或类似操作。
与AOF相比，RDB允许使用大数据集更快地重启。
在副本上，RDB支持重启和故障转移后的部分重新同步。

1.3、RDB缺点

如果Redis由于任何原因没有在正常关闭的情况下停止工作，那最新分钟的数据可能会丢失。
内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能。
RDB需要经常fork()以便使用子进程在磁盘上持久化。如果数据集很大，fork()会很耗时。

1.4、RDB快照

触发RDB快照的操作有：

配置文件中默认的快照配置
手动SAVE/BGSAVE命令
执行FLUSHDB/FLUSHALL命令
执行SHUTDOWN且没有设置开启AOF持久化
主从复制时，主节点自动触发

禁用快照的方法：

动态停止RDB保存规则的方法：redis-cli config set save ""
快照禁用，在配置文件redis.conf中修改save ""

1.5、RDB优化配置项

RDB的优化配置项在配置文件redis.conf的SNAPSHOTTING模块中

save <seconds> <changes>
# 在规定的时间内或者几次修改后自动保存到磁盘dbfilename  # dump.rdb的文件名dir # dump.rdb所在的路径stop-writes-on-bgsave-error
# 默认为yes，在bgsave报错后停止写入
# no表示在快照写入失败时，也能确保redis继续接受新的写请求。rdbcompression
# 对于存储到磁盘的快照是否压缩存储。
# yes，redis会使用LZF算法进行压缩
# no，减少CPU在这方面的消耗rdbchecksum
# 合法性校验
# 默认yes，redis使用CRC64算法进行数据校验
# no，关闭校验，提高性能rdb-del-sync-files
# 默认no，禁用此选项

二、AOF

AOF是以日志形式来记录每个写操作，将Redis执行过的所有写指令记录下来，并且只允许追加文件不允许改写文件，在redis启动的时候读取该文件并且将写指令从前往后执行一遍以完成数据的恢复工作。
默认情况下，redis没有开启AOF，通过appendonly yes来开启。它保存的文件名为appendonly.aof。

2.1、AOF工作流程

在这里插入图片描述

序号	详细步骤
1	客户端会产生请求命令发送至服务端
2	命令到达服务端后，并没有直接写入AOF文件，先保存在AOF缓存中，AOF缓存的目的是当这些命令到达一定数量后再写入磁盘，避免频繁的磁盘IO操作
3	AOF缓存根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘的AOF文件
4	由于AOF文件内容的增加，为了避免膨胀，进行AOF重写完成命令的合并，从而达到AOF文件压缩的目的
5	服务端重启后，会从AOF文件载入数据

2.2、AOF写回策略

AOF有三种写回策略，默认是everysec

配置项	写回时机	优点	缺点
`always`	同步写回	可靠性高、数据不丢失	每个写命令都要写磁盘，IO量大，性能影响较大
`everysec`	每秒写回	性能适中	宕机时丢失1秒内的数据
`no`	由操作系统控制写回	性能好	宕机时丢失的数据较多

2.3、MP-AOF实现

MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件。AOF的类型有：

BASE：基础AOF，由子进程通过重写产生，最多只有一个
INCR：增量AOF，一般会在AOFRW开始执行时创建，可能存在多个
HISTORY：AOFRW成功完成后，所有的BASE和INCR AOF都变成HISTORY，该类型的AOF会被Redis自动删除。

为了管理这些AOF文件，还引入了manifest文件来追踪管理这些AOF，总的来说，Redis7以后的AOF文件结构如下：

// 几种类型文件的前缀，后面跟着有关序列和类型的附加信息
appendfilename "appendonly.aof"//新版本增加的目录配置项目
appenddirname "appendonlydir"//具体文件
1、基本文件appendonly.aof.1.base.aof
2、增量文件appendonly.aof.1.incr.aofappendonly.aof.2.incr.aof
3、清单文件appendonly.aof.manifest

2.4、AOF优缺点

优势

使用AOF Redis更加持久，使用每秒fsync策略既可以保证写入性能，也可以减少redis宕机时丢失的数据。
AOF日志是一个仅附加的日志，因此不会出现寻道问题，也不会在断电时出现损坏问题，即使日志以写一半的命令结尾，redis-check-aof工具也能轻松修复。
Redis能够自动重写AOF，从而减少AOF的磁盘占用空间。
即使使用FLUSHALL命令刷新了所有内容，也可以通过删除AOF中的最新内容来恢复数据。

劣势

AOF文件通常比相同数据集的RDB文件大，回复速度慢于RDB
AOF运行效率低于RDB，每秒同步策略效率好，不同步的话效率和RDB相同。

2.5、AOF重写机制

重写机制通过启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。它并不是对源文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件去替换原来的AOF文件。
触发机制
手动方式通过命令bgrewriteaof命令触发
自动方式通过配置文件的选项触发

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 这里表示被重写的aof文件既要达到之前大小的一倍又要超过64mb才会自动重写

触发重写后，相应AOF文件的序号会增加，例如：

appendonly.aof.1.base.aof
appendonly.aof.1.incr.aof## 变成appendonly.aof.2.base.aof
appendonly.aof.2.incr.aof

重写原理

在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令分析压缩并写入一个临时文件中。
主进程将新接收到的写指令一边累计到内存缓冲区中，一边继续写入到原有的AOF文件中，保证了AOF文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发送一个信号，父进程收到信号后将内存中缓存的写指令追加到新AOF文件中。
追加结束后，redis使用新的aof文件替换旧的aof文件，之后新的写指令都会追加到新的aof文件中。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库用命令的方式重写了一个新的aof文件

三、RDB+AOF混合持久化

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。这种混合方式的具体流程是先使用RDB进行快照存储，然后使用AOF持久化记录所有写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样重启服务的时候会从RDB和AOF两方恢复数据，兼具了数据完整性和性能。
简单来说，混合持久化使得AOF=RDB头部+AOF混写