Redis作为一种高性能的内存数据存储系统,常被用作缓存、会话存储、消息队列等多种应用场景。然而,由于其数据存储在内存中,一旦发生意外或服务器重启,数据就会丢失。为了保障数据的持久性和安全性。
Redis提供了多种持久化方案:
本文将探究以上三种持久化技术的工作原理、优缺点以及适用场景。
RDB是Redis的默认持久化方式。它通过定期或手动执行快照将内存中的数据保存到磁盘上(dump.rdb)。触发RDB持久化过程分为手动触发和自动触发。
那么SAVE和BGSAVE两个命令有什么区别呢?
SAVE:主线程操作,同步执行,会阻塞其它命令的执行。执行[save]命令时,RDB快照生成如果时间过长,后续请求会被阻塞,客户端新发送所有命令都会被拒绝。因此在生产环境中要谨慎使用该命令,避免影响服务的正常运行。
BGSAVE:写时复制,异步执行,不会阻塞其它命令的执行,会fork一个子进程进行操作,但这样比较消耗内存。主进程依旧保持与客户端的连接,正常执行读写命令。
SAVE命令使用方法:
127.0.0.1:6379> SAVE
BGSAVE使用方法:
127.0.0.1:6379> BGSAVE
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持久化。
AOF持久化(Append Only File)以追加日志的形式记录Redis每个写操作并写入到一个文件中,即【appendonly.aof】文件。
AOF持久化过程可以简述如下:
在redis.conf配置文件中,开启配置(默认不开启):
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
持久化频率配置:
appendfsync always # 每个写命令都同步,新的命令追加到aof文件,慢但安全
appendfsync everysec # 每秒同步一次,丢失概率小
appendfsync no # 从不主动同步,交给操作系统决定何时同步
当满足触发条件时,Redis会扫描整个实例的数据,重新生成一个AOF文件来完成一些多余命令的过滤,从而削减了文件大小。
重写流程:主进程fork出一个子进程进行AOF文件的重写,子进程重写完毕后,主进程把子进程重写期间,其他客户端产生的写请求,追加到AOF文件中,替换旧文件。
重写是如何缩减文件大小的,如:
AOF有两种触发方式:
auto-aof-rewrite-percentage 100 # 百分比,AOF文件的增长率达到
auto-aof-rewrite-min-size 64mb # AOF文件大小达到多少
上述配置的含义是,当AOF文件大小增长到当前AOF文件大小的100%时,Redis会自动触发AOF重写操作;同时,AOF文件大小至少达到64MB时,才会执行AOF重写。
在Redis4.0后新增了一种混合模式:RDB+AOF,将两者的优点进行整合,混合方式采用AOF方式记录数据的变化,采用RDB的方式进行二进制文件存储。也就是在写入的时候先把数据以RDB的形式写入文件的开头,再将后续的写命令以AOF格式追加到文件中。
redis.conf开启配置如下:
# 混合持久化开关
aof-use-rdb-preamble yes
优点:
缺点:
优点:
缺点:
综合来看,对于不同的应用场景,可以根据需求选择适合的持久化方式。RDB持久化适用于要求高性能和定期备份的场景;AOF持久化适用于要求数据实时持久性和较高数据安全性的场景;混合持久化则可以在兼顾数据实时性和备份需求的同时,提供更好的性能和数据保护。在配置持久化时,建议根据具体业务需求,综合考虑数据安全性、性能、存储空间等因素,选择合适的持久化策略。