作为内存数据库，Redis 依然提供了持久化机制，其主要目的有两个：
- 安全：保证进程崩溃后数据不会丢失
- 备份：方便数据迁移与快速恢复
Redis 同时提供两种持久化机制：
- RDB 快照：数据库在某个时间点的完整状态，其存储内容为键值对
- AOF 日志：包含所有改变数据库状态的操作，其存储内容为命令
RDB 快照
生成 RDB 快照的方式有两种：
- 服务进程定期生成
- 手动执行 SAVE 或 BGSAVE 命令
定期生成
用户可以通过设置保存点save point，控制 RDB 快照的自动生成：
save 900 1 # 最近 15 分钟内，至少有 1 个 key 发生过变更
save 300 10 # 最近 5 分钟内，至少有 10 个 key 发生过变更
save 60 10000 # 最近 1 分钟内，至少有 10000 个 key 发生过变更
struct saveparam {
time_t seconds; // 秒数
int changes; // 变更数
};
struct redisServer {
// ...
struct saveparam *saveparams; /* RDB 保存点数组 */
int saveparamslen; /* 保存点数量 */
long long dirty; /* 上一次执行快照后的变更数 */
time_t lastsave; /* 上一次执行快照的 UNIX 时间戳 */
}
+---------------+
| redisServer |
+---------------+ +---------------+---------------+---------------+
| saveparams | -> | saveparams[0] | saveparams[1] | saveparams[2] |
+---------------+ +---------------+---------------+---------------+
| saveparamslen | | seconds | seconds | seconds |
| 3 | | 900 | 300 | 60 |
+---------------+ +---------------+---------------+---------------+
| dirty | | changes | changes | changes |
| 120 | | 1 | 10 | 10000 |
+---------------+ +---------------+---------------+---------------+
| lastsave |
| 1378270800 |
+---------------+
自动保存的过程：
- 每执行一个数据库修改命令，计数器 dirty 就会记录该记录导致的变更数量
- Redis 的定时任务
serverCron会周期性地检查是否满足保存点条件：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
// ...
for (j = 0; j < server.saveparamslen; j++) {
struct saveparam *sp = server.saveparams+j;
if (server.dirty >= sp->changes && // 检查变更数是否足够
server.unixtime-server.lastsave > sp->seconds) // 检查最近一次快照时间
{
// 如果当前状态满足保存点设置，打印日志并开始执行 BGSAVE
serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...", sp->changes, (int)sp->seconds);
// ...
// 执行 BGSAVE
rdbSaveBackground(server.rdb_filename,rsiptr);
break;
}
}
}
手动备份
为了避免在流量高峰期发生性能抖动，在生产环境中往往会关闭 Redis 的自动生成快照的功能。为了保证数据安全，此时运维会使用定时脚本的方式，在系统空闲时执行 BGSAVE 命令备份 Redis 数据。
int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
// ...
if ((childpid = redisFork(CHILD_TYPE_RDB)) == 0) { // 产生子进程
/* 子进程负责生成 RDB 快照 */
int retval = rdbSave(filename,rsi);
// ...
} else {
/* 主进程不阻塞直接返回 */
serverLog(LL_NOTICE,"Background saving started by pid %d",childpid);
updateDictResizePolicy(); // 如果子进程正生成快照，禁止 dict 进行 rehash 操作
// ...
return C_OK;
}
}
RDB 文件由子进程生成的，操作系统写时复制 copy-on-write 的优化特性，决定了父子进程间的内存在逻辑上是独立的。
因此主进程所产生的任何修改操作都不会被包含在 RDB 文件中，间接保证了 RDB 所记录状态的一致性。
RDB 文件
RDB 快照是一个二进制文件，其格式大致如下：
# 有 n 个数据库的 RDB 文件
+-------+------------+-------+-----+-------+-----+-----------+
| REDIS | db_version | db[0] | ... | db[n] | EOF | check_sum |
+-------+------------+-------+-----+-------+-----+-----------+
# 每个数据库包含任意长度的键值对
+-------+ +----------+---+------------+-----+------------+
| db[0] | => | SELECTDB | 0 | kv_pair[0] | ... | kv_pair[n] |
+-------+ +----------+---+------------+-----+------------+
# 键值对，常量 TYPE 指示了 value 的编码类型
+---------+ +------+-----+-------+
| kv_pair | => | TYPE | key | value |
+---------+ +------+-----+-------+
# 带过期时间的键值对，常量 EXPIRETIME_MS 紧接着一个 8 字节的时间戳
+------------------+ +---------------+--------------+------+-----+-------+
| kv_pair_with_ttl | => | EXPIRETIME_MS | ms_timestamp | TYPE | key | value |
+------------------+ +---------------+--------------+------+-----+-------+
RDB 快照存储了数据库在某个时间点的完整状态，且格式紧凑，十分适合作为数据备份：
- 方便通过网络传输到异地机柜，实现多机房容灾
- 通过使用 RESTORE 命令加载 RDB 快照，可以实现数据初始化或者紧急回滚
AOF 日志
生成 RDB 快照的过程比较耗时，无法频繁执行 BGSAVE。但如果状态变更长时间不落盘，一旦进程崩溃，将会丢失大量未持久化的数据。
为了避免全量备份的开销，Redis 支持以增量更新的方式，将状态变更持久化到 AOF 日志中，减少对磁盘 I/O 的压力。
由于 AOF 日志落盘是由主线程完成的，因此落盘策略会明显影响到 Redis 的性能。下列配置项可用于控制这一行为：
appendonly no # 是否开启 AOF
# 落盘策略
# always：每次发生变更会立即落盘
# everysec：每秒落盘一次
# no：由操作系统决定落盘时机
appendfsync everysec
struct redisServer {
// ...
int aof_enabled; /* AOF 开关 */
int aof_state; /* AOF 状态（开启、关闭、等待重写）*/
int aof_fsync; /* fsync 策略 */
sds aof_buf; /* AOF 缓冲 */
time_t aof_flush_postponed_start; /* AOF 延迟刷新 UNIX 时间戳 */
}
追加命令
每当成功执行完一条命令，会通过 processCommand -> call -> propagate -> feedAppendOnlyFile 这条调用链，将命令写入 AOF 缓存：
void feedAppendOnlyFile(struct redisCommand *cmd, int dictid, robj **argv, int argc) {
// 将命令追加到缓冲末尾，在向客户端返回结果前将其写入 AOF 文件中
if (server.aof_state == AOF_ON)
server.aof_buf = sdscatlen(server.aof_buf,buf,sdslen(buf));
// 如果有子线程正在执行 AOF 重写，期间会将新增的修改记录入一个新的 AOF 日志
if (server.aof_child_pid != -1)
aofRewriteBufferAppend((unsigned char*)buf,sdslen(buf));
}
写入文件
在 serverCron 事件循环结束前，会调用 flushAppendOnlyFile 将缓冲中的命令写入到 AOF 日志文件中：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
// ...
// AOF延迟刷新：每个 cron 循环都执行执行一次 fsync
if (server.aof_flush_postponed_start) flushAppendOnlyFile(0);
}
void flushAppendOnlyFile(int force) {
ssize_t nwritten;
int sync_in_progress = 0;
if (sdslen(server.aof_buf) == 0) { // 缓冲为空直接返回
// ...
return;
}
// 将命令写入 AOF 文件，此时尚未落盘
nwritten = aofWrite(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));
server.aof_flush_postponed_start = 0; // 写入完成，重置延迟刷新时间戳，避免再次触发
// ...
if (server.aof_fsync == AOF_FSYNC_ALWAYS) {
// 落盘策略为 always，则立即执行 fsync
redis_fsync(server.aof_fd);
server.aof_fsync_offset = server.aof_current_size;
server.aof_last_fsync = server.unixtime;
} else if ((server.aof_fsync == AOF_FSYNC_EVERYSEC &&
server.unixtime > server.aof_last_fsync)) {
// 落盘策略为 everysec，则 fsync 交由后台进程异步完成
if (!sync_in_progress) {
aof_background_fsync(server.aof_fd);
server.aof_fsync_offset = server.aof_current_size;
}
server.aof_last_fsync = server.unixtime;
}
}
值得注意的是，如果写入 AOF 文件过程中发生错误，且落盘策略为 always，此时 Redis 进程会直接退出。
日志重写
在不断接收写命令的过程中，AOF 文件会越来越大，这将导致以下问题：
- 文件系统对文件大小有限制，无法保存过大的文件
- 故障恢复时，需要逐个执行 AOF 日志的命令，如果日志文件太大，将导致整个过程会非常缓慢
导致该问题的一个重要原因就是存在冗余命令：
# 执行命令
127.0.0.1:6379> INCR counter
(integer) 1
127.0.0.1:6379> INCR counter
(integer) 2
127.0.0.1:6379> INCR counter
(integer) 3
# 对应的 AOF 日志
*2
$6
SELECT
$1
0
*2
$4
INCR
$7
counter
*2
$4
INCR
$7
counter
*2
$4
INCR
$7
counter
Redis 提供了重写机制rewrite，能够大幅缩减不必要的冗余命令：
# 重写日志，并输出到一个新的文件中
127.0.0.1:6379> BGREWRITEAOF
# 重写后的 AOF 日志将 3 个 INCR 命令转化为 1 个 SET 命令
*2
$6
SELECT
$1
0
*3
$3
SET
$7
counter
$1
3
除了手动执行 BGREWRITEAOF 命令之外，Redis 也支持自动触发 AOF 重写。下列配置项可用于控制这一行为：
# 重写策略
no-appendfsync-on-rewrite no # 重写 AOF 日志时禁止落盘
auto-aof-rewrite-percentage 100 # 当增长百分比超过该值时，触发 AOF 重写
auto-aof-rewrite-min-size 64mb # 当日志文件体积超过该值后，触发 AOF 重写
struct redisServer {
// ...
int aof_no_fsync_on_rewrite; /* 重写 AOF 过程中禁止调用 fsync 落盘 */
int aof_rewrite_perc; /* 触发 AOF 重写的文件增长百分比 */
off_t aof_rewrite_min_size; /* 触发 AOF 重写的最小文件体积 */
int aof_rewrite_scheduled; /* 是否有重写操作在等待 BGSAVE 完成 */
list *aof_rewrite_buf_blocks; /* AOF 重写缓冲 */
}
Redis 的定时任务 serverCron 会周期性地检查是否满足重写条件：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
/*
延迟重写：在服务器执行 BGSAVE 命令期间，如果接收到 BGWRITEAOF 命令，会将其延迟到 BGSAVE 完成后再执行，避免相互争抢磁盘资源 I/O
*/
if (!hasActiveChildProcess() && // 无执行后台操作的子进程，意味着 BGSAVE 已经完成
server.aof_rewrite_scheduled) // 存在等待执行的 BGWRITEAOF 命令
{
rewriteAppendOnlyFileBackground();
}
// ...
if (server.aof_state == AOF_ON &&
server.aof_rewrite_perc &&
server.aof_current_size > server.aof_rewrite_min_size) // 检查日志体积是否达标
{
// 检查日志增量是否达标
long long base = server.aof_rewrite_base_size ?
server.aof_rewrite_base_size : 1;
long long growth = (server.aof_current_size*100/base) - 100;
if (growth >= server.aof_rewrite_perc) {
// 如果当前状态满足重写条件，打印日志并开始执行 BGREWRITEAOF
serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);
rewriteAppendOnlyFileBackground();
}
}
}
int rewriteAppendOnlyFileBackground(void) {
// ...
if ((childpid = redisFork(CHILD_TYPE_AOF)) == 0) {
/* 子进程负责重写 AOF 日志 */
char tmpfile[256];
if (rewriteAppendOnlyFile(tmpfile) == C_OK) {
// ...
}
} else {
/* 主进程不阻塞直接返回 */
serverLog(LL_NOTICE,
"Background append only file rewriting started by pid %d",childpid);
updateDictResizePolicy();
return C_OK;
}
}
重写过程中，主线程仍然正常对外服务，数据库状态仍然会进行变更，但子进程重写后的 AOF 不会包含这些变更。
因此，这些新增的命令会被同时追加到 AOF 缓冲 server.aof_buf 与 重写缓冲 server.aof_rewrite_buf_blocks 中。当子进程重写完成后，将 重写缓冲 追加至重写完成的 AOF 日志中即可。
此外，为了避免与子进程的重写过程争抢磁盘I/O，可以通过 aof_no_fsync_on_rewrite 禁止主进程在重写期间调用 fsync 落盘 AOF 日志。
两者比较
RDB 快照
优点：文件结构紧凑，节省空间，易于传输，能够快速恢复
缺点：生成快照的开销只与数据库大小相关，当数据库较大时，生成快照耗时，无法频繁进行该操作
AOF 日志
优点：细粒度记录对磁盘I/O压力小，允许频繁落盘，数据丢失的概率极低
缺点：恢复速度慢；记录日志开销与更新频率有关，频繁更新会导致磁盘 I/O 压力上升