Redis做數(shù)據(jù)持久化的解決方案及底層原理

之前的文章介紹了Redis的簡單數(shù)據(jù)結(jié)構(gòu)的相關(guān)使用和底層原理，這篇文章我們就來聊一下Redis應(yīng)該如何保證高可用。

數(shù)據(jù)持久化

我們知道雖然單機(jī)的Redis雖然性能十分的出色， 單機(jī)能夠扛住10w的QPS，這是得益于其基于內(nèi)存的快速讀寫操作，那如果某個(gè)時(shí)間Redis突然掛了怎么辦？我們需要一種持久化的機(jī)制，來保存內(nèi)存中的數(shù)據(jù)，否則數(shù)據(jù)就會(huì)直接丟失。

Redis有兩種方式來實(shí)現(xiàn)數(shù)據(jù)的持久化，分別是RDB（Redis Database）和AOF（Append Only File)，你可以先簡單的把RDB理解為某個(gè)時(shí)刻的Redis內(nèi)存中的數(shù)據(jù)快照，而AOF則是所有記錄了所有修改內(nèi)存數(shù)據(jù)的指令的集合（也就是Redis指令的集合），而這兩種方式都會(huì)生成相應(yīng)的文件落地到磁盤上，實(shí)現(xiàn)數(shù)據(jù)的持久化，方便下次恢復(fù)使用。

接下來就分別來聊聊這兩種持久化方案。

RDB

在redis中生成RDB快照的方式有兩種，一種是使用save，另一種是bgsave，但是底層實(shí)現(xiàn)上，其調(diào)用的是同一個(gè)函數(shù)，叫rdbsave，只是其調(diào)用的方式不同而已。

生成方法

save

save命令直接調(diào)用rdbsave方法，此時(shí)會(huì)阻塞Redis主進(jìn)程，直至快照文件生成。

void saveCommand(client *c) {
    if (server.rdb_child_pid != -1) {
        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 {
        addReply(c,shared.err);
    }
}

bgsave

bgsave命令會(huì)fork出一個(gè)子進(jìn)程，由fork出來的子進(jìn)程調(diào)用rdbsave。父進(jìn)程會(huì)繼續(xù)響應(yīng)來自客戶端的讀寫請求。子進(jìn)程完成RDB文件生成之后會(huì)給父進(jìn)程發(fā)送信號(hào)，通知父進(jìn)程保存完成。

/* BGSAVE [SCHEDULE] */
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 {
            addReply(c,shared.syntaxerr);
            return;
        }
    }

    rdbSaveInfo rsi, *rsiptr;
    rsiptr = rdbPopulateSaveInfo(rsi);

    if (server.rdb_child_pid != -1) {
        addReplyError(c,"Background save already in progress");
    } else if (hasActiveChildProcess()) {
        if (schedule) {
            server.rdb_bgsave_scheduled = 1;
            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 {
        addReply(c,shared.err);
    }
}

這也就是為什么Redis是單線程的，但卻能夠在生成RDB文件的同時(shí)對(duì)外提供服務(wù)。fork是unix系統(tǒng)上創(chuàng)建進(jìn)程的主要方法，會(huì)把父進(jìn)程的所有數(shù)據(jù)拷貝到子進(jìn)程中，父子進(jìn)程共享內(nèi)存空間。

fork之后，操作系統(tǒng)內(nèi)核會(huì)把父進(jìn)程中的所有內(nèi)存設(shè)置為只讀，只有當(dāng)發(fā)生寫數(shù)據(jù)時(shí)，會(huì)發(fā)生頁異常中斷，內(nèi)核會(huì)把對(duì)應(yīng)的內(nèi)存頁拷貝一份，父子進(jìn)程各持有一份，所以在生成RDB過程中，由于使用了COW，內(nèi)存臟頁會(huì)逐漸和子進(jìn)程分開。

那么有沒有可能在調(diào)用bgsave的過程中，我再調(diào)用save命令呢，這個(gè)時(shí)候豈不是會(huì)生成兩份RDB文件？

實(shí)際上在調(diào)用save命令時(shí)，Redis會(huì)判斷bgsave是否正在執(zhí)行，如果正在執(zhí)行服務(wù)器就不能再調(diào)用底層的rdbsave函數(shù)了，這樣做可以避免兩個(gè)命令之間出現(xiàn)資源競爭的情況。

例如，在save命令中，有如下的判斷：

if (server.rdb_child_pid != -1) {
  addReplyError(c,"Background save already in progress");
  return;
}

而在bgsave中又有如下的判斷：

if (server.rdb_child_pid != -1) {
  addReplyError(c,"Background save already in progress");
} else if (hasActiveChildProcess()) {
  ...
}

可以看到都是對(duì)同一個(gè)變量的判斷，如下：

pid_t rdb_child_pid; /* PID of RDB saving child */

換句話說，在調(diào)用save、bgsave命令的時(shí)候，會(huì)提前去判斷bgsave是否仍然在運(yùn)行當(dāng)中，如果在運(yùn)行當(dāng)中，則不會(huì)繼續(xù)執(zhí)行bgsave命令。而save命令本身就是阻塞的，如果此時(shí)有其他的命令過來了都會(huì)被阻塞， 直到save執(zhí)行完畢，才會(huì)去處理。

那我把RDB文件生成了之后怎么使用呢？

Redis在啟動(dòng)服務(wù)器的時(shí)候會(huì)調(diào)用rdbLoad函數(shù)，會(huì)把生成的RDB文件給加載到內(nèi)存中來，在載入的期間，每載入1000個(gè)鍵就會(huì)處理一次已經(jīng)到達(dá)的請求，但是只會(huì)處理publish、subscribe、psubscribe、unsubscribe、punsubscribe這個(gè)五個(gè)命令。其余的請求一律返回錯(cuò)誤，直到載入完成。

你吹的這么好，RDB的優(yōu)缺點(diǎn)分別是啥？

優(yōu)點(diǎn)

RDB策略可以靈活配置周期，取決于你想要什么樣的備份策略。例如：

• 每小時(shí)生成一次最近24小時(shí)的數(shù)據(jù)
• 每天生成最近一周的數(shù)據(jù)
• 每天生成最近一個(gè)月的數(shù)據(jù)

基于這個(gè)策略，可以快速的恢復(fù)之前某個(gè)時(shí)間段的數(shù)據(jù)。

其次，RDB非常的適合做冷備份，你可以把RDB文件存儲(chǔ)后轉(zhuǎn)移到其他的存儲(chǔ)介質(zhì)上。甚至可以做到跨云存儲(chǔ)，例如放到OSS上的同時(shí)，又放到S3上，跨云存儲(chǔ)讓數(shù)據(jù)備份更加的健壯。

而且，基于RDB模式的恢復(fù)速度比AOF更快，因?yàn)锳OF是一條一條的Redis指令，RDB則是數(shù)據(jù)最終的模樣。數(shù)據(jù)量大的話所有AOF指令全部重放要比RDB更慢。

缺點(diǎn)

RDB作為一個(gè)數(shù)據(jù)持久化的方案是可行的，但是如果要通過RDB做到Redis的高可用，RDB就不那么合適了。

因?yàn)槿绻鸕edis此時(shí)還沒有來得及將內(nèi)存中的數(shù)據(jù)生成RDB文件，就先掛了，那么距離上次成功生成RDB文件時(shí)新增的這部分?jǐn)?shù)據(jù)就會(huì)全部丟失，而且無法找回。

而且，如果內(nèi)存的數(shù)據(jù)量很大的話，RDB即使是通過fork子進(jìn)程來做的，但是也需要占用到機(jī)器的CPU資源，也可能會(huì)發(fā)生很多的也異常中斷，也可能造成整個(gè)Redis停止響應(yīng)幾百毫秒。

AOF

上面提到過RDB不能滿足Redis的高可用。因?yàn)樵谀承┣闆r下，會(huì)永久性的丟失一段時(shí)間內(nèi)的數(shù)據(jù)，所以我們來聊聊另一種解決方案AOF。首先我們得有個(gè)概念，那就是RDB是對(duì)當(dāng)前Redis Server中的數(shù)據(jù)快照，而AOF是對(duì)變更指令的記錄（所有的獲取操作不會(huì)記錄，因?yàn)閷?duì)當(dāng)前的Redis數(shù)據(jù)沒有改變）。

但是也正因?yàn)槿绱?，AOF文件要比RDB文件更大。下面聊一下一個(gè)Redis命令請求從客戶端到AOF文件的過程。

AOF記錄過程

首先Redis的客戶端和服務(wù)器之間需要通信，客戶端發(fā)送的不是我們寫入的字符串，而是專門的協(xié)議文本。如果你可以熟悉Thrift或者Protobuf的話應(yīng)該就能理解這個(gè)協(xié)議。

例如執(zhí)行命令 SET KEY VALUE，傳到服務(wù)器就變成了"*3\r\n$3\r\nSET\r\n$3\r\nKEY\r\n$5\r\nVALUE\r\n"。

然后Redis服務(wù)器就會(huì)根據(jù)協(xié)議文本的內(nèi)容，選擇適當(dāng)?shù)膆andler進(jìn)行處理。當(dāng)客戶端將指令發(fā)送到Redis服務(wù)器之后，只要命令成功執(zhí)行，就會(huì)將這個(gè)命令傳播到AOF程序中。

注意，傳播到AOF程序中之后不會(huì)馬上寫入磁盤，因?yàn)轭l繁的IO操作會(huì)帶來巨大的開銷，會(huì)大大降低Redis的性能，協(xié)議文本會(huì)被寫到Redis服務(wù)器中的aof_buf中去，也叫AOF的寫入緩沖區(qū)。

你這全部都寫到緩沖區(qū)去了，啥時(shí)候落地？

每當(dāng)serverCron（先有一個(gè)定時(shí)任務(wù)的概念，下面馬上就會(huì)講serverCron是啥）被執(zhí)行的時(shí)候，flushAppendOnlyFile 這個(gè)函數(shù)就被調(diào)用。

這個(gè)命令會(huì)調(diào)用 write將寫入緩沖區(qū)的數(shù)據(jù)寫入到AOF文件中，但是這個(gè)時(shí)候還是沒有真正的落到磁盤上。這是OS為了提高寫入文件的效率，會(huì)將數(shù)據(jù)暫時(shí)寫入到OS的內(nèi)存的緩沖區(qū)內(nèi)，等到緩沖區(qū)被填滿了或超過了指定的時(shí)間，才會(huì)調(diào)用fsync或者sdatasync真正的將緩沖區(qū)的內(nèi)容寫入到磁盤中。

但是如果在這期間機(jī)器宕了，那么數(shù)據(jù)仍然會(huì)丟失。所以如果想要真正的將AOF文件保存在磁盤上，必須要調(diào)用上面提到的兩個(gè)函數(shù)才行。

ServerCron

作用

現(xiàn)在我們就來具體聊一下serverCron函數(shù)，它主要是用于處理Redis中的常規(guī)任務(wù)。

什么叫常規(guī)任務(wù)？

就比如上面提到的AOF寫入緩沖區(qū)，每次serverCron執(zhí)行的時(shí)候就會(huì)把緩沖區(qū)內(nèi)的AOF寫入文件（當(dāng)然，OS會(huì)寫入自己的buffer中）。其余的就像AOF和RDB的持久化操作，主從同步和集群的相關(guān)操作，清理失效的客戶端、過期鍵等等。

那這個(gè)cron間隔多久執(zhí)行一次？

很多博客是直接給出的結(jié)論，100ms執(zhí)行一次，口說無憑，我們直接擼源碼。下面是serverCron的函數(shù)定義。

/* This is our timer interrupt, called server.hz times per second.
 * .............
 */
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
  ...
  server.hz = server.config_hz;
}

為了避免影響大家的思路，我省略了暫時(shí)對(duì)我們沒用的代碼和注釋?？梢钥吹阶⑨屩杏?code>called server.hz times per second。意思就是serverCron這個(gè)函數(shù)將會(huì)在每一秒中調(diào)用server.hz次，那這個(gè)server.hz又是啥？

server.hz

相信大家都知道HZ（赫茲）這個(gè)單位，它是頻率的國際單位制單位，表示每一條周期性事件發(fā)生的次數(shù)。所以，我們知道這個(gè)配置項(xiàng)是用于控制周期性事件發(fā)生的頻率的。

其賦值的地方在上面的函數(shù)中已經(jīng)給出，可以看到其初始值是來源于redis.conf的配置文件。那讓我們看一下具體的配置。

# Redis calls an internal function to perform many background tasks, like
# closing connections of clients in timeout, purging expired keys that are
# never requested, and so forth.
#
# Not all tasks are performed with the same frequency, but Redis checks for
# tasks to perform according to the specified "hz" value.
#
# By default "hz" is set to 10. Raising the value will use more CPU when
# Redis is idle, but at the same time will make Redis more responsive when
# there are many keys expiring at the same time, and timeouts may be
# handled with more precision.
#
# The range is between 1 and 500, however a value over 100 is usually not
# a good idea. Most users should use the default of 10 and raise this up to
# 100 only in environments where very low latency is required.
hz 10

簡單的提取一下有用的信息，Redis會(huì)在內(nèi)部調(diào)用函數(shù)來執(zhí)行很多后臺(tái)的任務(wù)，而調(diào)用這些函數(shù)的頻率就由這個(gè)hz來決定的，其默認(rèn)值為10。那也就是說，上面提到的 serverCron函數(shù)會(huì)在一秒鐘執(zhí)行10次，這樣平均下來就是每100ms（1000ms/10）調(diào)用一次。

寫入策略

上面說到，如果Redis的AOF已經(jīng)位于OS的緩沖中，如果此時(shí)宕機(jī)，那么AOF的數(shù)據(jù)同樣會(huì)丟失。

你這不行啊，那你這個(gè)持久化有什么意義？怎么樣數(shù)據(jù)才能不丟失？

這得聊一下AOF日志的寫入策略，它有三種策略，分別如下：

• always 每個(gè)命令都會(huì)寫入文件并且同步到磁盤
• everysec 每秒鐘同步一次數(shù)據(jù)到磁盤
• no 不強(qiáng)制寫，等待OS自己去決定什么時(shí)候?qū)?/li>

很明顯always這種策略在真正的生產(chǎn)環(huán)境上是不可取的，每個(gè)命令都去寫文件，會(huì)造成極大的IO開銷，會(huì)占用Redis服務(wù)器的很多資源，降低Redis的服務(wù)效率。

而如果使用everysec策略的話，即使發(fā)生了斷電，機(jī)器宕機(jī)了，我最多也只會(huì)丟失一秒鐘的數(shù)據(jù)。

而no則完全交與操作系統(tǒng)去調(diào)度，可能會(huì)丟失較多的數(shù)據(jù)。

666，那這AOF文件咋用的，怎么恢復(fù)？

上面提到過，AOF文件是記錄了來自客戶端的所有寫命令，所以服務(wù)器只需要讀入并重放一遍即可將Redis的狀態(tài)恢復(fù)。

但是，Redis的命令只能在客戶端中的上下文才能夠執(zhí)行，所以Redis搞了一個(gè)沒有網(wǎng)絡(luò)連接的偽客戶端來執(zhí)行命令，直到命令執(zhí)行完畢。

老鐵，你這不行啊，萬一AOF日志數(shù)據(jù)量很大，你這豈不是要恢復(fù)很長時(shí)間，那服務(wù)豈不是不可用了？

的確，隨著服務(wù)器的運(yùn)行，AOF的數(shù)據(jù)量會(huì)越來越大，重放所需要的時(shí)間也會(huì)越來越多。所以Redis有一個(gè)重寫（AOF Rewrite）機(jī)制，來實(shí)現(xiàn)對(duì)AOF文件的瘦身。

雖然名字叫對(duì)AOF文件的瘦身，但是實(shí)際上要做的操作跟之前已經(jīng)生成的AOF文件沒有一毛錢的關(guān)系。

所謂瘦身是通過讀取Redis服務(wù)器當(dāng)前的數(shù)據(jù)狀態(tài)來實(shí)現(xiàn)的，當(dāng)然，這里的當(dāng)前是在服務(wù)器正常運(yùn)行的時(shí)候。其實(shí)你也可以理解為快照，只不過不是實(shí)打?qū)嵉亩M(jìn)制文件了，而是直接設(shè)置快照值的命令。

用人話舉個(gè)例子，假設(shè)你Redis中有個(gè)鍵叫test，它的值的變化歷史是1 -> 3 -> 5 -> 7 -> 9這樣，那么如果是正常的AOF文件就會(huì)記錄5條Redis指令。而AOF Rewrite此時(shí)介入，就只會(huì)記錄一條test=9這樣的數(shù)據(jù)。

而之前的AOF文件還是照常的寫入，當(dāng)新的AOF文件生成后替換即可。

你tm在逗我？你在rewrite的同時(shí)，服務(wù)器仍然在處理正常的請求，此時(shí)如果對(duì)服務(wù)器的狀態(tài)做了更改，你這個(gè)瘦身之后的AOF文件數(shù)據(jù)不就不一致了？

這種情況的確會(huì)出現(xiàn)，但是Redis通過一個(gè)AOF重寫緩沖區(qū)來解決了這個(gè)問題。

當(dāng)rewrite開始后，Redis會(huì)fork一個(gè)子進(jìn)程，讓子進(jìn)程來實(shí)現(xiàn)AOF的瘦身操作，父進(jìn)程則可以正常處理請求。AOF重寫緩沖區(qū)會(huì)在rewrite開始創(chuàng)建了子進(jìn)程之后開始使用，此時(shí)Redis服務(wù)器會(huì)把寫的指令同時(shí)發(fā)送到兩個(gè)地方：

• aof_buf，也就是上面提到的AOF文件的寫入緩沖區(qū)
• AOF重寫緩沖區(qū)

你可能會(huì)問，為啥要記錄到兩個(gè)地方？上面提到過，Redis執(zhí)行瘦身操作時(shí)，常規(guī)的AOF文件仍然是正常生成的，所以新的Redis指令一定會(huì)發(fā)送到寫入緩沖區(qū)。

而發(fā)送到AOF重寫緩沖區(qū)是為了重放在瘦身操作進(jìn)行當(dāng)中對(duì)Redis狀態(tài)進(jìn)行的更改，這樣瘦身之后的AOF文件狀態(tài)才能保證與Redis的狀態(tài)一致。總的來說，就是為了保證瘦身的AOF文件中的數(shù)據(jù)狀態(tài)與Redis當(dāng)時(shí)的內(nèi)存狀態(tài)保持?jǐn)?shù)據(jù)上的一致性。

End

關(guān)于Redis數(shù)據(jù)持久化的問題，就先聊這么多，下一期的計(jì)劃的應(yīng)該就是聊一聊Redis的高可用的相關(guān)機(jī)制了。

©著作權(quán)歸作者所有：來自51CTO博客作者S.H的原創(chuàng)作品，如需轉(zhuǎn)載，請與作者聯(lián)系，否則將追究法律責(zé)任
https://blog.51cto.com/u_15292354/3073048

到此這篇關(guān)于Redis做數(shù)據(jù)持久化的解決方案及底層原理的文章就介紹到這了,更多相關(guān)Redis數(shù)據(jù)持久化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！