RDB快照(snapshot)
Redis配置默认情况下持久化使用的是RDB快照的方式,数据持久化存储的文件名为dump.rdb,数据持久化以二进制的方式保持在文件中。redis.conf中持久化的默认配置如下:
# If the background saving process will start working again Redis will
# automatically allow writes again.
stop-writes-on-bgsave-error yes
# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
# The filename where to dump the DB
dbfilename dump.rdb
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./
可以配置redis持久化的触发机制,让它在”N秒内数据集至少有M个改动“条件满足时,自动保存一次数据集。如redis.conf配置:
# Save the DB on disk:
#
# save <seconds> <changes>
save 900 1
save 300 10
save 60 10000
还可以手动执行命令生成RDB快照,每次命令执行都会将所有redis内存快照到一个新的rdb文件里面,并覆盖原有的rdb快照文件。
127.0.0.1:6379> save
127.0.0.1:6379> bgsave
bgsave的写时复制(COW)机制
Redis借助操作系统提供的写时复制(Copy-On-Write),在生成快照的同时,依然可以正常处理写命令。Redis主线程fork出一个bgsave子线程,可以共享主线程的所有内存数据。bgsave子线程开始运行后,读取主线程的内存数据,并把它们写入RDB文件,此时如果主线程对这些数据都是读的操作,主线程和bgsave子线程互不影响。如果主线程修改一块数据,那么这块数据会被复制一份,生成数据副本,bgsave子线程会把这个副本数据写入RDB文件,而这个过程中,主线程仍然可以执行修改原来的数据。
save与bgsave对比
命令 | save | bgsave |
IO类型 | 同步 | 异步 |
是否阻塞redis的其它命令 | 是 | 否(在生成子进程执行调用fork函数时会有短暂的阻塞) |
复杂度 | O(n) | O(n) |
优点 | 不会消耗而外内存 | 不阻塞客户端命令 |
缺点 | 阻塞客户端命令 | 需要fork子进程,消耗内存 |
AOF(append-only file)
AOF持久化,将修改的每一条指令记录到文件appendonly.aof中,先写入os cache,每个一段时间sync到磁盘。可以通过修改Redis的配置文件redis.conf来开启AOF功能,开启AOF功能后,Redis重启时,就可以通过执行AOF文件中的命令来达到重建数据集的目的,在Redis的配置文件中还可以配置Redis多久将数据fsync到磁盘。
# 开启AOF
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
# 数据同步刷新到磁盘配置
# 每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全。
# appendfsync always
# 每秒 fsync 一次,足够快,并且在故障时只会丢失 1 秒钟的数据。
appendfsync everysec
# 从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。
# appendfsync no
AOF采用resp协议的数据格式将数据集存储到appendonly.aof文件中,如执行“set warrior 1” 对应aof文件记录的数据如下:
*3
$3
set
$7
warrior
$1
1
星号后面的数字代表命令有多少个参数
$号后面的数字代表这个参数有几个字符
AOF重写
AOF文件里面可能有太多没用的指令,所以AOF会定期根据内存中的最新数据生成aof文件,可以通过Redis的配置文件redis.conf中的两个配置项进行控制AOF自动重写的频率。
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
# aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100
# aof文件至少要达到64M才会自动重写,文件太小恢复速度本来就很快,重写的意义不大
auto-aof-rewrite-min-size 64mb
AOF也支持手动重写,在redis客户端执行 bgrewireaof重写AOF, AOF重写redis会fork出一个子进程去做,不会对redis正常命令处理有太多的影响。
RDB与AOF的选择
命令 | RDB | AOF |
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 容易丢失数据 | 根据策略决定 |
生成环境都可以启用,redis启动时如果既有rdb文件又有aof文件,则优先选择aof文件恢复,因为aof文件一般来说数据更安全一点。
Redis 4.0 混合持久化
Redis 4.0版本之后支持混合持久化配置,如果开启了混合持久化,AOF在重写时,不在单纯的将内存数据转换为resp格式命令写入AOF文件,而是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改内存数据的命令一起写入AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖原有的AOF文件,完成新旧两个AOF文件的替换。
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
# 必须先开启aof
aof-use-rdb-preamble yes
![](https://i-blog.csdnimg.cn/blog_migrate/b01d952ccea0d18193d9699037223c12.png)
Redis数据备份策略
写crontab定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48小时的备份
每天都保留一份当日的数据备份到一个目录中去,可以保留最近1个月的备份
每次copy备份的时候,都把太旧的备份给删了
每天晚上将当前机器上的备份复制一份到其他机器上,以防机器损坏