Redis学习 | Redis数据持久化方案

440 阅读3分钟

这是我参与8月更文挑战的第31天,活动详情查看:8月更文挑战

前言

我认为Redis之所以会成为大家首选的缓存数据库的原因,第一是开源易用,第二则是我一直低估了的第二大优势,它支持数据持久化。

持久化

Redis所有的数据都保存在内存中,我们都知道,内存中的数据一旦关机,或者断电故障,数据就会被清空。为了防止数据丢失,Redis在将数据保存到内存中的时候,会异步的将数据保存到硬盘上。常见的持久化方案有两种,一种是快照,另一种为写日志。

快照(RDB)

将内存中所有的数据保存起来,存放在硬盘上,类似于MySQL数据库的备份。

  • reids创建RDB二进制文件,并且创建快照的过程中是通过覆盖的形式
  • redis启动时重新载入RDB二进制文件

触发方式

  • save 同步保存
  • bgsave 异步保存
  • 通过配置项,自动保存

RDB的配置项

# 自动保存策略,`60`秒内有一个`key`发生变化就自动保存
save 60 1
# rdb文件名
dbfilename dbdump.rdb
# rdb文件保存目录
dir ./
# 发生错误中断写入,建议开启
stop-writes-on-bgsave-error yes
# 数据文件压缩,建议开启
rdbcompression yes
# 开启crc64错误校验,建议开启
rdbchecksum yes

RDB的缺点

数据量越大,越耗时,耗费性能

日志(AOF)

将Redis运行过程中所有的执行命令记录全部保存下来,当我们需要恢复时,将所有命令按照顺序执行一遍。

实现方式

每次执行完命令,在AOF文件中追加日志,恢复的时候载入AOF文件,恢复数据 AOF的追加(fsync)策略

  • always 随时写入
    • 优点:不丢失数据
    • 缺点:IO开销较大,一般的sata盘只有几百TPS
  • everysec 每秒写入 推荐
    • 优点:每秒一次fsync,降低了开销
    • 缺点:会丢1s的数据
  • no 依赖os规则写入
    • 优点:没有
    • 缺点:不可控

AOF重写

对一些重复操作,会进行处理,只关注最终的状态,减少了执行的时间。举个例子,原生的AOF按顺序记录了 set hello java , set hello vue 重写后AOF就是set hello vue

image.png

实现方式

  • bgrewriteof命令
  • AOF重写配置

AOF配置

# 开启aof
appendonly yes
# aof日志文件名
appendfilename aof-3306.aof
# 每秒记录一次日志
appendfsnc everysec
# 重写过程中是否向日志文件中写入
# yes 带表rewrite过程中,不向aof文件中追加信息,rewrite结束后再写入
# no 带表rewrite执行的同时,也向aof追加信息
no-appendfsync-no-rewrite yes
# 触发重写文件增长百分比,默认100%
auto-aof-rewrite-percentage 100
# 触发重写最小aof文件大小
auto-aof-rewrite-min-size 64mb

扩展

Reids是单线程模型

为什么使用单线程?

  1. 内存处理的速度足够快,纳秒级别的处理速度。
  2. 非阻塞IOIO多路复用,基于时间完成读写
  3. 避免线程切换与资源竞争

注意事项

正因为单线程的特性,一次只能运行一条命令,所以一些执行慢的命令需要谨慎使用。比如keys/flushall/flushdb/exec/save/bgsave/...