redis持久化的示例分析

這篇文章給大家分享的是有關(guān)redis持久化的示例分析的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

為什么需要持久化？

由于Redis是一種內(nèi)存型數(shù)據(jù)庫，即服務(wù)器在運行時，系統(tǒng)為其分配了一部分內(nèi)存存儲數(shù)據(jù)，一旦服務(wù)器掛了，或者突然宕機了，那么數(shù)據(jù)庫里面的數(shù)據(jù)將會丟失，為了使服務(wù)器即使突然關(guān)機也能保存數(shù)據(jù)，必須通過持久化的方式將數(shù)據(jù)從內(nèi)存保存到磁盤中。

對于進行持久化的程序來說，數(shù)據(jù)從程序?qū)懙接嬎銠C的磁盤的流程如下：

1、客戶端發(fā)送一個寫指令給數(shù)據(jù)庫（此時數(shù)據(jù)在客戶端的內(nèi)存）

2、數(shù)據(jù)庫接收到寫的指令以及數(shù)據(jù)（數(shù)據(jù)此時在服務(wù)端的內(nèi)存）

3、數(shù)據(jù)庫發(fā)起一個系統(tǒng)調(diào)用，把數(shù)據(jù)寫到磁盤（此時數(shù)據(jù)在內(nèi)核的內(nèi)存）

4、操作系統(tǒng)把數(shù)據(jù)傳輸?shù)酱疟P控制器（數(shù)據(jù)此時在磁盤緩存中）

5、磁盤控制器執(zhí)行真正寫入數(shù)據(jù)到物理媒介的操作（如磁盤）

如果只是考慮數(shù)據(jù)庫層面，數(shù)據(jù)在第三階段之后就安全了，在這個時候，系統(tǒng)調(diào)用已經(jīng)發(fā)起了，即使數(shù)據(jù)庫進程奔潰了，系統(tǒng)調(diào)用會繼續(xù)進行，也能順利將數(shù)據(jù)寫入到磁盤中。 在這一步之后，在第4步內(nèi)核會將數(shù)據(jù)從內(nèi)核緩存保存到磁盤緩存中，但為了系統(tǒng)的效率問題，默認情況下不會太頻繁地執(zhí)行這個動作，大概會在30s執(zhí)行一次，這就意味著如果這一步失敗了或者就在進行這一步的時候服務(wù)器突然關(guān)機了，那么就可能會有30s的數(shù)據(jù)丟失了，這種比較普通的災(zāi)難性問題也是需要考慮的。

POSIX API也提供了一個系統(tǒng)調(diào)用讓內(nèi)核強制將緩存數(shù)據(jù)寫入到磁盤中，比較常見的就是fsync系統(tǒng)調(diào)用。

int fsync(int fd);

fsync函數(shù)只對由文件描述符fd指定的一個文件起作用，并且等待寫磁盤操作結(jié)束后才返回。每次調(diào)用fsync時，會初始化一個寫操作，然后把緩沖區(qū)的數(shù)據(jù)寫入到磁盤中。fsync()函數(shù)在完成寫操作的時候會阻塞進程，如果其他線程也在寫同一個文件，它也會阻塞其他線程，直到完成寫操作。

持久化

持久化是將程序數(shù)據(jù)在持久狀態(tài)和瞬時狀態(tài)間轉(zhuǎn)換的機制。對于程序來說，程序運行中數(shù)據(jù)是在內(nèi)存的，如果沒有及時同步寫入到磁盤，那么一旦斷電或者程序突然奔潰，數(shù)據(jù)就會丟失了，只有把數(shù)據(jù)及時同步到磁盤，數(shù)據(jù)才能永久保存，不會因為宕機影像數(shù)據(jù)的有效性。而持久化就是將數(shù)據(jù)從程序同步到磁盤的一個動作過程。

Redis的持久化

redis有RDB和AOF兩種持久化方式。RDB是快照文件的方式，redis通過執(zhí)行SAVE/BGSAVE命令，執(zhí)行數(shù)據(jù)的備份，將redis當(dāng)前的數(shù)據(jù)保存到*.rdb文件中，文件保存了所有的數(shù)據(jù)集合。AOF是服務(wù)器通過讀取配置，在指定的時間里，追加redis寫操作的命令到*.aof文件中，是一種增量的持久化方式。

RDB

RDB文件通過SAVE或BGSAVE命令實現(xiàn)。 SAVE命令會阻塞Redis服務(wù)進程，直到RDB文件創(chuàng)建完成為止。 BGSAVE命令通過fork子進程，有子進程來進行創(chuàng)建RDB文件，父進程和子進程共享數(shù)據(jù)段，父進程繼續(xù)提供讀寫服務(wù)，子進程實現(xiàn)備份功能。BGSAVE階段只有在需要修改共享數(shù)據(jù)段的時候才進行拷貝，也就是COW（Copy On Write）。SAVE創(chuàng)建RDB文件可以通過設(shè)置多個保存條件，只要其中一個條件滿足，就可以在后臺執(zhí)行SAVE操作。

SAVE和BGSAVE命令的實現(xiàn)代碼如下：

void saveCommand(client *c) {

// BGSAVE執(zhí)行時不能執(zhí)行SAVE

if (server.rdb_child_pid != -1) {

addReplyError(c,"Background save already in progress");

return;

}

rdbSaveInfo rsi, *rsiptr;

rsiptr = rdbPopulateSaveInfo(&rsi);

// 調(diào)用rdbSave函數(shù)執(zhí)行備份（阻塞當(dāng)前客戶端）

if (rdbSave(server.rdb_filename,rsiptr) == C_OK) {

addReply(c,shared.ok);

} else {

addReply(c,shared.err);

}

}

/*

* BGSAVE 命令實現(xiàn) [可選參數(shù)"schedule"]

*/

void bgsaveCommand(client *c) {

int schedule = 0;

/* 當(dāng)AOF正在執(zhí)行時，SCHEDULE參數(shù)修改BGSAVE的效果

* BGSAVE會在之后執(zhí)行，而不是報錯

* 可以理解為：BGSAVE被提上日程

*/

if (c->argc > 1) {

// 參數(shù)只能是"schedule"

if (c->argc == 2 && !strcasecmp(c->argv[1]->ptr,"schedule")) {

schedule = 1;

} else {

addReply(c,shared.syntaxerr);

return;

}

}

// BGSAVE正在執(zhí)行，不操作

if (server.rdb_child_pid != -1) {

addReplyError(c,"Background save already in progress");

} else if (server.aof_child_pid != -1) {

// aof正在執(zhí)行，如果schedule==1，BGSAVE被提上日程

if (schedule) {

server.rdb_bgsave_scheduled = 1;

addReplyStatus(c,"Background saving scheduled");

} else {

addReplyError(c,

"An AOF log rewriting in progress: can't BGSAVE right now. "

"Use BGSAVE SCHEDULE in order to schedule a BGSAVE whenever "

"possible.");

}

} else if (rdbSaveBackground(server.rdb_filename,NULL) == C_OK) {// 否則調(diào)用rdbSaveBackground執(zhí)行備份操作

addReplyStatus(c,"Background saving started");

} else {

addReply(c,shared.err);

}

}

有了RDB文件之后，如果服務(wù)器關(guān)機了，或者需要新增一個服務(wù)器，重新啟動數(shù)據(jù)庫服務(wù)器之后，就可以通過載入RDB文件恢復(fù)之前備份的數(shù)據(jù)。 但是bgsave會耗費較長時間，不夠?qū)崟r，會導(dǎo)致在停機的時候丟失大量數(shù)據(jù)。

AOF（Append Only File）

RDB文件保存的是數(shù)據(jù)庫的鍵值對數(shù)據(jù)，AOF保存的是數(shù)據(jù)庫執(zhí)行的寫命令。

AOF的實現(xiàn)流程有三步：

append->write->fsync

append追加命令到AOF緩沖區(qū)，write將緩沖區(qū)的內(nèi)容寫入到程序緩沖區(qū)，fsync將程序緩沖區(qū)的內(nèi)容寫入到文件。 當(dāng)AOF持久化功能處于開啟狀態(tài)時，服務(wù)器每執(zhí)行完一個命令，就會將命令以協(xié)議格式追加寫入到redisServer結(jié)構(gòu)體的aof_buf緩沖區(qū)，具體的協(xié)議這里不展開闡述。

AOF的持久化發(fā)生時期有個配置選項：appendfsync。該選項有三個值： always：所有內(nèi)容寫入并同步到aof文件 everysec：將aof_buf緩沖區(qū)的內(nèi)容寫入到AOF文件，如果距離上次同步AOF文件的 no：將aof_buf緩沖區(qū)中的所有內(nèi)容寫入到AOF文件，但并不對AOF文件進行同步，由操作系統(tǒng)決定何時進行同步，一般是默認情況下的30s。

AOF持久化模式每個寫命令都會追加到AOF文件，隨著服務(wù)器不斷運行，AOF文件會越來越大，為了避免AOF產(chǎn)生的文件太大，服務(wù)器會對AOF文件進行重寫，將操作相同key的相同命令合并，從而減少文件的大小。

舉個例子，要保存一個員工的名字、性別等信息：

> hset employee_12345 name "hoohack"

> hset employee_12345 good_at "php"

> hset employee_12345 gender "male"

只是錄入這個哈希鍵的狀態(tài)，AOF文件就需要保存三條命令，如果還有其他，比如刪除，或者更新值的操作，那命令將會更多，文件會更大，有了重寫后，就可以適當(dāng)?shù)販p少文件的大小。

AOF重寫的實現(xiàn)原理是先服務(wù)器中的數(shù)據(jù)庫，然后遍歷數(shù)據(jù)庫，找出每個數(shù)據(jù)庫中的所有鍵對象，獲取鍵值對的鍵和值，根據(jù)鍵的類型對鍵值對進行重寫。比如上面的例子，可以合并為下面的一條命令：

> hset employee_12345 name "hoohack" good_at "php" gender "male"。

AOF的重寫會執(zhí)行大量的寫入操作，Redis是單線程的，所以如果有服務(wù)器直接調(diào)用重寫，服務(wù)器就不能處理其他命令了，因此Redis服務(wù)器新起了單獨一個進程來執(zhí)行AOF重寫。

Redis執(zhí)行重寫的流程：

在子進程執(zhí)行AOF重寫時，服務(wù)端接收到客戶端的命令之后，先執(zhí)行客戶端發(fā)來的命令，然后將執(zhí)行后的寫命令追加到AOF緩沖區(qū)中，同時將執(zhí)行后的寫命令追加到AOF重寫緩沖區(qū)中。 等到子進程完成了重寫工作后，會發(fā)一個完成的信號給服務(wù)器，服務(wù)器就將AOF重寫緩沖區(qū)中的所有內(nèi)容追加到AOF文件中，然后原子性地覆蓋現(xiàn)有的AOF文件。

RDB和AOF的優(yōu)缺點

RDB持久化方式可以只通過服務(wù)器讀取數(shù)據(jù)就能加載備份中的文件到程序中，而AOF方式必須創(chuàng)建一個偽客戶端才能執(zhí)行。

RDB的文件較小，保存了某個時間點之前的數(shù)據(jù)，適合做災(zāi)備和主從同步。

RDB備份耗時較長，如果數(shù)據(jù)量大，在遇到宕機的情況下，可能會丟失部分數(shù)據(jù)。另外，RDB是通過配置使達到某種條件的時候才執(zhí)行，如果在這段時間內(nèi)宕機，那么這部分數(shù)據(jù)也會丟失。

AOF方式，在相同數(shù)據(jù)集的情況下，文件大小會比RDB方式的大。

AOF的持久化方式也是通過配置的不同，默認配置的是每秒同步，最快的模式是同步每一個命令，最壞的方式是等待系統(tǒng)執(zhí)行fsync將緩沖同步到磁盤文件中，大部分操作系統(tǒng)是30s。通常情況下會配置為每秒同步一次，所以最多會有1s的數(shù)據(jù)丟失。

怎樣的同步方式更好？

RDB和AOF方式結(jié)合。起一個定時任務(wù)，每小時備份一份服務(wù)器當(dāng)前狀態(tài)的數(shù)據(jù)，以日期和小時命名，另外起一個定時任務(wù)，定時刪除無效的備份文件（比如48小時之前）。AOF配置為1s一次。這樣一來，最多會丟失1s的數(shù)據(jù)，同時如果redis發(fā)生雪崩，也能迅速恢復(fù)為前一天的狀態(tài)，不至于停止服務(wù)。

感謝各位的閱讀！關(guān)于“redis持久化的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！