Redis源码剖析之RDB

Redis源码剖析之RDB我们小学三年级的时候就知道,redis是一个纯内存存储的中间件,那它宕机会怎么样?数据会丢失吗?答案是可以不丢。 事实上redis为了保证宕机时

大家好,欢迎来到IT知识分享网。

我们小学三年级的时候就知道,redis是一个纯内存存储的中间件,那它宕机会怎么样?数据会丢失吗?答案是可以不丢。 事实上redis为了保证宕机时数据不丢失,提供了两种数据持久化的机制——rdb和aof。

rdb就定期将内存里的数据全量dump到磁盘里,下次启动时就可以直接加载之前的数据了,rdb的问题是它只能提供某个时刻的数据快照,无法保证建立快照后的数据不丢,所以redis还提供了aof。aof全程是Append Only File,它的原理就是把所有改动一条条写到磁盘上。这篇博客我们来重点介绍下rdb持久性的实现,aof留到下一篇博客。

rdb相关源码

在redis中,触发rdb保存主要有以下几种方式。

save命令

我们在redis-cli下直接调用save命令就会触发rdb文件的生成,如果后台没有在子进程在生成rdb,就会调用rdbSave()生成rdb文件,并将其保存在磁盘中。

void saveCommand(client *c) { // 检查是否后台已经有进程在执行save,如果有就停止执行。 if (server.child_type == CHILD_TYPE_RDB) { addReplyError(c,"Background save already in progress"); return; } rdbSaveInfo rsi, *rsiptr; rsiptr = rdbPopulateSaveInfo(&rsi); if (rdbSave(server.rdb_filename,rsiptr) == C_OK) { addReply(c,shared.ok); } else { addReplyErrorObject(c,shared.err); } }

Redis 的 rdbSave 函数是真正进行 RDB 持久化的函数,它的大致流程如下:

  1. 首先创建一个临时文件。
  2. 创建并初始化rio,rio是redis对io的一种抽象,提供了read、write、flush、checksum……等方法。
  3. 调用 rdbSaveRio(),将当前 Redis 的内存信息全量写入到临时文件中。
  4. 调用 fflush、 fsync 和 fclose 接口将文件写入磁盘中。
  5. 使用 rename 将临时文件改名为 正式的 RDB 文件。
  6. 将server.dirty清零,server.dirty是用了记录在上次生成rdb后有多少次数据变更,会在serverCron中用到。

具体代码如下:

/* rdb磁盘写入操作 */ int rdbSave(char *filename, rdbSaveInfo *rsi) { char tmpfile[256]; char cwd[MAXPATHLEN]; /* Current working dir path for error messages. */ FILE *fp = NULL; rio rdb; int error = 0; snprintf(tmpfile,256,"temp-%d.rdb", (int) getpid()); fp = fopen(tmpfile,"w"); if (!fp) { char *cwdp = getcwd(cwd,MAXPATHLEN); serverLog(LL_WARNING, "Failed opening the RDB file %s (in server root dir %s) " "for saving: %s", filename, cwdp ? cwdp : "unknown", strerror(errno)); return C_ERR; } rioInitWithFile(&rdb,fp); // 初始化rio, startSaving(RDBFLAGS_NONE); if (server.rdb_save_incremental_fsync) rioSetAutoSync(&rdb,REDIS_AUTOSYNC_BYTES); // 内存数据dump到rdb if (rdbSaveRio(&rdb,&error,RDBFLAGS_NONE,rsi) == C_ERR) { errno = error; goto werr; } /* 把数据刷到磁盘删,确保操作系统缓冲区没有剩余数据 */ if (fflush(fp)) goto werr; if (fsync(fileno(fp))) goto werr; if (fclose(fp)) { fp = NULL; goto werr; } fp = NULL; /* 把临时文件重命名为正式文件名 */ if (rename(tmpfile,filename) == -1) { char *cwdp = getcwd(cwd,MAXPATHLEN); serverLog(LL_WARNING, "Error moving temp DB file %s on the final " "destination %s (in server root dir %s): %s", tmpfile, filename, cwdp ? cwdp : "unknown", strerror(errno)); unlink(tmpfile); stopSaving(0); return C_ERR; } serverLog(LL_NOTICE,"DB saved on disk"); server.dirty = 0; server.lastsave = time(NULL); server.lastbgsave_status = C_OK; stopSaving(1); return C_OK; werr: serverLog(LL_WARNING,"Write error saving DB on disk: %s", strerror(errno)); if (fp) fclose(fp); unlink(tmpfile); stopSaving(0); return C_ERR; }

因为redis是单线程模型,所以在save的过程中处理不了请求,单线程模型可以save的过程中不会有数据变化,但save可能会持续很久,这会导致redis无法正常处理读写请求,对于线上服务来说这是非常致命的,所以redis还提供了bgsave命令,它可以在不影响正常读写的情况下执行save操作,我们来看下具体实现。

bgsave命令

bgsave提供了后台生成rdb文件的功能,bg含义就是background,具体怎么实现的? 其实就是调用fork() 生成了一个子进程,然后在子进程中完成了save的过程。

void bgsaveCommand(client *c) { int schedule = 0; /* The SCHEDULE option changes the behavior of BGSAVE when an AOF rewrite * is in progress. Instead of returning an error a BGSAVE gets scheduled. */ if (c->argc > 1) { if (c->argc == 2 && !strcasecmp(c->argv[1]->ptr,"schedule")) { schedule = 1; } else { addReplyErrorObject(c,shared.syntaxerr); return; } } rdbSaveInfo rsi, *rsiptr; rsiptr = rdbPopulateSaveInfo(&rsi); if (server.child_type == CHILD_TYPE_RDB) { addReplyError(c,"Background save already in progress"); } else if (hasActiveChildProcess()) { if (schedule) { server.rdb_bgsave_scheduled = 1; // 如果bgsave已经在执行中了,这次执行会放到serverCron中执行 addReplyStatus(c,"Background saving scheduled"); } else { addReplyError(c, "Another child process is active (AOF?): can't BGSAVE right now. " "Use BGSAVE SCHEDULE in order to schedule a BGSAVE whenever " "possible."); } } else if (rdbSaveBackground(server.rdb_filename,rsiptr) == C_OK) { addReplyStatus(c,"Background saving started"); } else { addReplyErrorObject(c,shared.err); } } int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) { pid_t childpid; if (hasActiveChildProcess()) return C_ERR; server.dirty_before_bgsave = server.dirty; server.lastbgsave_try = time(NULL); // 创建子进程,redisFork实际就是对fork的封装 if ((childpid = redisFork(CHILD_TYPE_RDB)) == 0) { int retval; /* 子进程 */ redisSetProcTitle("redis-rdb-bgsave"); redisSetCpuAffinity(server.bgsave_cpulist); retval = rdbSave(filename,rsi); if (retval == C_OK) { sendChildCowInfo(CHILD_INFO_TYPE_RDB_COW_SIZE, "RDB"); } exitFromChild((retval == C_OK) ? 0 : 1); } else { /* 父进程 */ if (childpid == -1) { server.lastbgsave_status = C_ERR; serverLog(LL_WARNING,"Can't save in background: fork: %s", strerror(errno)); return C_ERR; } serverLog(LL_NOTICE,"Background saving started by pid %ld",(long) childpid); server.rdb_save_time_start = time(NULL); server.rdb_child_type = RDB_CHILD_TYPE_DISK; return C_OK; } return C_OK; /* unreached */ }

bgsave其实就是把save的流程放到子进程里执行,这样就不会阻塞到父进程了。我最开始看到这里的时候有个问题,父进程在持续读写内存的情况下子进程是如何保存某一时刻快照的? 这个redid中没有特殊处理,还是依赖了操作系统提供的fork()。 当一个进程调用fork()时,操作系统会复制一份当前的进程,包括当前进程中的内存内容。所以可以认为只要fork()成功,当前内存中的数据就被全量复制了一份。当然具体实现上内核为了提升fork()的性能,使用了copy-on-write的技术,只有被复制的数据在被父进程或者子进程改动时才会真正拷贝。

serverCron

上面生成rdb的两种方式都是被动触发的,redis也提供定期生成rdb的机制。redis关于rdb生成的配置如下:

save <seconds> <changes> ## 例如 save 3600 1 # 3600秒内如果有1条写书就生成rdb save 300 100 # 300秒内如果有100条写书就生成rdb save 60 10000 # 60秒内如果有1000条写书就生成rdb

定期生成rdb的实现在server.c 中的serverCron中。serverCron是redis每次执行完一次eventloop执行的定期调度任务,里面就有rdb和aof的执行逻辑,rdb相关具体如下:

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) { /* . 略去其他代码 */ /* 检测bgsave和aof重写是否在执行过程中 */ if (hasActiveChildProcess() || ldbPendingChildren()) { run_with_period(1000) receiveChildInfo(); checkChildrenDone(); } else { /* If there is not a background saving/rewrite in progress check if * we have to save/rewrite now. */ for (j = 0; j < server.saveparamslen; j++) { struct saveparam *sp = server.saveparams+j; /* 检查是否达到了执行save的标准 */ if (server.dirty >= sp->changes && server.unixtime-server.lastsave > sp->seconds && (server.unixtime-server.lastbgsave_try > CONFIG_BGSAVE_RETRY_DELAY || server.lastbgsave_status == C_OK)) { serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...", sp->changes, (int)sp->seconds); rdbSaveInfo rsi, *rsiptr; rsiptr = rdbPopulateSaveInfo(&rsi); rdbSaveBackground(server.rdb_filename,rsiptr); break; } } } /* . 略去其他代码 */ /* 如果上次触发bgsave时已经有进程在执行了,就会标记rdb_bgsave_scheduled=1,然后放到serverCron * 中执行 */ if (!hasActiveChildProcess() && server.rdb_bgsave_scheduled && (server.unixtime-server.lastbgsave_try > CONFIG_BGSAVE_RETRY_DELAY || server.lastbgsave_status == C_OK)) { rdbSaveInfo rsi, *rsiptr; rsiptr = rdbPopulateSaveInfo(&rsi); if (rdbSaveBackground(server.rdb_filename,rsiptr) == C_OK) server.rdb_bgsave_scheduled = 0; } /* . 略去其他代码 */ }

rdb文件格式

rdb的具体文件格式相对比较简单,具体如下:

----------------------------# 52 45 44 49 53 # 魔术 "REDIS" 30 30 30 33 # ASCII码rdb的版本号 "0003" = 3 ---------------------------- FA # 辅助字段 $string-encoded-key # 可能包含多个元信息 $string-encoded-value # 比如redis版本号,创建时间,内存使用量……... ---------------------------- FE 00 # redis db号. db number = 00 FB # 标识db的大小 $length-encoded-int # hash表的大小(int) $length-encoded-int # expire hash表的大小(int) ----------------------------# 从这里开始就是具体的k-v数据 FD $unsigned-int # 数据还有多少秒过期(4byte unsigned int) $value-type # 标识value数据类型(1 byte) $string-encoded-key # key,redis字符串类型(sds) $encoded-value # value, 类型取决于 $value-type ---------------------------- FC $unsigned long # 数据还有多少毫秒过期(8byte unsigned long) $value-type # 标识value数据类型(1 byte) $string-encoded-key # key,redis字符串类型(sds) $encoded-value # value, 类型取决于 $value-type ---------------------------- $value-type # redis数据key-value,没有过期时间 $string-encoded-key $encoded-value ---------------------------- FE $length-encoding # FE标识前一个db的数据结束,然后再加上数据的长度 ---------------------------- ... # 其他redis db中的k-v数据, ... FF # FF rdb文件的结束标识 8-byte-checksum ## 最后是8byte的CRC64校验和 

总结

rdb在一定程度上保证了redis实例在异常宕机时数据不丢,当因为是定期生成的rdb快照,在生成快照后产生的变动无法追加到rdb文件中,所以rdb无法彻底保证数据不丢,为此redis又提供了另外一种数据持久化机制aof,我们将在下篇文章中看到。另外,在执行bgsave的时候高度依赖于操作系统的fork()机制,这也是会带来很大的性能开销的,详见Linux fork隐藏的开销-过时的fork(正传)

参考资料

  1. Redis RDB 持久化详解
  2. https://rdb.fnordig.de/file_format.html
  3. Redis Persistence
  4. Linux fork隐藏的开销-过时的fork(正传)

本文是Redis源码剖析系列博文,同时也有与之对应的Redis中文注释版,有想深入学习Redis的同学,欢迎star和关注。 Redis中文注解版仓库:https://github.com/xindoo/Redis
Redis源码剖析专栏:https://zxs.io/s/1h
如果觉得本文对你有用,欢迎一键三连

本文来自https://blog.csdn.net/xindoo

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/50836.html

(0)
上一篇 2024-08-12 20:00
下一篇 2024-08-26 20:15

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

关注微信