1、引言

Redis作为一种高性能的内存数据存储系统,常被用作缓存、会话存储、消息队列等多种应用场景。然而,由于其数据存储在内存中,一旦发生意外或服务器重启,数据就会丢失。为了保障数据的持久性和安全性。

Redis提供了多种持久化方案:

  • RDB(Redis DataBase):按指定的时间间隔执行数据集的时间点快照。
  • AOF(Append Only File):记录服务器收到的每个写入操作。
  • RDB + AOF:您还可以在同一实例中组合 AOF 和 RDB。

本文将探究以上三种持久化技术的工作原理、优缺点以及适用场景。

2、RDB持久化

RDB是Redis的默认持久化方式。它通过定期或手动执行快照将内存中的数据保存到磁盘上(dump.rdb)。触发RDB持久化过程分为手动触发和自动触发。

  • 手动触发:可通过SAVE和BGSAVE命令完成。
  • 自动触发:通过redis.conf文件增加save配置项完成,本质还是执行得BGSAVE命令。

那么SAVE和BGSAVE两个命令有什么区别呢?

Redis从入门到放弃(6):持久化-LMLPHP

SAVE:主线程操作,同步执行,会阻塞其它命令的执行。执行[save]命令时,RDB快照生成如果时间过长,后续请求会被阻塞,客户端新发送所有命令都会被拒绝。因此在生产环境中要谨慎使用该命令,避免影响服务的正常运行。

BGSAVE:写时复制,异步执行,不会阻塞其它命令的执行,会fork一个子进程进行操作,但这样比较消耗内存。主进程依旧保持与客户端的连接,正常执行读写命令。

2.1、手动触发

SAVE命令使用方法:

127.0.0.1:6379> SAVE

BGSAVE使用方法:

127.0.0.1:6379> BGSAVE

2.2、自动触发

RDB自动触发指的是通过在Redis的配置文件中设置特定的条件,使得Redis能够在满足这些条件时自动进行RDB持久化,而无需手动干预。这样可以确保数据定期地被保存到磁盘上,从而避免过多的数据丢失。

在Redis的配置文件redis.conf中,可以使用save配置项来设置RDB自动触发的条件。

save <seconds> <changes>

其中<seconds>表示多少秒内发生了<changes>次写操作,就会触发一次自动的RDB持久化。

可以设置多个save规则,每个规则独占一行,Redis会按照配置的顺序进行判断。例如:

save 900 1
save 300 10
save 60 10000

上述配置的意思分别是:在900秒内发生了至少1次写操作、在300秒内发生了至少10次写操作、在60秒内发生了至少10000次写操作时,Redis会自动触发RDB持久化。

3、AOF持久化

AOF持久化(Append Only File)以追加日志的形式记录Redis每个写操作并写入到一个文件中,即【appendonly.aof】文件。

AOF持久化过程可以简述如下:

  1. 写入操作记录:当Redis执行写操作时(如SET、INCR等),写入命令会追加到aof_buff(缓冲区)中。

  2. 文件同步:AOF缓冲区会根据配置定期进行同步到磁盘。

  3. AOF重写:为了避免AOF文件过大,Redis会定期进行AOF重写,达到压缩文件得目的。

3.1、触发方式

在redis.conf配置文件中,开启配置(默认不开启):

appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

持久化频率配置:

appendfsync always    # 每个写命令都同步,新的命令追加到aof文件,慢但安全

appendfsync everysec  # 每秒同步一次,丢失概率小

appendfsync no        # 从不主动同步,交给操作系统决定何时同步

3.2、AOF重写

当满足触发条件时,Redis会扫描整个实例的数据,重新生成一个AOF文件来完成一些多余命令的过滤,从而削减了文件大小。

重写流程:主进程fork出一个子进程进行AOF文件的重写,子进程重写完毕后,主进程把子进程重写期间,其他客户端产生的写请求,追加到AOF文件中,替换旧文件。

Redis从入门到放弃(6):持久化-LMLPHP

重写是如何缩减文件大小的,如:

  • 进程内已经超时的数据不再写入文件。
  • 旧的AOF文件含有无效命令,如del key1、hdel key2等。重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令。
  • 多条写命令可以合并为一个。

AOF有两种触发方式:

  • 手动触发:直接调用bgrewriteaof命令。
  • 自动触发:redis.config配置如下
auto-aof-rewrite-percentage 100    # 百分比,AOF文件的增长率达到

auto-aof-rewrite-min-size 64mb     # AOF文件大小达到多少

上述配置的含义是,当AOF文件大小增长到当前AOF文件大小的100%时,Redis会自动触发AOF重写操作;同时,AOF文件大小至少达到64MB时,才会执行AOF重写。

4、混合持久化

在Redis4.0后新增了一种混合模式:RDB+AOF,将两者的优点进行整合,混合方式采用AOF方式记录数据的变化,采用RDB的方式进行二进制文件存储。也就是在写入的时候先把数据以RDB的形式写入文件的开头,再将后续的写命令以AOF格式追加到文件中。

Redis从入门到放弃(6):持久化-LMLPHP

redis.conf开启配置如下:

# 混合持久化开关
aof-use-rdb-preamble yes

5、RDB与AOF的优缺点对比

5.1、RDB

优点:

  • 性能高:对Redis的性能影响较小,适用于要求高性能的场景。
  • 适用于备份:生成的快照文件紧凑且压缩,适合用于备份和灾难恢复。

缺点:

  • 数据丢失:定期生成快照,如果Redis发生故障,最后一次快照后的数据会丢失。
  • 不适用于大规模数据:对于大规模数据集,可能导致长时间阻塞。

5.2、AOF

优点:

  • 更高的数据安全性:记录每个写操作,数据更可靠,适用于要求数据实时持久性的场景。
  • 数据可读性:AOF文件以易读的文本格式记录,方便查看和理解。

缺点:

  • 相同数据集的数据而言AOF文件要远大于RDB文件,恢复速度慢于RDB
  • AOF文件较大:随着写操作的增加,AOF文件会变得庞大。

综合来看,对于不同的应用场景,可以根据需求选择适合的持久化方式。RDB持久化适用于要求高性能和定期备份的场景;AOF持久化适用于要求数据实时持久性和较高数据安全性的场景;混合持久化则可以在兼顾数据实时性和备份需求的同时,提供更好的性能和数据保护。在配置持久化时,建议根据具体业务需求,综合考虑数据安全性、性能、存储空间等因素,选择合适的持久化策略。

08-02 17:42