持久化

How Redis writes data to disk

RDB–Redis DataBase

RDB 持久性以指定的时间间隔执行数据集的时间点快照。

实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。**这个快照文件就称为RDB文件(dump.rdb)**，其中，RDB就是Redis DataBase的缩写。

自动触发

手动触发

Save

在主程序中执行会阻塞当前Redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他任务

BGSAVE（默认）
  • Redis会在后台异步进行快照操作，不阻塞快照同时还可以影响客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程
  • Redis会使用当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就是允许主进程同时可以修改数据
  • lastsave可以获取最后一次成功执行快照的时间

优点

  • 适合大规模的数据恢复
  • 按照业务定时备份
  • 对数据完整性和一致性要求不高
  • RDB文件在内存中的加载速度要比AOF快得多

缺点

  • 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
  • 内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
  • RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟，fork的时候内存中的数据被克隆一份，大致2倍的膨胀性，需要考虑

修复dump.rdb文件

redis-check-rdb dump6379.rdb

触发快照的条件

  • 配置文件中默认的快照设置
  • 手动save/bgsave命令
  • 执行flushall/fushdb命令也会产生dump.rdb文件，但是里面是空的，无意义
  • 执行shutdown且没有设置开启AOF持久化
  • 主从复制时，主节点会自动触发

AOF–Append Only File

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换而言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次完成数据的恢复工作

默认情况下，redis是没有开启AOF的，开启AOF功能需要配置：appendonly yes

  • aof保存的是appendonly.aof文件

AOF持久化流程

  1. Client作为命令的来源，会有多个源头以及源源不断的命令
  2. 在这些命令到达Redis Server以后并不合适直接写入AOF文件，会将其这些命令先放入AOF进行保存。这里的AOF缓存区实际上是内存中的一片区域，存在的目的是在这些命令达到一定量以后再写入磁盘，避免频繁的IO操作
  3. AOF缓存会根据AOF缓存区同步文件的三种协会策略将命令写入磁盘上的AOF文件
  4. 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并（又称AOF重写），从而起到AOF文件压缩的目的
  5. 当Redis Server服务器启动的时候会从AOF文件载入数据
三种写回策略
  • always：同步写回，每个命令执行完立即同步将日志写回磁盘
  • everysec：每秒写回，每个写命令执行完，只有先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
  • no：操作系统控制的写回，每个写命令执行完，只是把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

混合使用

RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写