Redis 持久化

官网：Redis persistence | Redis

1. RDB

实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也得到了保障。这个快照文件就成为RDB文件（dump.rdb）,RDB就是Redis DataBase的缩写。

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot内存快照。它恢复时再将硬盘快照文件直接读回到内存里。

Redis6.0.16以下：

Redis6.2以及Redis7.0.0：

 

   实操：

自动触发：

频率：当5s内有2次更新会触发。

时间：超过5s，2次更新也会触发。

修改dump文件的保存路径：（默认是dir ./）

必须要先创建文件夹  mkdir /myredis/dumpfiles

修改rdb文件的名字

备份成功了如何恢复：

执行flushall/flushdb 也会产生dump.rdb文件，但里面是空的。

shutdown 也会生成rdb文件。

手动触发：（类似于java开了一个子进程，去备份。）

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

bgsave（默认）：会在后台异步进行快照，不阻塞快照的同时还可以响应客户端的请求。该触发方式会fork一个子进程由子进程复制持久化过程。

可以通过lastsave 命令 获取最后一次成功执行快照的时间。

RDB的优点：

        非常适合备份、灾难恢复，它是一个可以传输到远程数据中心的压缩文件。

最大限度的提高了Redis 的性能，因为Redis父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程，父进程永远不会执行磁盘I/O获类似操作。

与AOF相比，RDB允许使用大数据集更快的重启。

总结：

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

RDB缺点：

        如果Redis优于任何原因在没有正确关闭的情况下停止工作，要做好丢失最新分钟的数据。

        RDB需要经常fork()，以便使用子进程在磁盘上的持久化。如果数据集很大，fork()可能会很耗时，并且如果数据集很大并且CPU性能不是很好，可能会导致Redis停止为客户服务几毫秒甚至一秒钟。AOF也需要fork(),但是效率低，可以调整要重写日志的频率。

总结：

• 在一定时间间隔做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据就会丢失。
• 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
• RDB依赖于主进程的fork(),在更大的数据集中，这可能会导致服务请求的瞬间延迟。

Redis恢复RDB文件：

在bin路径下有一个redis-ceck-rdb 文件。它用来修复破损的rdb文件。

# redis-ckeck-rdb /myredis/dump6379.rdb

如何禁用快照：

命令方式： # redis-cli config set save ""

配置文件方式： 

打开注释即可

RDB 优化配置项：

---

   2.AOF（Append Only File）

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

默认情况下redis没有开启AOF。如果要开启需要在redis.conf 文件中 修改 appendonly yse

aof 保存的文件是 appendonly.aof 文件

AOF 工作流程：

        

AOF 写回策略：

• Always：同步写回，每个写命令执行完立刻同步的将日志写回磁盘。
• everysec（默认）：每秒写回，每个写命令执行完，只是把日志写到AOF文件的内存缓存区，每隔1s再把缓存区中的内容写回磁盘
• no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF 文件的内容缓存区，由操作系统决定何时将缓存区内容写回磁盘。

配置文件说明:

• aof 保存路径：

                redis7之前：aof和rdb保存的文件位置是一样的，都是通过redis.conf 中的dir来配置

                redis7之后：会在 配置文件中 dir /myredis 中自己加一层目录结构appendonlydir

                

• aof 保存名称：

                redis7之前：有且仅有一个 就叫 appendonly.aof

                redis7之后：它采用了Multi Part AOF 的设计。变成了3个文件

base	基本文件
incr	增量文件
manifest	清单文件

                      BASE:它一般由子进程通过重写产生，该文件最多只有一个。

                      INCR:它一般会在AOFRW开始执行的时候被创建，该文件可能存在多个。

                      HISTORY:表示历史AOF,它由BASE和INCR AOF 变化而来，每次aofrw成功完成  时， 本次aofrw之前对应的base和incr aof都将变成history，history类型的aof会被redis自动删除。

                        为了管理这些AOF文件，引入了manifest（清单）文件来跟踪，管理这些aof 。

实操：

flashdb 也会生成AOF 文件，但是是一个空文件。再次启动时内存中也是空的。

vim vim appendonly.aof.1.incr.aof  长下面这样：

  

如果文件 appendonly.aof.1.incr.aof 损坏，不能链接到redis，服务器都链接不了。

AOF优势: 更好的保护数据不丢失，性能高，可做紧急恢复。

AOF缺点: AOF 文件通常比相同数据集的等效RDB文件大，恢复速度要慢与RDB.

AOF重写机制：

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

为了解决这个问题，Redis新增了重写机制。当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集（当重复写入某一个key时，aof文件只会记录最后一个写入的内容，忽略之前写入的，达到瘦身。）。也可以手动使用命令 bgrewriteaof 来重写。

官方自动触发条件：

当写入命令触发重写机制时,incr文件大小会从0开始并且文件号加一，base文件会把瘦身之后的incr文件内容copy到自己里面，并且文件号加一。（手动触发命令的效果也一样）

重写原理：

3. RDB+AOF混合

俩者共存没有任何问题，redis会优先加载AOF。

开启方式：在配置文件中 aof-use-rdb-preamble 的值改为 yes。

在同时开启了RDB和AOF持久化时，重启时只会加载AOF 文件，不会加载RDB文件。

结论：RDB做全量持久化，AOF做增量持久化。先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作。