Redis 数据持久化策略
2021-06-15 本文已影响0人
Ansme
Redis 数据持久化策略
redis 是基于内存的非关系型数据库,一旦服务器进程推出,数据库中的数据就会丢失,reids 为了解决这类问题,提供了两种持久化方式,RDB 和 AOF,将内存中的数据保存到磁盘中,避免数据丢失
RDB(快照)
工作原理
- redis 主进程会 fork 出一个子进程
- 子进程把数据写到一个临时的
RDB
文件 - 子进程写完数据后用新的
RDB
文件把旧的RDB
文件替换掉
优点
- RDB 文件是一个经过压缩的二进制文件,它保存了某个时间点的 redis 数据,适合做定时备份
- RDB 在使用
BGSAVE
命令时,主进程 fork 一个子进程出来,子进程进行持久化的工作,主进程不会阻塞 - RDB 在 redis 启动时如果检测到
RDB
文件,会自动载入这个文件,数据量较大的情况下,RDB
的启动速度更快
缺点
- RDB 容易造成数据的丢失,假设 redis 定期保存快照,如果 redis 因为异常原因无法正常工作,那么从上次保存快照到 redis 出现问题的这段时间内的数据就会丢失
- RDB 使用
fork()
产生子进程进行数据持久化,如果数据量较大,fork 过程会花费一定的时间,可能会造成 redis 停止服务一定时间
配置方式
# RDB文件名,默认为dump.rdb。
dbfilename dump.rdb
# 文件存放的目录,AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./
# 保存点可以设置多个
save 900 1 # 900 秒后至少有 1 个 key 有变动
save 300 10 # 300秒后至少10个key有变动
save 60 10000 # 60秒后至少10000个key有变动
save "" # 禁用快照保存的功能
AOF (追加文件)
工作原理
- AOF 是备份数据库接收到的命令
- 除了指定数据库的
select
命令,其他的命令都是来自client
的,这些命令会以追加的形式保存到文件中 - redis 自动载入 AOF 文件,创建一个虚拟的
client
把AOF
中的每一条命令都执行一遍,最终还原数据库的状态 - redis 在
RDB
和AOF
备份文件都存在的情况下,优先载入AOF
备份文件
优点
- AOF 比 RDB 更加可靠,可定制不同的
fsync
策略:不进行fsync
, 每秒fsync
一次和每次查询进行fsync
- AOF 日志文件是一个纯追加的文件,日志文件比较安全,不易损坏,就算损坏也可以使用
redis-check-aof
命令进行简单的修复 - 当AOF文件太大时,Redis会自动在后台进行重写,重写在一个新的文件上进行,同时 redis 会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完,redis 会把新旧文件进行切换,然后开始把数据写到新文件上
- AOF 备份文件存储的是简单易懂的一条一条的操作命令,很容易导出来用于恢复数据
缺点
- 在相同的数据集下,AOF 文件的大小一般会比 RDB 文件大
- 在某些 fsync 策略下,AOF 的速度会比 RDB 慢
配置方式
# 启用AOF
appendonly yes
# 文件存放目录,与RDB共用。默认为当前工作目录。
dir ./
# 默认文件名为appendonly.aof
appendfilename "appendonly.aof"
# 备份频率
appendfsync always # 每次更新数据都写入仅增日志文件。慢,但是最安全
appendfsync everysec # 每秒调用一次,折中
appendfsync no # 不调用,等待操作系统来清空缓冲区当操作系统要输出数据时。很快。
(如有错误,欢迎指正)