一文深度剖析Redis6的持久化机制（简洁易懂） javaredis数据库

Redis的强劲性能很大程度上是由于它所有的数据都存储在内存中，当然如果redis重启或者服务器故障导致redis重启，所有存储在内存中的数据就会丢失。但是在某些情况下，我们希望Redis在重启后能够保证数据不会丢失。

将redis作为nosql数据库使用。
将Redis作为高效缓存服务器，缓存被击穿后对后端数据库层面的瞬时压力是特别大的，所有缓存同时失效可能会导致雪崩。

这时我们希望Redis能将数据从内存中以某种形式同步到硬盘上，使得重启后可以根据硬盘中的记录来恢复数据。
Redis支持两种方式的持久化，一种是RDB方式、另一种是AOF（append-only-file）方式，两种持久化方式可以单独使用其中一种，也可以将这两种方式结合使用。

RDB：根据指定的规则“定时”将内存中的数据存储在硬盘上，
AOF：每次执行命令后将命令本身记录下来。

RDB模式 RDB的持久化方式是通过快照（snapshotting）完成的，它是Redis默认的持久化方式，配置如下。

# save 3600 1 # save 300 100 # save 60 10000

Redis允许用户自定义快照条件，当符合快照条件时，Redis会自动执行快照操作。快照的条件可以由用户在配置文件中配置。配置格式如下

save

第一个参数是时间窗口，第二个是键的个数，也就是说，在第一个时间参数配置范围内被更改的键的个数大于后面的changes时，即符合快照条件。当触发条件时，Redis会自动将内存中的数据生成一份副本并存储在磁盘上，
这个过程称之为“快照”，除了上述规则之外，还有以下几种方式生成快照。

根据配置规则进行自动快照
用户执行SAVE或者GBSAVE命令
执行FLUSHALL命令
执行复制(replication)时

根据配置规则进行自动快照

修改redis.conf文件，表示5秒内，有一个key发生变化，就会生成rdb文件。

save 5 1# 表示3600s以内至少发生1个key变化（新增、修改、删除），则重写rdb文件 save 300 100 save 60 10000

修改文件存储路径

dir /data/program/redis/bin

其他参数配置说明

参数	说明
dir	rdb文件默认在启动目录下（相对路径） `config get dir` 获取
dbfilename	文件名称
rdbcompression	开启压缩可以节省存储空间，但是会消耗一些CPU的计算时间，默认开启
rdbchecksum	使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

如果需要关闭RDB的持久化机制，可以参考如下配置，开启save，并注释其他规则即可

save "" #save 900 1 #save 300 10 #save 60 10000

用户执行SAVE或者GBSAVE命令除了让Redis自动进行快照以外，当我们对服务进行重启或者服务器迁移我们需要人工去干预备份。redis提供了两条命令来完成这个任务

save命令
如图4-24所示，当执行save命令时，Redis同步做快照操作，在快照执行过程中会阻塞所有来自客户端的请求。当redis内存中的数据较多时，通过该命令将导致Redis较长时间的不响应。所以不建议在生产环境上使用这个命令，而是推荐使用bgsave命令

文章图片

图4-24

bgsave命令
如图4-25所示，bgsave命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应来自客户端的请求。执行BGSAVE后，Redis会立即返回ok表示开始执行快照操作，在redis-cli终端，通过下面这个命令可以获取最近一次成功执行快照的时间（以 UNIX 时间戳格式表示）。

LASTSAVE

1：redis使用fork函数复制一份当前进程的副本(子进程)
2：父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件
3：当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

注意：redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份， RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
bgsave是异步执行快照的，bgsave写入的数据就是for进程时redis的数据状态，一旦完成fork，后续执行的新的客户端命令对数据产生的变更都不会反应到本次快照

Redis启动后会读取RDB快照文件，并将数据从硬盘载入到内存。根据数据量大小以及服务器性能不同，这个载入的时间也不同。

文章图片

图4-25
执行FLUSHALL命令该命令在前面讲过，会清除redis在内存中的所有数据。执行该命令后，只要redis中配置的快照规则不为空，
也就是save 的规则存在。redis就会执行一次快照操作。不管规则是什么样的都会执行。如果没有定义快照规则，就不会执行快照操作。
执行复制(replication)时该操作主要是在主从模式下，redis会在复制初始化时进行自动快照。这个会在后面讲到；
这里只需要了解当执行复制操作时，即时没有定义自动快照规则，并且没有手动执行过快照操作，它仍然会生成RDB快照文件。
RDB数据恢复演示

准备初始数据

redis> set k1 1 redis> set k2 2 redis> set k3 3 redis> set k4 4 redis> set k5 5

通过shutdown命令关闭触发save

redis> shutdown

备份dump.rdb文件(用来后续恢复)

cp dump.rdb dump.rdb.bak
接着再启动redis-server(systemctl restart redis_6379)，通过keys命令查看，发现数据还在

keys *

模拟数据丢失

执行flushall

redis> flushall

shutdown(重新生成没有数据的快照，用来模拟后续的数据恢复)

redis> shutdown

再次启动redis, 通过keys 命令查看，此时rdb中没有任何数据。
恢复之前备份的rdb文件（之前保存了数据的rdb快照）

mv dump.rdb.bak dump.rdb

再次重启redis，可以看到之前快照保存的数据

keys *

文件的优势和劣势一、优势
1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集，这种文件非常适合用于进行备份和灾难恢复。
2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比AOF的恢复速度要快。
二、劣势

1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高
2、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。
AOF模式 AOF(Append Only File)：Redis 默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis数据的命令时，就会把命令写入到AOF文件中。
Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
AOF配置开关

# 开关 appendonly no/yes # 文件名 appendfilename "appendonly.aof"

通过修改redis.conf重启redis之后：systemctl restart redis_6379。
再次运行redis的相关操作命令，会发现在指定的dir目录下生成appendonly.aof文件，通过vim查看该文件内容如下

*2 $6 SELECT $1 0 *3 $3 set $4 name $3 mic *3 $3 set $4 name $3 123

AOF配置相关问题解答问题1：数据都是实时持久化到磁盘吗？
虽然每次执行更改Redis数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作。以便将硬盘缓存中的内容真正地写入硬盘。
在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来说能够启用AOF的前提是业务场景不能容忍这样的数据损失，这个时候就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在redis.conf中通过如下配置来设置同步机制。

参数	说明
appendfsync everysec	AOF持久化策略（硬盘缓存到磁盘），默认everysec 1 no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全； 2 always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低； 3 everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。

问题2：文件越来越大，怎么办？
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的运行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
例如set gupao 666，执行1000次，结果都是gupao=666。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
可以使用命令下面这个命令主动触发重写

redis> bgrewriteaof

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

参数	说明
auto-aof-rewrite-percentage	默认值为100。表示的是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据
auto-aof-rewrite-min-size	默认64M。表示限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心

在启动时，Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相对于RDB会慢一些
问题：重写过程中，AOF文件被更改了怎么办？
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
重写的流程是这样，

主进程会fork一个子进程出来进行AOF重写，这个重写过程并不是基于原有的aof文件来做的，而是有点类似于快照的方式，全量遍历内存中的数据，然后逐个序列到aof文件中。
在fork子进程这个过程中，服务端仍然可以对外提供服务，那这个时候重写的aof文件的数据和redis内存数据不一致了怎么办？不用担心，这个过程中，主进程的数据更新操作，会缓存到aof_rewrite_buf中，也就是单独开辟一块缓存来存储重写期间收到的命令，当子进程重写完以后再把缓存中的数据追加到新的aof文件。
当所有的数据全部追加到新的aof文件中后，把新的aof文件重命名正式的文件名字，此后所有的操作都会被写入新的aof文件。
如果在rewrite过程中出现故障，不会影响原来aof文件的正常工作，只有当rewrite完成后才会切换文件。因此这个rewrite过程是比较可靠的。

文章图片

图4-26
Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。如果同时开启后，Redis重启会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。
AOF的优劣势优点：
1、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
缺点：
1、对于具有相同数据的的Redis，AOF 文件通常会比 RDB 文件体积更大（RDB存的是数据快照）。
【一文深度剖析Redis6的持久化机制（简洁易懂）】2、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。