【Redis】(一)Redis两种持久化方式RDB和AOF

关注

原创最新推荐文章于 2026-04-13 09:20:49 发布 453 阅读 AI 写同款· GEO 优化 ›

UQLab——其他概率分布随机变量转换标准Gaussian分布 1、使用UQLab将其他类型的随机变量转换成标准Gaussian分布； 2、使用科学计数法输出样本，方便后续ANSYS的调用分析； 3、基于MC的可靠度分析。原随机变量分布类型： % 调用UQLab进行采样 clc clear uqlab %% Specify these distributions as a UQLab INPUT object: PriorOpts.Marginals(1... 阅读详情

1. 使用场景

在我们正式的线上环境中，如果不是用的云服务器，而是客户本地的服务器，那出现服务器突然断电的情况是很正常的，有些项目比较依赖于Redis,或者某些数据较多的项目，依赖于Redis去做了一些缓存，方便查询数据的速率，这时候如果断电恢复过来，redis里面没有数据的话，就有点缓存雪崩的意思了。

2.持久化方式介绍

2.1 RDB

Redis给我们提供的第一种持久化的方式就是RDB方式，这种方式默认是将我们Redis在缓存中数据的二进制存入到文件中的，相当于是对我们的缓存做了一个快照，可想而知，如果我们使用这种方式进行数据的恢复的化，直接将数据恢复到缓存，速度是很快的，但是同样，因为是直接克隆我们的缓存，那么在生成这个文件的过程是很慢的，没办法做到实时的生成，否则会严重影响服务器的性能，这样就存在一个问题，如果是1个小时克隆一次，那么如果服务器断电，可能就会丢失1个小时的数据。

2.2 AOF

第二种方式称为AOF，这种方式是将我们redis的操作指令存储到文件中，弥补上一种方式的缺点，它可以做到1秒记录一次，或者每当执行命令时，都记录一次，只是将我们的指令记录到文件，不会过多影响服务器的性能，但是这种方式同样有它的缺点，那就是，如果我们在Redis里面存储了很多很多数据，并且已经进行过了很多的操作了，如果一个Key我先存了进去，后面又把它删了，按道理，这种数据我已经不要了，就不用在帮我恢复了，但是指令已经在文件中生成了，set和del的命令，它会再帮你执行一遍，可想而知，这种恢复的速度是特别慢的

综上所述，生成环境中要根据自己的项目类型，和存储Redis中的数据来判断应该选择那种持久化的方式，各自有各自的有点和缺点。

3.持久化方式的操作

3.1 使用RDB进行持久化存储

3.1.1 自动化进行RDB存储

在这里插入图片描述
打开Redis的配置文件找到上面这些内容，window下的配置文件是redis.windows.conf,linux的配置文件是redis.conf,Redis已经默认帮助我们开启了RDB的持久化方式
save 900 1 表示的含义是 900秒内，如果有1个key进行了更新，那就更新RDB文件
save 300 10 表示的含义是 300秒内，如果有10个key进行了更新，那就更新RDB文件
save 60 10000 表示的含义是 60秒内，如果有10000个key进行了更新，那就更新RDB文件

为了测试，我这里加了一个5秒内如果更新了一个Key那就帮我更新RDB文件

启动Redis指定配置文件

redis-server ./redis.windows.conf

往redis里面塞了一个key

set first 111

在redis的安装目录内，就可以看到生成了一个dump.rdb的文件
在这里插入图片描述
这里面记录的就是我们的rdb的数据了。

另外，如果我们正常的退出redis,Redis也会帮我们进行RDB的存储

3.1.2 手动进行RDB备份

可以使用save和bgsave两个命令触发RDB持久化。

3.1.3 备份的恢复

我们正常启动Redis,它会自动检测有没有rdb的文件，如果有的话，redis就会自动帮我们把rdb的数据恢复过来。

3.2 AOF持久化存储

在这里插入图片描述
继续打开配置文件，找到上述的内容
appendonly no Redis默认关闭了AOF的持久化的方式，如果使用将no改成yes
appendfilename “appendonly.aof” aof文件名称
appendfsync always 表示每当我们有了一次操作，它就帮我们同步到AOF文件中
appendfsync everysec 表示每秒帮我们同步一次
appendfsync no 不使用sync,依靠操作系统的刷写。