RDB
RDB持久化是把当前进程数据
生成快照
并保存到磁盘的过程
触发机制
-
手动触发
save和bgsave命令
-
自动触发
- 配置文件中的
save m n
表示m秒内存在n次修改,自动触发bgsave - 如果从节点全量复制, 主节点自动执行bgsave生成rdb文件,并发送给从节点
- 在没有开启aof时,执行shutdown命令时,自动执行bgsave
- 配置文件中的
save命令
阻塞当前Redis服务器,直到RDB过程完成为止
bgsave命令
AOF
AOF(append only file)持久化: 以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF默认不开启
启用aof需配置appendonly yes
AOF流程
- 命令写入:所有写入命令会追加到aof_buf缓冲区中
- 文件同步:根据对应的策略同步缓冲到磁盘
- 重写机制:定期对AOF文件进行重写
命令写入
AOF命令写入的内容直接是文本协议格式
文件同步
同步策略
appendfsync always
每次写入都立刻记入日志, 性能较差但数据完整性比较好
appendfsync everysec
每秒记入日志一次, 如果宕机, 最后一秒的数据可能丢失【建议配置,也是默认配置】
appendfsync no
不主动进行同步, 把同步时机交给操作系统
重写机制
为什么需要重写?
AOF采用文件追加方式, 文件会越来越大;为了避免出现此种情况, 新增了重写机制, 当AOF文件超过所设定的阀值时, redis 会启动内容压缩, 只保留恢复数据的最小指令集
重写后文件为什么变小?
- 进程内已经超时的数据不再写入文件
- 旧的AOF文件含有无效命令
- 多条命令可以合并为一条命令
触发重写的机制
-
手动触发
命令
bgrewriteaof
-
自动触发
自动触发时机 =
aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
比较
文件大小:rdb为二进制形式,文件更小
加载恢复快慢:rdb方式恢复数据更快
实时持久化:aof更好的保证实时性,更安全