问大家一个问题，假如Redis宕机，内存中的数据全部丢失，怎么恢复数据？
Redis 分别提供了 RDB 和 AOF 两种持久化机制：
RDB将数据库的快照(snapshot)以二进制的方式保存到磁盘中。
AOF则以协议文本的方式，将所有对数据库进行过写入的命令(及其参数)记录到AOF文件，以此达到记录数据库状态的目的。
(1) AOF日志是什么
AOF(Append Only File)日志是一种写后日志，在Redis先执行命令，把数据写入内存后，然后才记录日志，日志会追加到文件末尾，所以叫AOF日志。
和我们常见的WAL日志不同，WAL(Write Ahead Log)是写前日志，在实际写数据前，先把修改的数据记到日志文件中，再去执行命令，这个就要求数据库需要额外的检查命令是否正确。
(2) 为什么要用AOF
AOF日志的作用主要有2个:
1.用来在redis宕机后恢复数据；
2.可以用来主从数据同步。
(3) AOF原理
(3.1) AOF命令同步原理
Redis将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件， 以此达到记录数据库状态的目的。
redis> RPUSH list 1 2 3 4
(integer) 4
redis> LRANGE list 0 -1
1) "1"
2) "2"
3) "3"
4) "4"
redis> KEYS *
1) "list"
redis> RPOP list
"4"
redis> LPOP list
"1"
redis> LPUSH list 1
(integer) 3
redis> LRANGE list 0 -1
1) "1"
2) "2"
3) "3"那么其中四条对数据库有修改的写入命令就会被同步到 AOF 文件中：
RPUSH list 1 2 3 4
RPOP list
LPOP list
LPUSH list 1(3.2) Reids AOF数据存储方式
为了处理的方便， AOF文件使用网络通讯协议的格式来保存这些命令。
*2 # 表示这条命令的消息体共2行
$6 # 下一行的数据长度为6
SELECT # 消息体
$1 # 下一行数据长度为1
0 # 消息体
*6 # 表示这条命令的消息体共6行
$5 # 下一行的数据长度为5
RPUSH # 消息体
$4 # 下一行的数据长度为4
list
$1
1
$1
2
$1
3
$1
4
*2
$4
RPOP
$4
list
*2
$4
LPOP
$4
list
*3
$5
LPUSH
$4
list
$1
1除了 SELECT 命令是 AOF 程序自己加上去的之外， 其他命令都是之前我们在终端里执行的命令。
(3.4) 同步命令到AOF文件的过程
同步命令到AOF文件的整个过程可以分为三个阶段：
- 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到AOF程序中。
- 缓存追加：AOF程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的AOF缓存中。
- 文件写入和保存：AOF缓存中的内容被写入到AOF文件末尾，如果设定的AOF保存条件被满足的话，
fsync函数或者fdatasync函数会被调用，将写入的内容真正地保存到磁盘中。
(4) AOF怎么使用
(4.1) 保存模式
Redis 目前支持三种 AOF 保存模式，它们分别是：
- AOF_FSYNC_NO：不保存。
- AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
- AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。
(4.1) AOF 保存模式对性能和安全性的影响
对于三种 AOF 保存模式， 它们对服务器主进程的阻塞情况如下：
不保存（AOF_FSYNC_NO）：写入和保存都由主进程执行，两个操作都会阻塞主进程。
每一秒钟保存一次（AOF_FSYNC_EVERYSEC）：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。
每执行一个命令保存一次（AOF_FSYNC_ALWAYS）：和模式 1 一样。
(5) AOF重写
AOF 文件通过同步 Redis 服务器所执行的命令， 从而实现了数据库状态的记录， 但是， 这种同步方式会造成一个问题： 随着运行时间的流逝， AOF 文件会变得越来越大。
举个例子， 如果服务器执行了以下命令，那么光是记录 list 键的状态， AOF 文件就需要保存四条命令。
RPUSH list 1 2 3 4 // [1, 2, 3, 4]
RPOP list // [1, 2, 3]
LPOP list // [2, 3]
LPUSH list 1 // [1, 2, 3]“重写”其实是一个有歧义的词语， 实际上， AOF 重写并不需要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。
上面的例子，列表键 list 在数据库中的值就为 [1, 2, 3] 。
如果要保存这个列表的当前状态， 并且尽量减少所使用的命令数， 那么最简单的方式不是去 AOF 文件上分析前面执行的四条命令， 而是直接读取 list 键在数据库的当前值， 然后用一条 RPUSH 1 2 3 命令来代替前面的四条命令。
列表、集合、字符串、有序集、哈希表等键可以用类似的方法来保存状态， 并且保存这些状态所使用的命令数量， 比起之前建立这些键的状态所使用命令的数量要大大减少。
(5.1) AOF后台重写
避免竞争aof文件
当子进程在执行AOF重写时， 主进程需要执行以下三个工作：
处理命令请求。
将写命令追加到现有的 AOF 文件中。
将写命令追加到 AOF 重写缓存中。
(5.2) AOF重写函数与触发时机
实现AOF重写的函数是 rewriteAppendOnlyFileBackground
触发AOF有3种方法：
- 执行
bgrewriteaof命令，对应的函数是bgrewriteaofCommand - 配置开始AOF重写，对应函数是
startAppendOnly - 周期性检查，对应函数是
serverCron里的rewriteAppendOnlyFileBackground
(5.2.1) 手动触发AOF重写-bgrewriteaofCommand
void bgrewriteaofCommand(client *c) {
if (server.aof_child_pid != -1) { // 有AOF重写子进程
// 后台已经有重写进程
addReplyError(c,"Background append only file rewriting already in progress");
} else if (hasActiveChildProcess()) { // 有活跃子进程
//
server.aof_rewrite_scheduled = 1;
//
addReplyStatus(c,"Background append only file rewriting scheduled");
} else if (rewriteAppendOnlyFileBackground() == C_OK) { // 实际执行AOF重写
addReplyStatus(c,"Background append only file rewriting started");
} else {
addReplyError(c,"Can't execute an AOF background rewriting. "
"Please check the server logs for more information.");
}
}(5.2.2) 开始AOF重新-startAppendOnly
/* Called when the user switches from "appendonly no" to "appendonly yes"
* at runtime using the CONFIG command. */
int startAppendOnly(void) {
char cwd[MAXPATHLEN]; /* Current working dir path for error messages. */
int newfd;
newfd = open(server.aof_filename,O_WRONLY|O_APPEND|O_CREAT,0644);
serverAssert(server.aof_state == AOF_OFF);
if (newfd == -1) {
char *cwdp = getcwd(cwd,MAXPATHLEN);
serverLog(LL_WARNING,
"Redis needs to enable the AOF but can't open the "
"append only file %s (in server root dir %s): %s",
server.aof_filename,
cwdp ? cwdp : "unknown",
strerror(errno));
return C_ERR;
}
if (hasActiveChildProcess() && server.aof_child_pid == -1) {
server.aof_rewrite_scheduled = 1;
serverLog(LL_WARNING,"AOF was enabled but there is already another background operation. An AOF background was scheduled to start when possible.");
} else {
/* If there is a pending AOF rewrite, we need to switch it off and
* start a new one: the old one cannot be reused because it is not
* accumulating the AOF buffer. */
if (server.aof_child_pid != -1) {
serverLog(LL_WARNING,"AOF was enabled but there is already an AOF rewriting in background. Stopping background AOF and starting a rewrite now.");
killAppendOnlyChild();
}
if (rewriteAppendOnlyFileBackground() == C_ERR) {
close(newfd);
serverLog(LL_WARNING,"Redis needs to enable the AOF but can't trigger a background AOF rewrite operation. Check the above logs for more info about the error.");
return C_ERR;
}
}
/* We correctly switched on AOF, now wait for the rewrite to be complete
* in order to append data on disk. */
server.aof_state = AOF_WAIT_REWRITE;
server.aof_last_fsync = server.unixtime;
server.aof_fd = newfd;
return C_OK;
}(5.2.3) 周期性执行-serverCron
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
// 省略部分代码
/* Start a scheduled AOF rewrite if this was requested by the user while
* a BGSAVE was in progress. */
if (!hasActiveChildProcess() &&
server.aof_rewrite_scheduled)
{
rewriteAppendOnlyFileBackground();
}
}(5.3) AOF重写的基本过程
/* ----------------------------------------------------------------------------
* AOF background rewrite
* ------------------------------------------------------------------------- */
/* This is how rewriting of the append only file in background works:
*
* 1) The user calls BGREWRITEAOF
* 2) Redis calls this function, that forks():
* 2a) the child rewrite the append only file in a temp file.
* 2b) the parent accumulates differences in server.aof_rewrite_buf.
* 3) When the child finished '2a' exists.
* 4) The parent will trap the exit code, if it's OK, will append the
* data accumulated into server.aof_rewrite_buf into the temp file, and
* finally will rename(2) the temp file in the actual file name.
* The the new file is reopened as the new append only file. Profit!
*/
int rewriteAppendOnlyFileBackground(void) {
pid_t childpid;
if (hasActiveChildProcess()) return C_ERR;
if (aofCreatePipes() != C_OK) return C_ERR;
openChildInfoPipe();
if ((childpid = redisFork(CHILD_TYPE_AOF)) == 0) {
char tmpfile[256];
/* Child */
redisSetProcTitle("redis-aof-rewrite");
redisSetCpuAffinity(server.aof_rewrite_cpulist);
snprintf(tmpfile,256,"temp-rewriteaof-bg-%d.aof", (int) getpid());
if (rewriteAppendOnlyFile(tmpfile) == C_OK) {
sendChildCOWInfo(CHILD_TYPE_AOF, "AOF rewrite");
exitFromChild(0);
} else {
exitFromChild(1);
}
} else {
/* Parent */
if (childpid == -1) {
closeChildInfoPipe();
serverLog(LL_WARNING,
"Can't rewrite append only file in background: fork: %s",
strerror(errno));
aofClosePipes();
return C_ERR;
}
serverLog(LL_NOTICE,
"Background append only file rewriting started by pid %d",childpid);
server.aof_rewrite_scheduled = 0;
server.aof_rewrite_time_start = time(NULL);
server.aof_child_pid = childpid;
updateDictResizePolicy();
/* We set appendseldb to -1 in order to force the next call to the
* feedAppendOnlyFile() to issue a SELECT command, so the differences
* accumulated by the parent into server.aof_rewrite_buf will start
* with a SELECT statement and it will be safe to merge. */
server.aof_selected_db = -1;
replicationScriptCacheFlush();
return C_OK;
}
return C_OK; /* unreached */
}参考资料
https://weikeqin.com/tags/redis/
Redis源码剖析与实战 学习笔记 Day19 19 AOF重写（上）：触发时机与重写的影响
https://time.geekbang.org/col...