文章系转载，便于整理和归纳，源文地址：https://developer.aliyun.com/article/193034
简介： redis有两种持久化的方式——RDB和AOF，RDB是一份内存快照，AOF则为可回放的命令日志，他们两个各有特点也相互独立。4.0开始允许使用RDB-AOF混合持久化的方式，结合了两者的优点，通过aof-use-rdb-preamble配置项可以打开混合开关，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。
RDB V.S. AOF
1. RDB
RDB文件本质上是一份内存快照，保存了创建RDB文件那个时间点的redis全量数据。具有数据文件小创建、恢复快的优点，但是由于快照的特性无法保存创建RDB之后的增量数据。
2. AOF
AOF文件本质上是一份执行日志保存所有对redis进行更改的命令，增量数据也就随命令写入AOF文件刷盘的策略，由配置项appendfsync控制可以选择"everysec"或"always"。
AOF文件基本上是human-readable的文本，所以其体积相对较大，在从AOF文件恢复数据时就是做日志回放执行AOF文件中记录的所有命令，所以相对RDB而言恢复耗时较长。
随着redis的运行AOF文件会不断膨胀，由aofrewrite机制来防止磁盘空间被撑满详见上一篇文章《redis4.0之利用管道优化aofrewrite》。
RDB-AOF混合持久化
细细想来，aofrewrite时也是先写一份全量数据到新AOF文件中再追加增量，只不过全量数据是以redis命令的格式写入。那么是否可以先以RDB格式写入全量数据，再追加增量日志呢？这样既可以提高aofrewrite和恢复速度，也可以减少文件大小，还可以保证数据的完毕性，整合RDB和AOF的优点。那么现在4.0实现了这一特性——RDB-AOF混合持久化。
aofrewrite
综上所述RDB-AOF混合持久化体现在aofrewrite时，那么我们就从这里开始来看4.0是如何实现的。
-
回忆下aofrewrite的过程
无论是serverCron触发或者执行BGREWRITEAOF命令，最终redis都会走到rewriteAppendOnlyFileBackground()，
rewriteAppendOnlyFileBackground函数会fork子进程子进程进入rewriteAppendOnlyFile函数来生成新的AOF文件混合持久化就从这里开始。
int rewriteAppendOnlyFile(char *filename) { ... if (server.aof_use_rdb_preamble) { int error; if (rdbSaveRio(&aof,&error,RDB_SAVE_AOF_PREAMBLE,NULL) == C_ERR) { errno = error; goto werr; } } else { if (rewriteAppendOnlyFileRio(&aof) == C_ERR) goto werr; } ... } -
可以看到当混合持久化开关打开时，就会进入rdbSaveRio函数先以RDB格式来保存全量数据。 前文说道子进程在做aofrewrite时，会通过管道从父进程读取增量数据并缓存下来，那么在以RDB格式保存全量数据时也会从管道读取数据，并不会造成管道阻塞。
int rdbSaveRio(rio *rdb, int *error, int flags, rdbSaveInfo *rsi) { ... snprintf(magic,sizeof(magic),"REDIS%04d",RDB_VERSION); if (rdbWriteRaw(rdb,magic,9) == -1) goto werr; if (rdbSaveInfoAuxFields(rdb,flags,rsi) == -1) goto werr; -
首先把RDB的版本（注意不是redis的版本）和辅助域写入文件
for (j = 0; j < server.dbnum; j++) { redisDb *db = server.db+j; dict *d = db->dict; if (dictSize(d) == 0) continue; di = dictGetSafeIterator(d); if (!di) return C_ERR; /* Write the SELECT DB opcode */ if (rdbSaveType(rdb,RDB_OPCODE_SELECTDB) == -1) goto werr; if (rdbSaveLen(rdb,j) == -1) goto werr; /* Write the RESIZE DB opcode. We trim the size to UINT32_MAX, which * is currently the largest type we are able to represent in RDB sizes. * However this does not limit the actual size of the DB to load since * these sizes are just hints to resize the hash tables. */ uint32_t db_size, expires_size; db_size = (dictSize(db->dict) <= UINT32_MAX) ? dictSize(db->dict) : UINT32_MAX; expires_size = (dictSize(db->expires) <= UINT32_MAX) ? dictSize(db->expires) : UINT32_MAX; if (rdbSaveType(rdb,RDB_OPCODE_RESIZEDB) == -1) goto werr; if (rdbSaveLen(rdb,db_size) == -1) goto werr; if (rdbSaveLen(rdb,expires_size) == -1) goto werr; -
然后遍历DB先把dbnum和db_size、expires_size写入文件
/* Iterate this DB writing every entry */ while((de = dictNext(di)) != NULL) { sds keystr = dictGetKey(de); robj key, *o = dictGetVal(de); long long expire; initStaticStringObject(key,keystr); expire = getExpire(db,&key); if (rdbSaveKeyValuePair(rdb,&key,o,expire,now) == -1) goto werr; /* When this RDB is produced as part of an AOF rewrite, move * accumulated diff from parent to child while rewriting in * order to have a smaller final write. */ if (flags & RDB_SAVE_AOF_PREAMBLE && rdb->processed_bytes > processed+AOF_READ_DIFF_INTERVAL_BYTES) { processed = rdb->processed_bytes; aofReadDiffFromParent(); } } dictReleaseIterator(di); } di = NULL; /* So that we don't release it again on error. */ -
在当前DB中遍历所有的key把key-value对及过期时间（如果有设置的话写入文件）。这里小插曲一下在rdbSaveKeyValuePair函数中会判断expire是否已经到了过期时间如果已经过期就不会写入文件，同时如果flags标记了RDB_SAVE_AOF_PREAMBLE的话，说明是在aofrewrite且开启了RDB-AOF混合开关，此时就会从父进程去读取增量数据了。
/* EOF opcode */ if (rdbSaveType(rdb,RDB_OPCODE_EOF) == -1) goto werr; /* CRC64 checksum. It will be zero if checksum computation is disabled, the * loading code skips the check in this case. */ cksum = rdb->cksum; memrev64ifbe(&cksum); if (rioWrite(rdb,&cksum,8) == 0) goto werr; return C_OK; } -
最后把代表RDB格式结束的RDB_OPCODE_EOF标记和校验和写入文件。
RDB-AOF混合持久化的RDB部分到此结束rdbSaveRio函数运行完后返回rewriteAppendOnlyFile继续把增量数据写入AOF文件。
也就是说AOF文件的前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。
数据恢复
当appendonly配置项为no时，redis启动后会去加载RDB文件，以RDB格式来解析RDB文件自然没有问题。
而appendonly配置项为yes时，redis启动后会加载AOF文件来恢复数据，如果持久化时开启了RDB-AOF混合开关，那么AOF文件的前半段就是RDB格式，此时要如何正确加载数据呢？
一切数据都逃不过协议二字，不以正确的协议存储和解析那就是乱码，既然允许RDB-AOF混合持久化就要能够识别并恢复数据。这一节我们来介绍如何以正确的姿势来恢复数据。
加载AOF文件的入口为loadAppendOnlyFile。
int loadAppendOnlyFile(char *filename) {
...
/* Check if this AOF file has an RDB preamble. In that case we need to
* load the RDB file and later continue loading the AOF tail. */
char sig[5]; /* "REDIS" */
if (fread(sig,1,5,fp) != 5 || memcmp(sig,"REDIS",5) != 0) {
/* No RDB preamble, seek back at 0 offset. */
if (fseek(fp,0,SEEK_SET) == -1) goto readerr;
} else {
/* RDB preamble. Pass loading the RDB functions. */
rio rdb;
serverLog(LL_NOTICE,"Reading RDB preamble from AOF file...");
if (fseek(fp,0,SEEK_SET) == -1) goto readerr;
rioInitWithFile(&rdb,fp);
if (rdbLoadRio(&rdb,NULL) != C_OK) {
serverLog(LL_WARNING,"Error reading the RDB preamble of the AOF file, AOF loading aborted");
goto readerr;
} else {
serverLog(LL_NOTICE,"Reading the remaining AOF tail...");
}
}
...
}
打开AOF文件之后首先读取5个字符，如果是"REDIS"，那么就说明这是一个混合持久化的AOF文件，正确的RDB格式一定是以"REDIS"开头，而纯AOF格式则一定以"*"开头，此时就会进入rdbLoadRio函数来加载数据。
rdbLoadRio函数此处就不详细展开了，就是以约定好的协议解析文件内容，直至遇到RDB_OPCODE_EOF结束标记，返回loadAppendOnlyFile函数继续以AOF格式解析文件直到结束整个加载过程完成。
附录
1. RDB格式的文件
我们先向redis写入一些数据并生成RDB文件
$redis-cli
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> expire foo 60
(integer) 1
127.0.0.1:6379> select 2
OK
127.0.0.1:6379[2]> set foo bar
OK
127.0.0.1:6379[2]> bgsave
Background saving started
看下RDB文件内容
$cat dump.rdb
REDIS0008 redis-ver4.0.1
redis-bits@ctimeYused-mem
aof-preamblerepl-id(484f9d49a700c4b9b136f0fd40d2d6e5a8460438
repl-offa;^foobarfoobar^KJ_U
OMG…一堆乱码隐约可以看到一些和redis相关的字符串为了更直观的感受下RDB的内容我们用redis自带的工具redis-check-rdb来看下
redis-check-rdb dump.rdb
[offset 0] Checking RDB file dump.rdb
[offset 26] AUX FIELD redis-ver = '4.0.1'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1504234774'
[offset 67] AUX FIELD used-mem = '2139016'
[offset 83] AUX FIELD aof-preamble = '0'
[offset 133] AUX FIELD repl-id = '484f9d49a700c4b9b136f0fd40d2d6e5a8460438'
[offset 148] AUX FIELD repl-offset = '0'
[offset 150] Selecting DB ID 0
[offset 173] Selecting DB ID 2
[offset 194] Checksum OK
[offset 194] \o/ RDB looks OK! \o/
[info] 2 keys read
[info] 1 expires
[info] 0 already expired
这下就好看多了,首先可以看到是一些AUX FIELD辅助域，4.0特有用来配合全新的主从同步方式PSYNC2，后面会专门来介绍PSYNC2，然后可以看到DB0和DB2是有内容的，Checksum也OK。最后是说一共有2个key，其中一个设置了过期时间到目前为止还都没有过期。
2. AOF格式的文件
同样的数据我们来看下在AOF文件中是如何保存的
$cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$3
foo
$3
bar
*3
$9
PEXPIREAT
$3
foo
$13
1504255377087
*2
$6
SELECT
$1
2
*3
$3
set
$3
foo
$3
bar
很明显就是一条一条redis命令。
3. RDB-AOF混和持久化的文件
最后来看下RDB-AOF混和持久化的文件。
首先打开混合开关执行BGREWRITEAOF生成RDB-AOF混合文件，再追加写入一些数据
$redis-cli
127.0.0.1:6379> config set aof-use-rdb-preamble yes
OK
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> quit
再来看下此时AOF文件内容
$cat appendonly.aof
REDIS0008 redis-ver4.0.1
redis-bits@ctimeYused-memP
aof-preamblerepl-id(484f9d49a700c4b9b136f0fd40d2d6e5a8460438
repl-offsetfoobar?I Y*2
$6
SELECT
$1
0
*3
$3
set
$3
foo
$3
bar
显而易见前半段是RDB格式的全量数据后半段是redis命令格式的增量数据。
优缺点
RDB
-
优点：
- RDB 是一个非常紧凑（compact）的文件，体积小，因此在传输速度上比较快，因此适合灾难恢复。
- RDB 可以最大化Redis 的性能：父进程在保存RDB 文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O 操作。
- RDB 在恢复大数据集时的速度比AOF 的恢复速度要快。
-
缺点：
RDB是一个快照过程，无法完整的保存所有数据，尤其在数据量比较大时候，一旦出现故障丢失的数据将更多。
当redis中数据集比较大时候，RDB由于RDB方式需要对数据进行完成拷贝并生成快照文件，fork的子进程会耗CPU，并且数据越大，RDB快照生成会越耗时。
RDB文件是特定的格式，阅读性差，由于格式固定，可能存在不兼容情况。
AOF
-
优点：
- 数据更完整，秒级数据丢失(取决于设置fsync策略)。
- 兼容性较高，由于是基于redis通讯协议而形成的命令追加方式，无论何种版本的redis都兼容，再者aof文件是明文的，可阅读性较好。
-
缺点：
- 数据文件体积较大，即使有重写机制，但是在相同的数据集情况下，AOF文件通常比RDB文件大。
- 相对RDB方式，AOF速度慢于RDB，并且在数据量大时候，恢复速度AOF速度也是慢于RDB。
- 由于频繁地将命令同步到文件中，AOF持久化对性能的影响相对RDB较大。
混合持久化
-
优点：
混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，减少数据丢失。
-
缺点：
兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。
3338
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
