Redis持久化机制详解

虚幻0516

Redis提供两种持久化机制，供用户灵活的选用、组合使用：

• 基于快照的持久化机制：rdb
  
• 基于日志的持久化机制：aof
  

1.快照
1.1 基于快照的持久化
基于快照的持久化（rdb）：在系统满足用户设置的条件（时间间隔和累计的写操作次数两方面）时，触发系统向磁盘写入快照从而达到数据持久化的目的。系统将向磁盘写入一个.rdb文件作为所有数据的dump。这个.rdb文件也可以作为备份文件。

快照机制的缺陷也是比较明显的：在两次快照之间，可能有显著的数据丢失。

1.2 源码总结
从代码角度分析，rdb机制的代码调用关系可以用下图总结：

不难分析发现：rdbSave()函数是rdb机制的底层核心实现。触发rdb的时机主要有：

• 客户端发送SAVE/BGSAVE/FLUSHALL/SHUTDOWN命令
  
• Sentinel触发
  
• 主从复制中，rdb作为从主节点到从节点的数据复制机制
  

rdbSave()的主要工作流程:


1.3 两个设计要点

• 当使用background save时，Redis的快照机制充分利用了Linux 的Copy On Wirte机制。向磁盘写快照的工作由新fork出来的子进程完成，不影响主服务进程的运行。基于Copy On Write策略，子进程由于没有进行任何写操作，可以从父进程的内存空间中直接读取数据写入磁盘。
  
• 快照是直接从最终数据集中读取数据写入磁盘的，所以，所有事务要不全部执行完成，要不根本不存在在快照中
  

2. 日志
2.1 基于日志的持久化
基于日志的持久化机制把每一条修改了数据集的命令都通过APPEND的方式写入到日志。一旦出现实例宕机，重启后Replay日志就可以恢复数据。

2.2 源码总结
基本工作流程如下图所示：

• 每条命令的具体执行都会调用call()函数，如果该命令涉及到写操作，那么会调用progagate()函数来传播写操作到AOF和slaves。
  
• 传播到AOF的工作由feedAppendOnlyFile()完成，主要工作是分析翻译命令写入命令缓存aof_buf。详细流程图见下面附图。
  
• 在每一条命令执行前检查aof_buf，并根据aofsync配置调用flushAppendOnlyFile()函数写入到磁盘
  
• 当AOF文件太大的时候会进行AOF Rewrite，直接从内存数据集中拉取数据，新建最小的日志文件
  

feedAppendOnlyFile()函数的主要工作流程如下图所示：