尽管 Redis 是基于内存的 key-value 服务,但也可以进行数据的持久化,以便服务重启,数据能重新加载进来。
为了尽可能的保证数据不丢失,Redis 为我们提供了好几种持久化机制:
下面,我们来看看这些机制吧。
在 redis.conf
文件里我们可以针对 RDB 持久化方式进行设置:
### 快照设置 ###
# save "" 空表示不进行持久化
save 900 1 # 900 秒内如果有1个 key 值改变,则进行持久化动作
save 300 10 # 300 秒内如果有10个 key 值改变,则进行持久化动作
save 60 10000 # 60 秒内如果有10000个 key 值改变,则进行持久化动作
# 如果持久化失败,则 Redis 不会再进行数据更新操作,直到恢复正常
stop-writes-on-bgsave-error yes
# 是否对持久化的 rdb 文件进行压缩保存
rdbcompression yes
# 是否对持久化的 rdb 文件进行校验
rdbchecksum yes
# 要持久化的 rdb 文件名
dbfilename example.rdb
# 导出目录
dir /opt/redisdata
同样的,我们可以在 redis.conf
文件里对 AOF 持久化进行配置:
appendonly no # 是否开启 aof
appendfilename "appendonly.aof" # aof 文件名
# 同步到磁盘的策略 默认每秒一次
# appendfsync always # 每次
appendfsync everysec # 每秒一次
# appendfsync no # 由操作系统执行,默认Linux配置最多丢失30秒
auto-aof-rewrite-percentage 100 # aof 文件超过比例则进行重写
auto-aof-rewrite-min-size 64mb # aof 文件超过多少则进行重写
aof-load-truncated yes # 如果 aof 最后的指令有误,则在重新恢复时忽略。
在上面的配置中,我们看到有关 aof 文件重写的配置。之所以需要对 aof 进行重写,是因为 aof 文件记录的是逻辑操作。随着系统运行越久,操作命令将越来越多,日志文件也就越来越大了,所以需要对其进行重写,以减少磁盘空间。
当 AOF 进行文件重写时,会将内存数据重新整理一遍,然后保存到新文件里,接着再将新文件替换原来的 AOF 文件。
为了能将 AOF 和 RDB 的优势结合起来, Redis 在 4.0 之后启用了混合持久化,它的配置如下:
aof-use-rdb-preamble yes
当开启了混合持久化后,Redis 会 fork 子进程将内存数据以 RDB 格式写入 AOF 文件,后面会将重写缓冲区的增量命令以 AOF 方式写入到文件。这样的话,新的 AOF 文件就同时拥有了 2 种格式的数据。
当需要使用混合文件进行恢复时,会先判断 AOF 文件的头部是否为 RDB 格式,是的话,先使用 RDB 的方式加载数据,接着再处理后面的 AOF 数据。
这样的话就能加快数据的恢复速度,又降低了数据丢失的风险。
当然, 这种混合方式会使得 AOF 文件变得复杂,可读性差,而且得是 4.0 版本以上才能使用。
Redis 的持久化都有它的特点,那我们应该选择哪种机制呢?
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。