Redis是一个内存数据库，如果没有配置持久化，redis重启后数据就全丢失 因此开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数 据。Redis持久化的方式有两种，分别的RDB和AOF，接下来我们就分别看一下两种储存方式的特点以及优缺点。

RDB (Redis DataBase) 全量二进制备份

介绍

在指定的时间间隔内将内存中的数据集快照写入磁盘，默认的文件名为dump.rdb。

应用场景

save 会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。 bgsave fork创建子进程，RDB持久化过程由子进程负责，会在后台异步进行快照操作，快照同时还可以响应客户端请求。 自动化触发 配置文件来完成，配置触发 Redis的 RDB 持久化条件 比如 "save m n"。表示m秒内数据集存在n次修改时，自动触发bgsave。 可以配置多个"save m n"来应对不同的场景。 主从架构 从服务器同步数据的时候，会发送sync执行同步操作，master主服务器就会执行bgsave。

优点

1. RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
2. 在恢复大数据集时的速度比 AOF 的恢复速度要快
3. 生成的是一个紧凑压缩的二进制文件

缺点

1. 每次快照是一次全量备份，fork子进程进行后台操作，子进程存在开销
2. 在快照持久化期间修改的数据不会被保存，可能丢失数据

RDB的关键配置

修改redis.conf文件中的配置信息

#持久化文件名称
dbfilename itlaoqi.rdb
#持久化文件存储路径
dir /usr/local/redis/data
#持久化策略, M秒内有个n个key改动，执行快照
save 3600 1
save 300 100
save 60 10000
#导出rdb数据库文件压缩字符串和对象,默认是yes，会浪费CPU但是节省空间
rdbcompression yes
#导入时是否检查
rdbchecksum yes

AOF(Append Only File)

介绍

追加文件的方式保存Redis执行的每一条命令，文件容易被人读懂。 以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的 写入过程宕机，也不影响之前的数据，可以通过 redis-check-aof检查修复问题

核心原理

Redis每次写入命令会追加到aof_buf（缓冲区）

新增x1:v1
新增x2:v2
删除x2
新增x3:v3
覆盖x4:v4

AOF缓冲区根据对应的策略向硬盘做同步操作。高频AOF会带来影响，特别是每次刷盘。

同步方式

提供了3种同步方式，在性能和安全性方面做出平衡

appendfsync always    #每次有数据修改发生时都会写入AOF文件，消耗性能多
appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no        #不主从同步，由操作系统自动调度刷磁盘，性能是最好的，但是最不安全

AOF的关键配置

修改redis.conf文件中的配置信息

appendonly yes                           #开启aof
appendfilename "appendonly.aof"          #aof日志文件名
appendfsync everysec                     #aof同步方式 每秒钟同步一次

AOF的Rewrite重写机制

介绍

AOF文件越来越大，需要定期对AOF文件进行重写达到压缩。旧的AOF文件含有无效命令会被忽略，保留最新的数据命令。将多条写命令可以合并为一个。 AOF重写降低了文件占用空间。 更小的AOF 文件可以更快地被Redis加载。

示例

新增x1:v1
覆盖x1:v2
覆盖x1:v3
覆盖x1:v4
删除x1
新增x1:v5
# Rewrite以后
新增x4:v5

重写触发方式

手动触发

bgrewriteaof

自动触发

auto-aof-rewrite-percentage 100
#redis记住上次重写时AOF日志的大小,比如上一次重写后50mb,当增长率达到100%,
#也就是AOF文件达到50+50=100mb后,就会自动触发rewrite.60mb = 120mb

auto-aof-rewrite-min-size 50mb 设置触发Rewrite的最小尺寸

重写触发配置

# 是否开启aof
appendonly yes
# 文件名称
appendfilename "appendonly.aof"
# 同步方式,每秒同步
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 50mb
# 加载aof时如果有错如何处理
# yes表示如果aof尾部文件出问题，写log记录并继续执行。no表示提示写入等待修复后写
入
aof-load-truncated yes

RDB和AOF的取舍

RDB持久化以指定的时间间隔执行数据集的时间点快照。

AOF持久化记录服务器接收的每个写入操作，将在服务器启动时再次读取，重建原始数据集。使用与Redis协议本身相同的格式以仅追加方式记录命令，当文件太大时，Redis能够重写。

RDB的优缺点

优点

1. RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O
2. RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
3. 在恢复大数据集时的速度比 AOF 的恢复速度要快
4. 生成的是一个紧凑压缩的二进制文件

缺点

1. 如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好
2. RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大，Fork可能会非常耗时

AOF的优缺点

优点

1. 数据更加安全
2. 当Redis AOF文件太大时，Redis能够在后台自动重写AOF
3. AOF以易于理解和解析的格式，一个接一个地包含所有操作的日志

缺点

AOF文件通常比同一数据集的等效RDB文件大。根据确切的fsync策略，恢复的时候AOF可能比RDB慢

在线上我们到底该怎么做？

AOF通常作为RDB的补充使用。 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据,集群中可以关闭AOF持久化，靠集群的备份方式保证可用性 自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；

Redis4.0后开始的rewrite支持混合模式

介绍

就是RDB和AOF一起用。 直接将rdb持久化的方式来操作将二进制内容覆盖到aof文件中,rdb是二进制，所以很小 有写入的话还是继续append追加到文件原始命令，等下次文件过大的时候再次rewrite。 默认在redis4.x版本后是开启状态的。

示例

AOF日志↓↓↓↓
新增x1:v1
覆盖x1:v2
覆盖x1:v3
覆盖x1:v4
删除x1
新增x1:v5
新增x2:v6

当前保存的aof日志文件当占用空间达到设置的自动保存数值后，执行Rewrite命令，将压缩之后的

x1:v5
x2:v6

通过RDB的方式保存成二进制文件，然后执行的redis命令继续以aof的方式存储。

AOF日志:↓↓↓
新增x3:v7
新增x4:v7

优缺点

优点

混合持久化结合了RDB持久化 和 AOF 持久化的优点,采取了rdb的文件小易于灾难恢复 同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失

缺点

前部分是RDB格式，是二进制，所以阅读性较差

数据恢复的方式

先看是否存在aof文件，若存在则先按照aof文件恢复，aof比rdb全，且aof文件也rewrite成rdb二进制格式 若aof不存在，则才会查找rdb是否存在。

谢谢观看。如有帮助请点个赞，谢谢。

作者：Carlos_Lee
链接：https://juejin.cn/post/7053426807529439269