Redis 持久化(Persistence)
作者:互联网
作为内存数据库,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\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
Redis 提供了重写机制rewrite
,能够大幅缩减不必要的冗余命令:
# 重写日志,并输出到一个新的文件中
127.0.0.1:6379> BGREWRITEAOF
# 重写后的 AOF 日志将 3 个 INCR 命令转化为 1 个 SET 命令
*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
*3\r\n$3\r\nSET\r\n$7\r\ncounter\r\n$1\r\n3
除了手动执行 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 压力上升
标签:AOF,持久,aof,int,Redis,server,日志,重写,Persistence 来源: https://www.cnblogs.com/buttercup/p/13974022.html