redis的持久化有RDB和AOF两种方式。RDB(Redis Database)是redis在指定间隔将当前时间点的内存数据快照保存成一个二级制rdb文件。AOF(Append Only File)是将每一条写指令写入到特定日志文件,然后当服务重启时通过回放这些指令来恢复原来的数据集。redis可以同时开启RDB和AOF。当然如果只是使用redis来当作缓存使用,也可以不开启持久化,RDB和AOF都不开启。
RDB(Redis Database)
默认情况下redis是开启RDB持久化的。将快照文件存储在一个叫dump.rdb的文件。文件名可以通过dbfilename配置项来指定,文件位置可以通过dir配置项来指定。
dbfilename dump.rdb
dir data/6379/
rdb文件的存盘时机可以通过save配置项来配置
save <seconds> <changes>
表示在多少秒内至少有多少个写操作指令发生时触发存盘操作。
如下面默认的配置
#900秒内至少有一次写操作
save 900 1
#300秒内至少有10次写操作
save 300 10
#60秒内至少有10000次写操作
save 60 10000
如果在配置文件中一个save配置也没有,则代表关闭了RDB。
除了通过save配置进行周期性的自动生成RDB文件,还可以通过save和bgsave两个指令来手动触发快照的生成。
快照生成过程:
当Redis触发RDB持久化时,会fork一个子线程用来处理快照生成。这个子进程负责将内存中的数据dump到一个临时rdb文件中。当dump完成后,新的rdb文件会替换原来的rdb文件。
快照生成过程中redis可以处理写操作吗?
rdb持久化的子进程是由主进程fork出来的,可以共享主线程的所有内存数据。bgsave 子进程运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。而在这个过程中,主线程仍然可以直接修改原来的数据。这里Redis 借助操作系统提供的写时复制技术(Copy-On-Write, COW),如果主线程要修改一块数据,那么,这块数据就会被复制一份,生成该数据的副本。然后,bgsave 子进程会把这个副本数据写入 RDB 文件。
RDB持久化可能会对Redis的性能造成一些影响,特别是在写操作较多的情况下。尽管Redis可以继续处理请求,但创建快照时的I/O操作可能会导致延迟。
AOF(Append Only File)
开启AOF日志比较简单,在配置文件添加如下配置即可
appendonly yes
开启AOF日志后每个写操作都将记录到aof日志文件中。
执行几条写命令
127.0.0.1:6380> set name hello
OK
127.0.0.1:6380> set nums 2
OK
127.0.0.1:6380> set nums 3
OK
127.0.0.1:6380> set nums 4
OK
查看aof日志文件,日志文件在data配置项指定的目录下,文件名是appendonly.aof
set^M
$4^M
name^M
$5^M
hello^M
*3^M
$3^M
set^M
$4^M
nums^M
$1^M
2^M
*3^M
$3^M
set^M
$4^M
nums^M
$1^M
3^M
...
这里看到每个执行的写命令都会记入到AOF日志文件中。
写入策略
AOF通过appendfsync
参数来控制日志持久化到文件的策略,该参数有以下结果选项可以配置:
always:每次写操作都会将 AOF 文件同步到磁盘。这确保了数据的持久性,但会显著增加 I/O 操作,可能影响性能。
everysec:每秒钟将 AOF 文件同步到磁盘一次。这是一个折衷方案,提供了较好的性能和数据持久性。大多数情况下推荐使用这个选项,因为它在性能和数据安全性之间提供了平衡。
no:不强制将 AOF 文件同步到磁盘,而是依赖操作系统的缓存机制。这种设置可能会带来较高的性能,但数据丢失的风险也更大,因为可能会丢失最近未同步到磁盘的操作。
日志重写
AOF日志会将每一个写命令写入日志文件,随着时间的推移,日志文件会越来越大。redis数据集中的数只需要保存最终的结果即最新的结果信息,中间的过程没必要记录,比如一个计数的key从0累计到100中间会有99条set指令是过程记录,如果这些记录在aof中存放,在日志重放过程中也没必要保留,只需要知道当前key值是100即可。这时候就需要日志rewrite来优化AOF日志,基本上一个key使用一个写入命令,来简化AOF日志。
和日志重写相关的配置有以下两个
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage
:设置触发 AOF 重写的百分比,默认值为 100,意味着 AOF 文件增长了一倍时会触发重写。auto-aof-rewrite-min-size
:设置触发 AOF 重写的最小文件大小,默认值为 64MB。
AOF日志重写是由后台线程 bgrewriteaof 来完成的,不会阻塞主线程。
总结
RDB持久化对Redis的性能影响相对较小,因为它是通过创建数据库的快照来实现的。这种方式在生成快照的过程中,Redis会在后台执行,而不会对主线程的操作产生显著影响。RDB文件是经过优化的二进制格式,能够快速加载。相较于AOF文件,RDB在恢复数据时通常比AOF更快,适合需要快速恢复的场景。RDB文件可以方便地用于备份和迁移数据,因为它们是单个文件,易于复制和移动。也适合用于离线备份和灾难恢复。RDB持久化不会像AOF那样持续不断地记录操作日志,因此对磁盘I/O的压力较小,适合对I/O性能有严格要求的场景。RDB提供的数据一致性较好,因为在快照生成时,Redis会冻结数据库状态,使得快照的一致性得到保证。RDB也有一些缺点,比如数据恢复到最近一次快照的时间点可能会丢失一定量的数据。
AOF 通过记录每个写操作来持久化数据,通常可以通过配置将数据丢失降到最小。数据恢复更加精确。AOF 文件可能比 RDB 文件大,恢复速度相对也会比较慢。
在实际应用中,许多 Redis 部署会同时使用 RDB 和 AOF,这样可以兼顾性能和数据安全。通过这种方式,可以利用 RDB 的快速备份和恢复能力,同时通过 AOF 提供更高的数据完整性保障。