Redis数据持久化

数据持久化主要是将内存中的数据写入disk。redis保存的数据在内存中，当redis发生宕机，那么存在redis中的数据就会消失，可能会导致数据丢失。那么如何解决这种问题呢？这就需要我们对redis中的数据进行持久化。

redis进行持久化的两种方法

发生宕机时，数据恢复

RDB

RDB（Redis DataBase）数据持久化是在指定时间将当前时刻内存中的数据生成一个 snapshot (快照，默认为dump.rdb)，然后将快照保存到磁盘上，这样即使redis宕机了，下次可以通过将硬盘快照文件直接读会到内存，达到恢复数据的效果。

在指定的时间间隔，执行数据集的时间点快照。

配置文件（6 VS 7）

Redis6

Redis7

触发方式

自动触发

修改配置文件

vim /myredis/redis7.conf

# 5秒钟2次修改
save 5 2
# 修改dump文件保存路径，路径需要存在
dir /myredis/dumpfiles
# 修改dump文件名称
dbfilename dump6379.rdb

触发备份

# 执行上面的两个命令后，会再我们配置的 dir中生成 备份文件
set key1 value1 
set key2 value2

恢复备份

将备份文件 dump.rdb移动到 redis 安装目录下并启动服务即可

重要：

执行flushall、flushdb命令也会产生备份文件，但是备份文件为空。
redis服务器和备份必须分机隔离。防止物理机损坏后备份文件丢失。

手动触发

save

再主程序中执行会阻塞当前redis服务器，直到持久化工作完成。执行save命令期间，redis不能处理其他命令，线上禁止使用

bgsave（默认）

redis会使用bgsave对当前内存中的所有数据做一份快照，这个操作是子进程再后台完成的，这允许主进程同时可以修改数据。

通过lastsave命令获取最后一次执行快照的时间

lastsave

优点

RDB是Redis数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，可以在最近24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照，这可以在发生灾难时轻松恢复不同版本的数据集。
RDB非常适合灾难恢复，他可以传输到远程数据中心或云服务器上。
RDB最大限度的提高了Redis的性能，因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘I/O或类似操作。
与AOF相比，RDB允许使用大数据集更快地重启
在副本上，RDB支持重启和故障转移后的部分重新同步。

总结

适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性要求不高
RDB文件在内存中的加载速度要比AOF快得多

缺点

如果您需要在Redis停止工作时（例如断电）将数据丢失的可能性降到最低，那么RDB并不好。您可以配置多个RDB的不同保存点。如果Redis由于任何原因在没有正确关闭的情况下停止工作，都会丢失最新分钟的数据
RDB需要经常fork()以便使用子进程在磁盘上持久化，如果数据集很大，fork()可能会消耗较多时间，并且如果数据集很大并且CPU性能不好，可能会导致Redis停止客户端服务几毫秒甚至一秒钟。AOF也需要fork()但是频率较低，可以调整要重写日志的频率，而不需要对持久性进行任何权衡。

总结

在一定间隔时间做一次备份，如果redis宕机，就会丢失当前至最近一次快照期间的数据
内存数据全量同步，如果数据量很大会导致I/O严重影响服务器性能。
RDB依赖于主进程的fork，在很大的数据集中会导致服务器瞬间延迟，fork()时内存中的数据被克隆了一份导致体积膨胀。

案例

数据丢失案例，模拟redis宕机

设置了 save 5 2，5 秒钟 2 次修改

①、正常写入

# 正常写入数据
set k1 v1
set k2 v2

⑤、模拟宕机

# 写入k3
set k3 v3
# 查看redis进程
ps -ef|grep redis
# kill，模拟宕机
kill -9 3878

⑤、重启redis

重启redis，发现 k3 数据丢失

修复dump.rdb文件

cd /usr/local/bin
redis-check-rdb /myredis/dumpfiles/dump6379.rdb

触发RDB快照

那些情况会触发RDB快照？

配置文件中默认的快照配置
手动save/bgsave命令
执行flushdb/flushall命令
执行shutdown且没有设置开启AOF持久化
主从复制时，主节点自动触发

禁用RDB

命令
```
redis-cli config set save ""
```

配置文件 redis.conf

# 配置文件设置下面内容
save ""

RDB优化配置项

配置文件 redis.conf

# 1.
save <seconds> <changes>
# 2.
dbfilename
# 3.
dir
# 4.默认yes，如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求
stop-writes-on-bgsave-error
# 5.默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbcompression
# 6.默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdbchecksum
# 7.在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。
rdb-del-sync-files

AOF

AOF（Append Only File）数据持久化是记录每一次对redis的写操作命令（默认为appendonly.aof），当发生redis宕机时，将保存的操作命令重新再执行一次，从而达到恢复数据的效果。

以日志的形式来记录每个写操作，将redis执行过的写指令记录下来（读操作不记录），只允许追加文件不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前往后执行一次已完成数据恢复的工作。

默认redis没有开启AOF，需要手动设置 appendonly yes

工作流程

编号	描述
1	Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2	在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3	AOF缓冲会根据AOF缓冲区*同步文件的三种写回策略*将命令写入磁盘上的AOF文件。
4	随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5	当Redis Server 服务器重启的时候会从AOF文件载入数据。

三种写回策略

Always

同步写回，每个命令执行完立刻同步地将日志写回磁盘

everysec

每秒写回，每个命令执行完，只是先把日志写回到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘

no

操作系统控制的写回，每个命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回到磁盘

总结

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高，数据基本不丢失	每个写命令都要落盘，性能影响较大
Everysec	每秒写回	性能适中	宕机时丢失1秒内的数据
No	操作系统控制的写回	性能好	宕机时丢失数据较多

配置文件（6 VS 7）

修改配置文件

开启aof

vim /myredis/redis7.conf
# 修改appendonly 为 yes
appendonly yes

使用默认的写回策略

# 每秒写回
sppendfsync everysec

aof文件保存路径

redis6: AOF保存文件位置和RDB保存文件位置一样，都是通过redis.conf配置文件中的 dir 配置

**redis7: ** 在redis7使用的的保存appendonly.aof文件的路径是 dir + appenddirname

# 修改之前配置的 dir /myredis/dumpfiles 为下面内容
dir /myredis
# 配置 appendonlydirname
appenddirname "appendonlydir"

aof文件保存名称

redis6: 有且仅有一个
redis7:
- base基本文件
- incr增量文件
- manifest清单文件：
  - base : 基础AOF，它一般由子进程通过重写产生，该文件最多只有一个。
  - incr : 增量AOF，它一般会在AOF重写的开始执行时被创建，该文件可能存在多个。
  - history : 历史AOF，它由base和incr AOF变化而来，每次AOF重写成功完成时，本次AOF 重写之前对应的base和incr AOF都将变成history，history类型的AOF会被redis自动删除。
  为了管理这些AOF文件，我们引入了一个manifest清单文件来跟踪、管理这些AOF。同时，为了便于AOF备份和拷贝，我们将所有的AOF文件和manifest文件放到一个单独的文件目录中，目录名由 appenddirname配置决定。

修复aof文件

redis-check-aof --fix appendonly.aof.1.incr.aof

优点

使用AOF Redis更加持久：您可以有不同的 fsyn 策略: 根本不fsync、每秒 fsync、每次查询时 fsync，使用每秒 fsync 的默认策略，写入性能仍然很棒。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
AOF 日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因) 日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它
当AOF 变得太大时，Redis 能够在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个。
AOF 以易于理解和解析的格式依次包合所有操作的日志。您甚至可以轻松导出 AOF 文件。例如，即使您不小心使用该FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存您的数据集.

总结

更好的保护数据不丢失、性能高、可做紧急恢复。

缺点

AOF 文件通常比相同数据集的等效 RDB 文件大。
根据确切的 fsync 策略，AOF 可能比 RDB 慢。一般来说，将fsync 设置为每秒性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下它也应该与 RDB 一样快。即使在巨大的写入负载的情况下，RDB 仍然能够提供关于最大延迟的更多保证。

总结

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb，aof运行效率要慢于rdb，每秒钟同步策略效率较好，不同步效率和rdb相同。

AOF重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者手动使用命令 bgrewriteaof 来重写。

总结：启动AOF文件的内容压缩，只保留可恢复数据的最小指令集。

为什么需要重写？

set k1 v1
set k1 v3
set k1 v3
set k1 v4

上面的四条命令如果不重写，那么四条命令都将保存到 aof 文件中，不光占空间，在启动的时候需要一次执行四条命令，但是实际上我们只需要最后一条命令执行的效果即可。

开启重写后，只需要保留最后一条命令即可。

触发方式

自动触发

根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
重写是满足的文件大小

两个条件同时满足才会触发

手动触发

客户端向服务器发送 bgrewriteaof 命令

AOF 文件的重写并不是对原文件进行重新整理，而是直接读取服务器中现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件去替换原来的AOF文件。

案例

准备工作

# 开启 aof
appendonly yes
# 重写峰值，修改为 1k
auto-aof-rewrite-min-size 1k
# 关闭混合，修改为 no
aof-use-rdb-preamble no
# 删除之前全部的 aof和rdb（省略代码）

自动触发案例

启动redis服务，不断向写入内容，直到到达 1KB后，启动重写机制。

手动触发案例

# 发送命令
bgrewriteaof

重写原理

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

RDB + AOF

RDB持久化方式能够在指定时间间隔能对数据进行快照存储
AOF持久化方式记录每次对服务器写操作，当服务器重启时会自动执行这些命令来恢复原始数据，AOF命令以redis协议追加保存每次写操作到文件末尾。

RDB 与 AOF 可以共存，如果AOF 被开启会优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF保存的数据集要比RDB文件保存的数据集要完整。

要不要只用AOF呢？

建议不要，因为RDB更适合用于备份数据库，AOF在不断的变化不好做备份。

纯缓存

同时关闭 RDB + AOF

禁用RDB

禁用rdb持久化模式下，我们仍然可以使用命令 save、bgsave 生成 rdb 文件
```
save ""
```
禁用AOF

禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof 生成aof 文件
```
appendonly no
```

✨✨✨✨想要了解更多关于Redis的信息，可以关注一波作者的公众号