Redis之Redis持久化
一、概述
Redis（Remote Dictionary Server）是一个可持久化的内存、Key-Value数据库。
Redis自带持久化功能，用于将内存中的数据同步到磁盘，防止服务器断电或宕机导致数据丢失。
Redis支持两种持久化方式：
- RDB（redis database）
- AOF（append only file）。
二、持久化方式
2.1、关闭持久化配置
- 修改配置文件方式
vi redis.conf
## 禁用RDB
save ""
## 禁用AOF
appendonly no
:wq
- 命令文件方式
redis-cli config set value ""
2.2、RDB （redis database）
2.2.1、是什么
概念：在指定的时间间隔内将内存中的数据集快照（Snapshot）写入磁盘(dump.rdb)，待服务重启时，将快照文件读入内存中。
原理：在执行持久化时，redis使用Fork的方式单独创建一个进程来进程持久化，该进程会先将内存中的数据写入到一个临时文件中，待持久化结束时，用此临时文件替换掉上次持久化保存的文件（dump.rdb）。
Fork原理：复制一个与当前进程一样的进程，新进程的所有数据都与原进程一样，但是一个全新的进程，并作为原进程的子进程。
2.2.2、配置方式
vi redis.conf
## 3600秒内1次、300秒内60次、60秒内10000次，则触发RDB
save 3600 1 300 100 60 10000
## 指定 dump.rdb 文件存储目录，默认：./ 。可使用命令 config get dir 查看
dir /opt/redis-7.2.4/data
## 指定 dump.rdb 文件名，默认：dump.rdb。
dbfilename dump.rdb
## 快照写入失败时，不再处理客户端新的写入请求。默认：no
stop-writes-on-bgsave-error no
## 是否对 rdb 文件压缩存储。默认：yes。采用LZF算法压缩，会消耗部分性能。
rdbcompression yes
## 是否对 rdb 文件使用CRC64算法进行数据校验。默认：yes。
rdbchecksum yes
## 在没有持久化时，删除复制中使用的RDB文件。默认：no。
rdb-del-sync-files no
:wq
2.2.3、触发备份
- redis 命令
## 阻塞主线程，不再响应客户端请求，执行备份
save
## 非阻塞，Fork新线程后端异步执行备份
bgsave
## 查看最后一次备份时间，转化时间戳为时间格式命令：date -d @时间戳
lastsave
## flushdb 和 fulshall 也会触发生成RDB文件（将命令记录到 dump.rdb 中，恢复后是空）
flushdb
fulshall
## 执行shutdown且没有设置开启AOF持久化
shutdown
- 主从复制时，主节点自动触发
2.2.4、恢复备份
查看 redis.conf 配置中 rdb 文件的保存目录（dir）和文件名（dbfilename），将恢复文件 dbfilename 放置 dir 目录下，重启 redis 服务即可。
注意：
当 redis 异常宕机后，可能会导致 dump.rdb 文件记录异常，需修复文件后再恢复备份。恢复命令：
## 历史版本命令：redis-check-dump --fix dump.rdb
/opt/redis-7.2.4/bin/redis-check-rdb /opt/redis-7.2.4/data/dump.rdb
2.2.5、优缺点
- 优点
- 持久化过程中，主进程不进行任何IO操作，对于大规模数据恢复，性能极高；
- 与AOF 相比，RDB 对大数据集可更快的重启；
- RDB支持重启和故障转移后的部分重新同步。
- 缺点
- RDB 最后一次持久化后的数据可能因为 redis 意外宕机而丢失；
- RDB 要经常 fork() 使用子进程持久化。若数据集很大，持久化会很耗时，影响性能；
- Fork 时内存数据被克隆，大致2倍的膨胀性，会对服务器造成一定的压力，影响性能。
2.2.6、使用场景
- 适合大规模数据恢复
- 按照业务定时备份
- 对数据的完整性、一致性要求不是很严格
2.3、AOF（append only file）
2.3.1、是什么
原理：：用日志的形式来追加的方式在文件中记录每个写操作。
redis启动时，根据日志内容将写指令从前到后执行一次以完成数据恢复。
AOF 文件重写不是去整理原文件，而是读取服务器现有键值对，将其转化为一条条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件格式：
- redis6 以前 AOF 仅有一个文件：appendonly.aof。
- redis7 之后 AOF 采用 Multi Part AOF 格式，共有三个文件：
- BASE: 基础AOF，由子进程通过重写产生，最多只有一个。
- INCR: 增量AOF，在AOFRW开始执行时被创建，可能存在多个。
- HISTORY: 历史AOF，由 BASE 和 INCR AOF 变化而来，每次 AOFRW 完成时，本次AOFRW 之前的 BASE 和 INCR AOF 将变为 HISTORY。HISTORY 类型的 AOF 会被Redis 自动删除。
2.3.2、配置方式
vi redis.conf
## 是否开启AOF，默认：no
appendonly yes
## 指定日志目录名，redis7后新增，完整目录为：dir参数指定目录 + appenddirname 指定目录
appenddirname "appendonly"
## 指定日志文件名
appendfilename "appendonly.aof"
## AOF缓冲区同步文件的三种 更新频率
## appendfsync always ## 每个写操作均之心更新。性能差。
appendfsync everysec ## 默认。每秒更新，最多丢失一秒内数据
## appendfsync no ## 操作系统控制的写回，时间随机
## AOF 重写期间是否进行 AOF 同步
## yes - 不同步：重写期间新的 写操作 只会在内存中，不会阻塞但可能丢失数据；
## no - 同步：重写期间新的 写操作 由主线程调用 fsync() 刷盘，如果正在 bgrewrite 会导致主线程阻塞。可保证数据一致性但是效率低。
no-appendfsync-on-rewrite no
:wq
2.3.3、恢复备份
查看 redis.conf 配置中 rdb 文件的保存目录（dir） + aof目录（appenddirname）+ 文件名（appendfilename），将恢复文件 appendfilename 放置 appenddirname 目录下，重启 redis 服务即可。
注意：
当 redis 异常宕机 或 网络闪断导致文件写入不完整时，会导致 aof 文件记录异常，需修复文件后再恢复备份。恢复命令：
/opt/redis-7.2.4/bin/redis-check-aof --fix /opt/redis-7.2.4/data/appendonly/appendonly.aof*
2.3.4、AOF 重写
背景： AOF 持久化是不断将 写命令 写入AOF 文件中，导致文件越来越大。
解决方案： 引入重写机制。当 AOF 文件大小超过设定峰值时，Redis 自动启动AOF重写，只保留可恢复数据的最小指令集。
重写原理：
- 创建 重写子进程；
- 子进程遍历新进程内存中的数据，将每条记录转化为一条set语句并写入新 AOF 文件；
- 主进程会将接受到的新写指令，同时写入 内存缓冲区 和 原有的AOF文件，确保重写出现意外时，原有AOF文件依然可用；
- “重写子进程”完成后，发信号给父进程。父进程收到信号后，将内存中缓存的写指令追加到新的AOF文件中；
- 追加结束后，redis 会用 新AOF 代替 旧AOF。之后的新写指令都会追加到新的AOF文件中。
触发时机：
- 配置文件
vi redis.conf
## 当 AOF 上次rewrite后大小的一倍 且 文件大于 64M 时触发重写。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
:wq
- 命令方式
bgrewriteaof
2.3.5、优缺点
- 优点
- 更好的保护数据不丢失
- 性能高、
- 可做紧急恢复
- 缺点
- 相同数据量 AOF 文件远大于 RDB 文件，且恢复速度慢于RDB
- AOF 运行效率慢于 RDB，每秒同步策略效率较好，不同步效率和RDB相同
2.4、RDB-AOF混合模式
2.4.1、加载原理
RDB和AOF共存时会优先加载AOF文件，因为通常情况下AOF文件保存的数据集比RDB文件的完整。
2.4.2、混合模式优势
- RDB 做全量持久化
- AOF做增量持久化
- 先使用 RDB 进行快照存储，在使用 AOF 持久化增量记录所有的写操作
既保证了数据完整性，又提高了恢复数据的性能。
2.4.3、开启混合模式配置
vi redis.conf
## 是否开启 RDB-AOF 混合持久化模式
## yes时，AOF 重写产生的文件将包含 RDB 格式 和 AOF 格式的内容，该文件的前半段是 RDB 格式的全量数据，而后半段是 Redis 命令格式的增量数据。
aof-use-rdb-preamble yes
:wq
