Redis持久化:RDB与AOF详解


RDB和AOF持久化的由来?

因为Redis中的数据是基于内存的,所以如果出现服务器断电或者服务器宕机,那么Redis中存放的数据就会直接丢失。RDB和AOF就是针对Redis提供的两种持久化机制,可以将Redis中的数据持久化到磁盘中。当Redis实例故障重启后,就可以根据备份的文件来进行数据的恢复

二、RDB

概述:

RDB也被叫做Redis数据快照,简单来说就是把内存中所有的数据都记录在磁盘中,当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前的运行目录(RDB可以理解周期定时任务,任务内容就是全量备份数据
每次触发RDB的时候,就会重新生成一个新的RDB文件,覆盖旧的RDB文件文件,这样就可以确保备份得到最新的数据。

RDB的触发策略:

① 关闭Redis实例的时候,redis会在关闭之前主动的进行一次RDB(关闭不是宕机,宕机则数据丢失)
② 当你使用save/bgsave命令的时候,redis也会进行内存数据的持久化
③ 通过配置文件的配置触发:redis.conf配置文件

save 900 1
– 表示在900秒内,redis中有1个key发生改变,那么就进行一次bgsave
save 300 10
– 表示在300秒内,redis中有1个key发生改变,那么就进行一次bgsave
save 60 10000
– 表示在60秒内,redis中有10000个key发生改变,那么就进行一次bgsave

save/bgsave的不同

前面说到可以使用save命令或者bgsave命令来触发RDB,那么两者有什么区别呢?

  • 如果使用的是save命令,数据备份就是由主线程来操作的,由于Redis是单线程的,所以如果使用save命令来进行内存的数据备份,那么在数据备份的时候redis是无法响应用户的请求的。当需要备份的数据非常大的时候,就可能导致请求被阻塞超时的情况
  • 如果使用的是bgsave命令,那么实际上是主线程fork个子线程,让子线程来进行RDB操作,主线程只是在fork子线程的时候阻塞,之后便可以继续响应用户的请求。接下来子进程即可读取内存数据并进行持久化,生成新的RDB文件替换旧的RDB文件
RDB缺点:
  • RDB执行间隔时间长,两次RDB之间写入数据有丢失风险
  • fork子进程、压缩、写出RDB文件都比较耗时
RDB优点:
  • 使用RDB文件进行数据的恢复速度快、效率高(类似于文件拷贝)
  • 相比于AOF持久化的文件,RDB的文件更小
RDB的相关配置:
  • 在redis.conf配置RDB文件压缩
# 表示的是是否开启压缩,不建议开启,虽然节省空间,但是会耗费CPU
rdbcompression yes
  • 在redis.conf配置RDB文件名
# 默认的rdb文件名称
dbfilename dump.rdb
  • 在redis.conf配置rdb文件存放路径
dir ./
  • 在redis.conf配置触发策略
# 15分钟内有1个key发生改变,那么就保存
save 900 1
# 5分钟内有10个key发生改变,那么就保存
save 300 10
# 1分钟内有10000个key发生改变,那么就保存
save 60 10000
# 执行的都是bgsave

三、AOF

概述:

AOF的全称叫做Append Only File(追加文件)Redis处理的每一个命令都会记录在AOF文件中,可以看做是命令日志文件(AOF存放的不是数据本身而是执行redis写操作的命令,类似于存放insert/update等这类命令而不是数据

触发策略:根据配置文件触发redis.conf
  • 每执行一次命令,立即记录到AOF文件(性能最差,是有主进程执行)
appendfsync always
  • 写命令执行完先放入AOF缓存区,然后每间隔1s将缓冲区中的数据写到AOF文件,默认设置(性能较好,但是可能丢失1s内的数据)
appendfsync everysec
  • 写命令执行完先放入AOF缓冲区中,由操作系统决定合适写回磁盘(可靠性比较低,性能最好)
appendfync no

配置项

刷盘时机

优点

缺点

Always

同步刷盘

可靠性低,几乎不丢数据

性能影响大

everysec

每秒刷盘

性能适中

最多丢失1s数据

no

操作系统控制

性能最好

可靠性较差,可能丢失大量数据

AOF的重写机制:

由于AOF记录的是命令,那么当执行了很多命令的时候,就会记录到很多的冗余命令,例如:

# 添加key1的值
set key1 v1
# 修改key1的值
set key1 v2
# 删除key1的值
del key1

实际上key1最后被删除了,那么所有关于key1的命令实际上都是没有作用的,但是AOF中却记录了所有的命令,这样就会导致AOF文件很大而且存放了很多冗余命令。
通过使用bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同的效果,执行完该指令后,所以的冗余指令就会被删除,达到AOF文件压缩的效果。

AOF优点:
  • 通过配置,可以使得备份的数据更加完整安全
  • 每次进行AOF时占用的CPU资源较少(因为是追加,RDB则是全部重新复制一遍)
AOF缺点:
  • 通过使用AOF文件进行恢复的速度较慢,需要依次执行所有指令
  • AOF文件可能会比RDB大得多,记录的是所有的写操作
AOF配置:
  • 在redis.conf配置AOF开启
# 表示的是开启,默认是no
appendonly yes
  • 在redis.conf配置AOF文件名
# 这里表示的是AOF文件名称
appendfilename "appendonly.aof"
  • 在redis.conf配置重写触发策略
# AOF文件比上次文件增长超过百分之百则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才能触发重写
auto-aof-rewrite-min-size 64mb
四、RDB和AOF的对比

RDB

AOF

持久化方式

定时对整个内存做快照

记录每一次执行的命令

数据完整性

不完整,两次备份之间会丢失

相对完整,取决于刷盘策略

文件大小

会有压缩,文件体积较小

记录命令,文件体积很大

宕机恢复速度

很快


数据恢复优先级

低,因为数据完整性不如AOF

高,因为数据完整性更高

系统资源占用

高,大量CPU和内存消耗

低,主要是磁盘IO资源,但AOF重写时会占用大量CPU和内存资源

使用场景

可以容忍数分钟的数据丢失,追求更快的启动速度

对数据安全要求较高常见

五、知识点:
  • 默认方式开启的是RDB,AOF默认是关闭的
六、实际使用

在实际使用中,一般不会单独的开启其中的一个,一般都会使用两者结合的方式一并使用。RDB根据有容灾性,可以周期性的进行RDB得到指定时间点的备份文件。AOF则数据更加的完整,仅仅有非常少的数据的丢失。

你可能感兴趣的:(redis,redis,前端,数据库)