您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“Redis持久化策略是什么”的有關(guān)知識(shí),在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
Redis(Remote Dictionary Server ),即遠(yuǎn)程字典服務(wù),是一個(gè)開源的內(nèi)存高速緩存數(shù)據(jù)存儲(chǔ)服務(wù)。使用 ANSI C 語言編寫,支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value 數(shù)據(jù)存儲(chǔ),并提供多種語言的 API
Redis 是內(nèi)存數(shù)據(jù)庫,數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中,為了避免進(jìn)程退出導(dǎo)致數(shù)據(jù)的永久丟失,需要定期將 Redis 中的數(shù)據(jù)以某種形式(數(shù)據(jù)或命令)從內(nèi)存保存到硬盤。當(dāng)下次 Redis 重啟時(shí),利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外,為了進(jìn)行災(zāi)難備份,可以將持久化文件拷貝到一個(gè)遠(yuǎn)程位置。Redis 的持久化機(jī)制有兩種:
RDB(Redis Data Base) 內(nèi)存快照
AOF(Append Only File) 增量日志
RDB 將當(dāng)前數(shù)據(jù)保存到硬盤,AOF 則是將每次執(zhí)行的寫命令保存到硬盤(類似于 MySQL 的 Binlog)。AOF 持久化的實(shí)時(shí)性更好,即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少。
RDB ( Redis Data Base) 指的是在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤,RDB 是內(nèi)存快照(內(nèi)存數(shù)據(jù)的二進(jìn)制序列化形式)的方式持久化,每次都是從 Redis 中生成一個(gè)快照進(jìn)行數(shù)據(jù)的全量備份。
優(yōu)點(diǎn):
存儲(chǔ)緊湊,節(jié)省內(nèi)存空間。
恢復(fù)速度非???。
適合全量備份、全量復(fù)制的場景,經(jīng)常用于災(zāi)難恢復(fù)(對數(shù)據(jù)的完整性和一致性要求相對較低的場合)。
缺點(diǎn):
容易丟失數(shù)據(jù),容易丟失兩次快照之間 Redis 服務(wù)器中變化的數(shù)據(jù)。
RDB 通過 fork 子進(jìn)程對內(nèi)存快照進(jìn)行全量備份,是一個(gè)重量級(jí)操作,頻繁執(zhí)行成本高。
在默認(rèn)情況下,Redis 將數(shù)據(jù)庫快照保存在名字為 dump.rdb 的二進(jìn)制文件中。RDB 文件結(jié)構(gòu)由五個(gè)部分組成:
(1)長度為5字節(jié)的 REDIS
常量字符串。
(2)4字節(jié)的 db_version,標(biāo)識(shí) RDB 文件版本。
(3)databases:不定長度,包含零個(gè)或多個(gè)數(shù)據(jù)庫,以及各數(shù)據(jù)庫中的鍵值對數(shù)據(jù)。
(4)1字節(jié)的 EOF 常量,表示文件正文內(nèi)容結(jié)束。
(5)check_sum: 8字節(jié)長的無符號(hào)整數(shù),保存校驗(yàn)和。
數(shù)據(jù)結(jié)構(gòu)舉例,以下是數(shù)據(jù)庫[0]和數(shù)據(jù)庫[3]有數(shù)據(jù)的情況:
手動(dòng)指令觸發(fā)
手動(dòng)觸發(fā) RDB 持久化的方式可以使用 save
命令和 bgsave
命令,這兩個(gè)命令的區(qū)別如下:
save
:執(zhí)行 save
指令,阻塞 Redis 的其他操作,會(huì)導(dǎo)致 Redis 無法響應(yīng)客戶端請求,不建議使用。
bgsave
:執(zhí)行 bgsave
指令,Redis 后臺(tái)創(chuàng)建子進(jìn)程,異步進(jìn)行快照的保存操作,此時(shí) Redis 仍然能響應(yīng)客戶端的請求。
自動(dòng)間隔性保存
在默認(rèn)情況下,Redis 將數(shù)據(jù)庫快照保存在名字為 dump.rdb的二進(jìn)制文件中。可以對 Redis 進(jìn)行設(shè)置,讓它在“ N 秒內(nèi)數(shù)據(jù)集至少有 M 個(gè)改動(dòng)”這一條件被滿足時(shí),自動(dòng)保存一次數(shù)據(jù)集。
比如說, 以下設(shè)置會(huì)讓 Redis 在滿足“ 60 秒內(nèi)有至少有 10 個(gè)鍵被改動(dòng)”這一條件時(shí),自動(dòng)保存一次數(shù)據(jù)集:save 60 10
。
Redis 的默認(rèn)配置如下,三個(gè)設(shè)置滿足其一即可觸發(fā)自動(dòng)保存:
save 60 10000
save 300 10
save 900 1
自動(dòng)保存配置的數(shù)據(jù)結(jié)構(gòu)
記錄了服務(wù)器觸發(fā)自動(dòng) BGSAVE
條件的saveparams
屬性。
lastsave
屬性:記錄服務(wù)器最后一次執(zhí)行 SAVE
或者 BGSAVE
的時(shí)間。
dirty
屬性:以及自最后一次保存 RDB 文件以來,服務(wù)器進(jìn)行了多少次寫入。
RDB 持久化方案進(jìn)行備份時(shí),Redis 會(huì)單獨(dú) fork 一個(gè)子進(jìn)程來進(jìn)行持久化,會(huì)將數(shù)據(jù)寫入一個(gè)臨時(shí)文件中,持久化完成后替換舊的 RDB 文件。在整個(gè)持久化過程中,主進(jìn)程(為客戶端提供服務(wù)的進(jìn)程)不參與 IO 操作,這樣能確保 Redis 服務(wù)的高性能,RDB 持久化機(jī)制適合對數(shù)據(jù)完整性要求不高但追求高效恢復(fù)的使用場景。下面展示 RDB 持久化流程:
關(guān)鍵執(zhí)行步驟如下
Redis 父進(jìn)程首先判斷:當(dāng)前是否在執(zhí)行 save,或 bgsave/bgrewriteaof 的子進(jìn)程,如果在執(zhí)行則 bgsave 命令直接返回。bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行,主要是基于性能方面的考慮:兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤寫操作,可能引起嚴(yán)重的性能問題。
父進(jìn)程執(zhí)行 fork 操作創(chuàng)建子進(jìn)程,這個(gè)過程中父進(jìn)程是阻塞的,Redis 不能執(zhí)行來自客戶端的任何命令。父進(jìn)程 fork 后,bgsave 命令返回”Background saving started”信息并不再阻塞父進(jìn)程,并可以響應(yīng)其他命令。
子進(jìn)程進(jìn)程對內(nèi)存數(shù)據(jù)生成快照文件。
父進(jìn)程在此期間接收的新的寫操作,使用 COW 機(jī)制寫入。
子進(jìn)程完成快照寫入,替換舊 RDB 文件,隨后子進(jìn)程退出。
在生成 RDB 文件的步驟中,在同步到磁盤和持續(xù)寫入這個(gè)過程是如何處理數(shù)據(jù)不一致的情況呢?生成快照 RDB 文件時(shí)是否會(huì)對業(yè)務(wù)產(chǎn)生影響?
上面說到了 RDB 持久化過程中,主進(jìn)程會(huì) fork 一個(gè)子進(jìn)程來負(fù)責(zé) RDB 的備份,這里簡單介紹一下 fork:
Linux 操作系統(tǒng)中的程序,fork 會(huì)產(chǎn)生一個(gè)和父進(jìn)程完全相同的子進(jìn)程。子進(jìn)程與父進(jìn)程所有的數(shù)據(jù)均一致,但是子進(jìn)程是一個(gè)全新的進(jìn)程,與原進(jìn)程是父子進(jìn)程關(guān)系。
出于效率考慮,Linux 操作系統(tǒng)中使用 COW(Copy On Write)寫時(shí)復(fù)制機(jī)制,fork 子進(jìn)程一般情況下與父進(jìn)程共同使用一段物理內(nèi)存,只有在進(jìn)程空間中的內(nèi)存發(fā)生修改時(shí),內(nèi)存空間才會(huì)復(fù)制一份出來。
在 Redis 中,RDB 持久化就是充分的利用了這項(xiàng)技術(shù),Redis 在持久化時(shí)調(diào)用 glibc 函數(shù) fork 一個(gè)子進(jìn)程,全權(quán)負(fù)責(zé)持久化工作,這樣父進(jìn)程仍然能繼續(xù)給客戶端提供服務(wù)。fork 的子進(jìn)程初始時(shí)與父進(jìn)程(Redis 的主進(jìn)程)共享同一塊內(nèi)存;當(dāng)持久化過程中,客戶端的請求對內(nèi)存中的數(shù)據(jù)進(jìn)行修改,此時(shí)就會(huì)通過 COW (Copy On Write) 機(jī)制對數(shù)據(jù)段頁面進(jìn)行分離,也就是復(fù)制一塊內(nèi)存出來給主進(jìn)程去修改。
通過 fork 創(chuàng)建的子進(jìn)程能夠獲得和父進(jìn)程完全相同的內(nèi)存空間,父進(jìn)程對內(nèi)存的修改對于子進(jìn)程是不可見的,兩者不會(huì)相互影響;
通過 fork 創(chuàng)建子進(jìn)程時(shí)不會(huì)立刻觸發(fā)大量內(nèi)存的拷貝,采用的是寫時(shí)拷貝 COW (Copy On Write)。內(nèi)核只為新生成的子進(jìn)程創(chuàng)建虛擬空間結(jié)構(gòu),它們來復(fù)制于父進(jìn)程的虛擬究竟結(jié)構(gòu),但是不為這些段分配物理內(nèi)存,它們共享父進(jìn)程的物理空間,當(dāng)父子進(jìn)程中有更改相應(yīng)段的行為發(fā)生時(shí),再為子進(jìn)程相應(yīng)的段分配物理空間;
AOF (Append Only File) 是把所有對內(nèi)存進(jìn)行修改的指令(寫操作)以獨(dú)立日志文件的方式進(jìn)行記錄,重啟時(shí)通過執(zhí)行 AOF 文件中的 Redis 命令來恢復(fù)數(shù)據(jù)。類似MySql bin-log 原理。AOF 能夠解決數(shù)據(jù)持久化實(shí)時(shí)性問題,是現(xiàn)在 Redis 持久化機(jī)制中主流的持久化方案。
優(yōu)點(diǎn):
數(shù)據(jù)的備份更加完整,丟失數(shù)據(jù)的概率更低,適合對數(shù)據(jù)完整性要求高的場景
日志文件可讀,AOF 可操作性更強(qiáng),可通過操作日志文件進(jìn)行修復(fù)
缺點(diǎn):
AOF 日志記錄在長期運(yùn)行中逐漸龐大,恢復(fù)起來非常耗時(shí),需要定期對 AOF 日志進(jìn)行瘦身處理
恢復(fù)備份速度比較慢
同步寫操作頻繁會(huì)帶來性能壓力
被寫入 AOF 文件的所有命令都是以 RESP 格式保存的,是純文本格式保存在 AOF 文件中。
Redis 客戶端和服務(wù)端之間使用一種名為
RESP(REdis Serialization Protocol)
的二進(jìn)制安全文本協(xié)議進(jìn)行通信。
下面以一個(gè)簡單的 SET 命令進(jìn)行舉例:
redis> SET mykey "hello"
//客戶端命令OK
客戶端封裝為以下格式(每行用 \r\n
分隔)
*3$3SET$5mykey$5hello
AOF 文件中記錄的文本內(nèi)容如下
*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
//多出一個(gè)SELECT 0 命令,用于指定數(shù)據(jù)庫,為系統(tǒng)自動(dòng)添加
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$5\r\nhello\r\n
AOF 持久化方案進(jìn)行備份時(shí),客戶端所有請求的寫命令都會(huì)被追加到 AOF 緩沖區(qū)中,緩沖區(qū)中的數(shù)據(jù)會(huì)根據(jù) Redis 配置文件中配置的同步策略來同步到磁盤上的 AOF 文件中,追加保存每次寫的操作到文件末尾。同時(shí)當(dāng) AOF 的文件達(dá)到重寫策略配置的閾值時(shí),Redis 會(huì)對 AOF 日志文件進(jìn)行重寫,給 AOF 日志文件瘦身。Redis 服務(wù)重啟的時(shí)候,通過加載 AOF 日志文件來恢復(fù)數(shù)據(jù)。
AOF 的執(zhí)行流程包括:
命令追加(append)
Redis 先將寫命令追加到緩沖區(qū) aof_buf,而不是直接寫入文件,主要是為了避免每次有寫命令都直接寫入硬盤,導(dǎo)致硬盤 IO 成為 Redis 負(fù)載的瓶頸。
struct redisServer {
//其他域... sds aof_buf; // sds類似于Java中的String //其他域...}
文件寫入(write)和文件同步(sync)
根據(jù)不同的同步策略將 aof_buf 中的內(nèi)容同步到硬盤;
Linux 操作系統(tǒng)中為了提升性能,使用了頁緩存(page cache)。當(dāng)我們將 aof_buf 的內(nèi)容寫到磁盤上時(shí),此時(shí)數(shù)據(jù)并沒有真正的落盤,而是在 page cache 中,為了將 page cache 中的數(shù)據(jù)真正落盤,需要執(zhí)行 fsync / fdatasync 命令來強(qiáng)制刷盤。這邊的文件同步做的就是刷盤操作,或者叫文件刷盤可能更容易理解一些。
AOF 緩存區(qū)的同步文件策略由參數(shù) appendfsync 控制,有三種同步策略,各個(gè)值的含義如下:
always
:命令寫入 aof_buf 后立即調(diào)用系統(tǒng) write 操作和系統(tǒng) fsync 操作同步到 AOF 文件,fsync 完成后線程返回。這種情況下,每次有寫命令都要同步到 AOF 文件,硬盤 IO 成為性能瓶頸,Redis 只能支持大約幾百TPS寫入,嚴(yán)重降低了 Redis 的性能;即便是使用固態(tài)硬盤(SSD),每秒大約也只能處理幾萬個(gè)命令,而且會(huì)大大降低 SSD 的壽命??煽啃暂^高,數(shù)據(jù)基本不丟失。
no
:命令寫入 aof_buf 后調(diào)用系統(tǒng) write 操作,不對 AOF 文件做 fsync 同步;同步由操作系統(tǒng)負(fù)責(zé),通常同步周期為30秒。這種情況下,文件同步的時(shí)間不可控,且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多,數(shù)據(jù)安全性無法保證。
everysec
:命令寫入 aof_buf 后調(diào)用系統(tǒng) write 操作,write 完成后線程返回;fsync 同步文件操作由專門的線程每秒調(diào)用一次。everysec 是前述兩種策略的折中,是性能和數(shù)據(jù)安全性的平衡,因此是 Redis 的默認(rèn)配置,也是我們推薦的配置。
文件重寫(rewrite)
定期重寫 AOF 文件,達(dá)到壓縮的目的。
AOF 重寫是 AOF 持久化的一個(gè)機(jī)制,用來壓縮 AOF 文件,通過 fork 一個(gè)子進(jìn)程,重新寫一個(gè)新的 AOF 文件,該次重寫不是讀取舊的 AOF 文件進(jìn)行復(fù)制,而是讀取內(nèi)存中的Redis數(shù)據(jù)庫,重寫一份 AOF 文件,有點(diǎn)類似于 RDB 的快照方式。
文件重寫之所以能夠壓縮 AOF 文件,原因在于:
過期的數(shù)據(jù)不再寫入文件
無效的命令不再寫入文件:如有些數(shù)據(jù)被重復(fù)設(shè)值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset)等等
多條命令可以合并為一個(gè):如 sadd myset v1, sadd myset v2, sadd myset v3 可以合并為 sadd myset v1 v2 v3。不過為了防止單條命令過大造成客戶端緩沖區(qū)溢出,對于 list、set、hash、zset類型的 key,并不一定只使用一條命令;而是以某個(gè)常量為界將命令拆分為多條。這個(gè)常量在 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 中定義,不可更改,2.9版本中值是64。
前面提到 AOF 的缺點(diǎn)時(shí),說過 AOF 屬于日志追加的形式來存儲(chǔ) Redis 的寫指令,這會(huì)導(dǎo)致大量冗余的指令存儲(chǔ),從而使得 AOF 日志文件非常龐大,比如同一個(gè) key 被寫了 10000 次,最后卻被刪除了,這種情況不僅占內(nèi)存,也會(huì)導(dǎo)致恢復(fù)的時(shí)候非常緩慢,因此 Redis 提供重寫機(jī)制來解決這個(gè)問題。Redis 的 AOF 持久化機(jī)制執(zhí)行重寫后,保存的只是恢復(fù)數(shù)據(jù)的最小指令集,我們?nèi)绻胧謩?dòng)觸發(fā)可以使用如下指令:
bgrewriteaof
文件重寫時(shí)機(jī)
相關(guān)參數(shù):
aof_current_size:表示當(dāng)前 AOF 文件空間
aof_base_size:表示上一次重寫后 AOF 文件空間
auto-aof-rewrite-min-size: 表示運(yùn)行 AOF 重寫時(shí)文件的最小體積,默認(rèn)為64MB
auto-aof-rewrite-percentage: 表示當(dāng)前 AOF 重寫時(shí)文件空間(aof_current_size)超過上一次重寫后 AOF 文件空間(aof_base_size)的比值多少后會(huì)重寫。
同時(shí)滿足下面兩個(gè)條件,則觸發(fā) AOF 重寫機(jī)制:
aof_current_size 大于 auto-aof-rewrite-min-size
當(dāng)前 AOF 相比上一次 AOF 的增長率:(aof_current_size - aof_base_size)/aof_base_size 大于或等于 auto-aof-rewrite-percentage
AOF 重寫流程如下:
bgrewriteaof 觸發(fā)重寫,判斷是否存在 bgsave 或者 bgrewriteaof 正在執(zhí)行,存在則等待其執(zhí)行結(jié)束再執(zhí)行
主進(jìn)程 fork 子進(jìn)程,防止主進(jìn)程阻塞無法提供服務(wù),類似 RDB
子進(jìn)程遍歷 Redis 內(nèi)存快照中數(shù)據(jù)寫入臨時(shí) AOF 文件,同時(shí)會(huì)將新的寫指令寫入 aof_buf 和 aof_rewrite_buf 兩個(gè)重寫緩沖區(qū),前者是為了寫回舊的 AOF 文件,后者是為了后續(xù)刷新到臨時(shí) AOF 文件中,防止快照內(nèi)存遍歷時(shí)新的寫入操作丟失
子進(jìn)程結(jié)束臨時(shí) AOF 文件寫入后,通知主進(jìn)程
主進(jìn)程會(huì)將上面 3 中的 aof_rewirte_buf 緩沖區(qū)中的數(shù)據(jù)寫入到子進(jìn)程生成的臨時(shí) AOF 文件中
主進(jìn)程使用臨時(shí) AOF 文件替換舊 AOF 文件,完成整個(gè)重寫過程。
在實(shí)際中,為了避免在執(zhí)行命令時(shí)造成客戶端輸入緩沖區(qū)溢出,重寫程序會(huì)檢查集合元素?cái)?shù)量是否超過 REDIS_AOF_REWRITE_ITEMS_PER_CMD 常量的值,如果超過了,則會(huì)使用多個(gè)命令來記錄,而不單單使用一條命令。
Redis 2.9版本中該常量為64,如果一個(gè)命令的集合鍵包含超過了64個(gè)元素,重寫程序會(huì)拆成多個(gè)命令。
AOF重寫是一個(gè)有歧義的名字,該功能是通過直接讀取數(shù)據(jù)庫的鍵值對實(shí)現(xiàn)的,程序無需對現(xiàn)有AOF文件進(jìn)行任何讀入、分析或者寫入操作。
Redis 為什么考慮使用 AOF 而不是 WAL 呢?
很多數(shù)據(jù)庫都是采用的 Write Ahead Log(WAL)寫前日志,其特點(diǎn)就是先把修改的數(shù)據(jù)記錄到日志中,再進(jìn)行寫數(shù)據(jù)的提交,可以方便通過日志進(jìn)行數(shù)據(jù)恢復(fù)。
但是 Redis 采用的卻是 AOF(Append Only File)寫后日志,特點(diǎn)就是先執(zhí)行寫命令,把數(shù)據(jù)寫入內(nèi)存中,再記錄日志。
如果先讓系統(tǒng)執(zhí)行命令,只有命令能執(zhí)行成功,才會(huì)被記錄到日志中。因此,Redis 使用寫后日志這種形式,可以避免出現(xiàn)記錄錯(cuò)誤命令的情況。
另外還有一個(gè)原因就是:AOF 是在命令執(zhí)行后才記錄日志,所以不會(huì)阻塞當(dāng)前的寫操作。
在版本號(hào)大于等于2.4的 Redis 中,BGSAVE 執(zhí)行的過程中,不可以執(zhí)行 BGREWRITEAOF。反過來說,在 BGREWRITEAOF 執(zhí)行的過程中,也不可以執(zhí)行 BGSAVE。這可以防止兩個(gè) Redis 后臺(tái)進(jìn)程同時(shí)對磁盤進(jìn)行大量的 I/O 操作。
如果 BGSAVE 正在執(zhí)行,并且用戶顯示地調(diào)用 BGREWRITEAOF 命令,那么服務(wù)器將向用戶回復(fù)一個(gè) OK 狀態(tài),并告知用戶,BGREWRITEAOF 已經(jīng)被預(yù)定執(zhí)行:一旦 BGSAVE 執(zhí)行完畢 BGREWRITEAOF 就會(huì)正式開始。
當(dāng) Redis 啟動(dòng)時(shí),如果 RDB 持久化和 AOF 持久化都被打開了,那么程序會(huì)優(yōu)先使用 AOF 文件來恢復(fù)數(shù)據(jù)集,因?yàn)?AOF 文件所保存的數(shù)據(jù)通常是最完整的。
Redis4.0 后大部分的使用場景都不會(huì)單獨(dú)使用 RDB 或者 AOF 來做持久化機(jī)制,而是兼顧二者的優(yōu)勢混合使用。其原因是 RDB 雖然快,但是會(huì)丟失比較多的數(shù)據(jù),不能保證數(shù)據(jù)完整性;AOF 雖然能盡可能保證數(shù)據(jù)完整性,但是性能確實(shí)是一個(gè)詬病,比如重放恢復(fù)數(shù)據(jù)。
Redis從4.0版本開始引入 RDB-AOF 混合持久化模式,這種模式是基于 AOF 持久化模式構(gòu)建而來的,混合持久化通過 aof-use-rdb-preamble yes
開啟。
那么 Redis 服務(wù)器在執(zhí)行 AOF 重寫操作時(shí),就會(huì)像執(zhí)行 BGSAVE 命令那樣,根據(jù)數(shù)據(jù)庫當(dāng)前的狀態(tài)生成出相應(yīng)的 RDB 數(shù)據(jù),并將這些數(shù)據(jù)寫入新建的 AOF 文件中,至于那些在 AOF 重寫開始之后執(zhí)行的 Redis 命令,則會(huì)繼續(xù)以協(xié)議文本的方式追加到新 AOF 文件的末尾,即已有的 RDB 數(shù)據(jù)的后面。
換句話說,在開啟了 RDB-AOF 混合持久化功能之后,服務(wù)器生成的 AOF 文件將由兩個(gè)部分組成,其中位于 AOF 文件開頭的是 RDB 格式的數(shù)據(jù),而跟在 RDB 數(shù)據(jù)后面的則是 AOF 格式的數(shù)據(jù)。
當(dāng)一個(gè)支持 RDB-AOF 混合持久化模式的 Redis 服務(wù)器啟動(dòng)并載入 AOF 文件時(shí),它會(huì)檢查 AOF 文件的開頭是否包含了 RDB 格式的內(nèi)容。
如果包含,那么服務(wù)器就會(huì)先載入開頭的 RDB 數(shù)據(jù),然后再載入之后的 AOF 數(shù)據(jù)。
如果 AOF 文件只包含 AOF 數(shù)據(jù),那么服務(wù)器將直接載入 AOF 數(shù)據(jù)。
其日志文件結(jié)構(gòu)如下:
“Redis持久化策略是什么”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。