redis支持四种持久化方式,一是 Snapshotting(快照)也是默认方式(RDB);二是Append-only file(缩写aof)的方式;三是虚拟内存方式;四是diskstore方式。
RDB的实现方式为,在指定时间将当前时刻内存中的数据生成一个快照文件(.rdb文件,默认为dump.rdb),并将这个快照文件保存到磁盘上。这样,即使redis宕机了,下次重启时也可以通过读取这个快照文件来恢复数据。
rdb文件默认文件名为dump.rdb,是在配置文件中
触发生成rdb快照文件的方式主要有五种:配置文件自动触发、执行save命令、执行bgsave命令、执行shutdown命令、执行flushall命令。
redis默认的配置文件redis.conf中,有一个自动触发rdb持久化的配置:
-
- # 时间策略
- save 3600 1 -> 3600秒内有1个key被修改,则触发RDB
- save 300 100 -> 300秒内有100个key被修改,则触发RDB
- save 60 10000 -> 60秒内有10000个key被修改,则触发RDB
-
- # 文件名称
- dbfilename dump.rdb
-
- # 文件保存路径
- dir /home/work/app/redis/data/
-
- # 如果持久化出错,主进程是否停止写入
- stop-writes-on-bgsave-error yes
-
- # 是否压缩
- rdbcompression yes
-
- # 导入时是否检查
- rdbchecksum yes
当满足其中任意一个save条件时,都会触发一次bgsave命令进行异步持久化。
save命令是一个同步操作,执行该命令后,RDB持久化是在主进程中进行的,这样会阻塞当前redis服务,直到RDB持久化完成后,客户端才能正常连接redis服务。
bgsave命令是对save命令的一个优化,是一个异步操作。执行该命令后,redis主进程会通过fork操作创建一个子进程,RDB持久化是由子进程操作,完成后自动结束。这个过程中,主进程不阻塞,可以继续接收客户端的访问。因此,redis内部所有涉及RDB持久化的操作都是采用的bgsave方式,save命令基本已经废弃。
在客户端执行shutdown命令即可
flushall命令是清空redis内存中的数据,并且同时清空dump.rdb文件。所以这个命令就相当于删库跑路,此处只是说明该命令会触发rdb,实际使用中千万不要执行。
AOF是redis提供的另一种数据持久化方式,它会记录客户端对redis服务端的每一次写操作,并将这些写操作以redis协议追加保存到后缀为aof的文件末尾。在redis服务器重启时,会读取并加载aof文件,达到恢复数据的目的。
aof持久化方式redis是默认不开启的,我们可以通过配置文件开启aof持久化方式:
- # 是否开启aof,默认是no
- appendonly yes
-
- # 文件名称
- appendfilename "appendonly.aof"
-
- # 同步方式
- #appendfsync always #每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
- #appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐
- #appendfsync no #完全依赖os,性能最好,持久化没保证
- appendfsync everysec
-
- # aof重写期间是否同步
- no-appendfsync-on-rewrite no
-
- # 重写触发配置
- #auto-aof-rewrite-percentage 100:当文件的大小达到原先文件大小(上次重写后的文件大小,如果没有重写过,那就是redis服务启动时的文件大小)的两倍。
- #auto-aof-rewrite-min-size 64mb:文件重写的最小文件大小,即当AOF文件低于64mb时,不会触发重写。只有这两个指标同时满足的时候才会发生重写。
-
- auto-aof-rewrite-percentage 100
- auto-aof-rewrite-min-size 64mb
-
- # 加载aof时如果有错如何处理
- aof-load-truncated yes
-
- # 文件重写策略
- aof-rewrite-incremental-fsync yes
RDB的优点:
RDB的缺点:
AOF的优点:
AOF的缺点: