Redis持久化

A_Tai2333333

已于 2024-10-05 12:57:08 修改

阅读量604

点赞数 9

分类专栏： Redis 文章标签： redis java 数据库

于 2024-10-04 12:23:07 首次发布

本文链接：https://blog.csdn.net/m0_50460160/article/details/142701101

版权

Redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、持久化两种方式:

1.RDB:Redis DataBase

(1).介绍:

RDB持久化是以指定的时间间隔执行数据集的时间点快照；实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中RDB就是Redis DataBase的缩写。Redis的数据都在内存中，保存备份时执行的是全量快照，把内存中所有数据都记录到磁盘中；

(2)自动触发:

a.按照redis.conf配置的save <seconds> <changes>

b.修改dump文件保存路径

c.修改dump文件名称

恢复时将备份文件(dump.rdb)移动到redis安装目录并启动服务即可；

执行flushall/flushdb命令时也会产生dump.rdb文件，但里面是空的，无意义

不可以把备份文件dump.rbd和生产redis服务器放在同一台机器，必须分开各自存储，防止生产机物理损坏后备份文件也挂掉

(3)手动触发:

Redis提供了两个命令来手动生成RDB文件，分别是save和bgsave(默认)

一般情况下只能使用bgsave，这是因为在主程序中执行save时会阻塞当前redis服务器，直到持久化工作完成；执行save命令期间redis不能处理其他命令；使用bgsave时redis会在后台异步进行快照操作，不阻塞当前redis服务器，快照同时还可以相应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程。Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，允许主进程同时可以修改

(4)RDB优点:

a.RDB是Redis数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份

b.RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3(可能已加密)的压缩文件

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

d.与 AOF 相比RDB允许使用大数据集更快地重启

e.在副本上RDB支持重启和故障转移后的部分重新同步

(4)RDB缺点:

a.如果需要在Redis停止工作时(例如断电后)将数据丢失的可能性降到最低，那么 RDB 并不好

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

(5)触发RDB快照的场景:

a.配置文件中默认的快照配置

b.手动save/bgsave命令

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

d.执行shutdown且没有设置开启AOF持久化

e.主从复制时主节点自动触发

(6).禁用RDB快照:

动态停止所有RDB保存规则的方法:redis-cli config set save ""

修改配置文件

2.AOF:Append only file

(1)介绍:

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作;默认情况下，redis是没有开启AOF(append only file)的。开启AOF功能需要设置配置:appendonly yes;

(2).AOF持久化的工作流程:

a.Client作为命令的来源，会有多个源头以及源源不断的请求命令

b.在这些命令到达Redis server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。

c.AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件

d.随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。

e.当Redis Server服务器重启时会从AOF文件载入数据

(3).AOF的写回策略:

a.always:同步写回，每个写命令执行完立刻同步地将日志写回磁盘，可靠性高，数据基本不丢失，但是每个写命令都要落盘，对性能影响比较大

b.everysec:每秒写回，每个写命令执行完毕后只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘，性能适中，宕机时丢失1秒内的数据

c.no:操作系统控制写回，每个写命令执行完毕后只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘，性能好，但是宕机时丢失的数据较多

Redis7以前AOF文件只有一个，Redis7.0以后产生了Multi Part AOF，分为BASE-AOF,INCR-AOF以及HISTORY-AOF;BASE-AOF表示基础AOF，一般由子进程通过重写产生，该文件最多只有一个。INCR-AOF表示增量AOF，它一般会在AOFRW开始执行时被创建，该文件可能存在多个；HISTORY-AOF表示历史AOF，它由BASE和INCRAOF变化而来，每次AOFRW成功完成时本次AOFRW之前对应的BASE和INCR AOF都将变为HISTORY，HISTORY类型的AOF会被Redis自动删除。

(4).AOF的优点:

a.使用AOF Redis更加持久:可以有不同的fsync策略:根本不fsync、每秒 fsync、每次查询时 fsync。使用每秒fsync的默认策略，写入性能仍然很好。fsync是使用后台线程执行的，当没有 fsync正在进行时，主线程将努力执行写入，因此只能丢失一秒钟的写入。

b.AOF日志是一个仅附加日志，因此不会出现寻道问题，也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因)日志以写一半的命令结尾，redis-check-aof 工具也能够轻松修复它

c.当AOF 变得太大时，Redis 能够在后台自动重写 AOF。重写是完全安全的，因为当 Redis 继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始附加到新的那一个

d.AOF以易于理解和解析的格式依次包含所有操作的日志。甚至可以轻松导出 AOF 文件。即使不小心使用该FLUSHALL命令刷新了所有内容，只要在此期间没有执行日志重写，仍然可以通过停止服务器、删除最新命令并重新启动Redis来保存数据集;

(5).AOF的缺点:

a.AOF文件通常比相同数据集的等效RDB文件大

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

(6).AOF的重写机制

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

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

触发机制:满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时

重写原理:

a.在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

b.与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

c.当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

d.当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

e.重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似