- 基于快照的持久化机制：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()函数的主要工作流程如下图所示：
