Redis是一个内存数据库,数据保存在内存中。但我们都知道存储在内存中的数据会因为外部因素而丢失,所以Redis会把数据持久化到磁盘中,至于是如何持久化呢?

一、RDB

1.手动触发

  • save:该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。
  • bgsave:执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

2.自动触发

  • 根据redis.conf配置里的save m n定时触发(用的是BGSAVE)

  • 主从复制时,主节点自动触发

  • 执行Debug Relaod

  • 执行Shutdown且没有开启AOF持久化

# 在几秒内改动了多少数据就触发持久化
# 想禁用的话不设置save   或者save ""
save 900 1
save 300 10
save 60 10000
# 备份进程出错主进程停止写入操作
stop-writes-on-bgsave-error yes
# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu更值钱
rdbcompression yes

3.优缺点

优点:

  • 只会生成一个文件,方便操作,文件小
  • 相对AOF来说,恢复大数据集的速度快
  • 在RDB持久化开始时,只会fork一个子线程处理所有的持久化工作,不会影响到父系线程

缺点:

  • 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
  • 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

二、AOF

  全量备份总是耗时的,有时候我们提供一种更加高效的方式AOF,工作机制很简单,redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

  • 记录除了查询以外的所有变更数据库状态的指令

  • 以append的形式追加保存到AOF文件中(增量)

  • 日志重写解决AOF文件不断增大的问题,原理如下

    • 调用fork,创建一个子进程

    • 子进程把新的AOF写到一个临时文件里,不依赖原来的AOF文件

    • 主进程持续将新的变动同时写到内存和原来的AOF里

    • 主进程获取子进程重写AOF完成信号,往新AOF同步增量变动

    • 使用新的AOF文件替换掉旧的AOF文件

# 默认关闭若要开启将no改为yes
appendonly no
# append文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# always一旦缓存区内容发生变化就写入AOF文件中
appendfsync always
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 将写入文件的操作交由操作系统决定
appendfsync no
# 当AOF文件大小的增长率大于该配置项时自动开启重写(这里指超过原大小的100%)。
auto-aof-rewrite-percentage 100
# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

优点:

  • AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据。
  • AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
  • AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
  • AOF日志文件的命令通过非常可读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。

缺点:

  • AOF日志文件相对于RDB来说会更大
  • AOF开启后,支持的写QPS会比RDB支持的写QPS低
  通过对比可以看出单独使用AOF和RDB都存在不少都问题,所以在redis4.0之后,带来了新的持久化选项——混合持久化。

三、RDB-AOF混合持久化

  如果开启了混合持久化,aof在重写时,不再是单纯将内存数据转换为RESP命令写入aof文件,而是将重写这一刻之前的内存做rdb快照处理,并且将rdb快照内容和增量的aof修改内存数据的命令存在一起,都写入新的aof文件,新的aof文件一开始不叫appendonly.aof,等到重写完成后,新的aof文件才会进行改名,原子的覆盖原有的aof文件,完成新旧两个aof文件的替换。
于是在redis重启的时候,可以先加载rdb文件,然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放,因此重启效率大幅得到提高。
  简单说就是BGSAVE做镜像全量持久化,AOF做增量持久化。
深入了解Redis(6)-持久化原理-LMLPHP注:图来自网络

如果redis没有升级到4.0,优先选择 RDB 还是 AOF 呢?

分析对比两种方式并做了测试后,发现这是两种不同风格的持久化方式。那么应该如何选择呢?

  • 对于企业级的中大型应用,如果不想牺牲数据完整性但是又希望保持高效率,那么你应该同时使用 RDB 和 AOF 两种方式。
  • 如果你不打算耗费精力在这个地方,只需要保证数据完整性,那么优先考虑使用 AOF 方式。
  • RDB 方式非常适合大规模的数据恢复,如果业务对数据完整性和一致性要求不高,RDB 是很好的选择。
09-29 23:23