看到這個標題我先愣了一下RBD是個什么鬼以我多年的經(jīng)歷Redis持久化里從來沒有RBD這個說法十有八九是把RDB打成RBD了。RDBRedis Database是Redis提供的快照持久化機制也是生產(chǎn)環(huán)境里用得最多、面試被問得最頻繁的一塊內(nèi)容。正好借這個機會把RDB持久化徹底聊透從底層原理到配置實操再到生產(chǎn)環(huán)境里那些文檔不會寫明白的坑。這篇博文不是我臨時翻文檔整理的而是踩過無數(shù)坑之后的總結(jié)。早年我還在用Redis當純緩存重啟就重啟丟了就丟了直到有一次大促前夜緩存節(jié)點因為內(nèi)存碎片問題被運維重啟第二天高峰期一到數(shù)據(jù)庫瞬間被打爆我才真正意識到持久化不是選配功能而是保命功能。所以這篇內(nèi)容適合幾類讀者剛接觸Redis、想搞懂持久化到底是怎么回事的入門者正在做Redis選型和配置的開發(fā)者以及已經(jīng)上了生產(chǎn)環(huán)境、想優(yōu)化或排查RDB問題的運維和后端同學(xué)。我會把RDB的原理講透把配置一行行拆開講再把生產(chǎn)環(huán)境里“怎么用安全、怎么用好”的實踐經(jīng)驗?zāi)贸鰜?。最后還會附上問題排查實錄都是真實場景里的典型問題。1. 先搞懂RDB為什么存在從一次“緩存全丟”事故說起很多教程上來就講RDB是什么、怎么配置我反而覺得得先講清楚一個問題RDB到底在解決什么。明白了這個后續(xù)所有配置、參數(shù)、優(yōu)化方向都會變得順理成章。1.1 一次真實的生產(chǎn)事故復(fù)盤有一年我做電商平臺的架構(gòu)優(yōu)化某個核心服務(wù)用Redis存著熱銷商品、庫存扣減結(jié)果和用戶會話數(shù)據(jù)量不大內(nèi)存峰值也就600MB左右。因為歷史原因這個Redis實例沒開持久化大家都覺得“反正是緩存掛了就掛了最多回源一次”。結(jié)果一次例行升級服務(wù)器需要重啟Redis一停再一起來整個實例空空如也?？膳碌牡胤皆谟谶@臺Redis早就被當成“緩存準存儲”在用了調(diào)用方代碼里大量用了“先查Redis查不到就不查庫”的寫法所以緩存一丟所有請求全部穿透到MySQL。不到兩分鐘數(shù)據(jù)庫連接數(shù)被打滿一堆慢查詢把CPU頂?shù)?00%接口可用性直接掉到個位數(shù)。復(fù)盤的時候所有人的第一反應(yīng)都是“等緩存自己慢慢回填”可問題是寫代碼的人根本沒做回填保護數(shù)據(jù)庫扛不住瞬間流量整個服務(wù)雪崩。那次事故之后我把系統(tǒng)里所有Redis實例全部梳理了一遍該開持久化的一律開上并且每周做一次恢復(fù)演練。這里想說的是Redis持久化從來不是給“存儲型Redis”準備的只要你把數(shù)據(jù)寫進Redis就得假設(shè)“重啟之后這份數(shù)據(jù)還有用”按這個標準來設(shè)計才不至于出事。1.2 RDB核心原理快照不是“備份”而是“寫時復(fù)制”RDB的原理一句話說就是把內(nèi)存里的全部數(shù)據(jù)在某個時間點做一次完整的二進制快照寫到磁盤上的一個文件里默認叫 dump.rdb。這個“某個時間點”很關(guān)鍵它決定了RDB不是實時的而是按策略觸發(fā)的。觸發(fā)方式分為手動和自動兩類手動就是執(zhí)行SAVE或者BGSAVE命令自動就是在redis.conf里配置save規(guī)則比如“900秒內(nèi)至少有1個key發(fā)生變化就觸發(fā)一次快照”。那么問題來了Redis是單線程處理命令的如果做快照要把內(nèi)存數(shù)據(jù)全部遍歷一遍這個過程中還能不能正常服務(wù)客戶端請求這里就要講到RDB的核心機制fork 寫時復(fù)制Copy On Write以下簡稱COW。當執(zhí)行BGSAVE時Redis主進程會通過fork系統(tǒng)調(diào)用創(chuàng)建一個子進程子進程與主進程共享同一份內(nèi)存頁。子進程負責(zé)把這份共享快照寫入磁盤主進程繼續(xù)處理客戶端請求。關(guān)鍵點在于如果主進程此時沒有寫操作那么子進程寫的就是完整內(nèi)存數(shù)據(jù)?？梢坏┲鬟M程收到寫命令需要修改某個內(nèi)存頁操作系統(tǒng)就會先把這塊內(nèi)存復(fù)制一份出來給主進程用子進程手里的仍是舊版本的那塊頁。這樣兩邊數(shù)據(jù)互不干擾子進程就能生成一個一致性快照。生活里你就能找到類似的例子。你去打印店復(fù)印一堆材料打印機工作的時候你還能繼續(xù)修改手上的原稿打印出來的都是你按下開始鍵那一刻的版本。新寫的字不會出現(xiàn)在打印結(jié)果里這就是“快照是某個時間點的狀態(tài)”的含義。理解COW機制后續(xù)看BGSAVE導(dǎo)致的阻塞、磁盤IO等問題就會很清楚真正讓你擔心的不是快照本身多耗時而是fork瞬間和寫操作劇烈時COW帶來的內(nèi)存開銷和系統(tǒng)負載。1.3 快照與AOF的本質(zhì)差異既然講了RDB就繞不開AOFAppend Only File。很多新手搞不清兩者區(qū)別我習(xí)慣用一句話區(qū)分RDB存的是“某一時刻的數(shù)據(jù)狀態(tài)”AOF存的是“從啟動至今的每一條寫命令”。一個是結(jié)果一個是過程。對比項RDB快照AOF日志存儲內(nèi)容二進制數(shù)據(jù)快照可讀的命令文本文件體積小、緊湊通常比RDB大恢復(fù)速度快直接加載快照慢需要逐條執(zhí)行命令數(shù)據(jù)丟失窗口取決于觸發(fā)頻率可能丟最近一次快照后的數(shù)據(jù)取決于刷盤策略默認每秒刷盤最多丟1秒數(shù)據(jù)對性能的影響當bgsave時CPU/內(nèi)存/磁盤有開銷持續(xù)寫入有CPU和磁盤開銷使用場景數(shù)據(jù)量大、允許少量丟失、需要快速恢復(fù)對數(shù)據(jù)完整性要求高、不能丟數(shù)據(jù)生產(chǎn)環(huán)境里我見過很多團隊盲目把兩個都打開結(jié)果機器負載蹭蹭漲。實際上兩者各有適合的場景如果你只是拿Redis做緩存丟了能回源那RDB夠用如果里面有訂單、優(yōu)惠券、計數(shù)器之類不能丟的數(shù)據(jù)那就得AOF或者RDBAOF組合。這個選型問題后面專門講。2. 實操配置與核心參數(shù)從零到落地的完整過程原理搞懂了接下來就是把RDB真正配置到你的實例里。這一節(jié)我按配置文件逐行拆解再演示手動觸發(fā)和數(shù)據(jù)恢復(fù)的完整流程。2.1 redis.conf里與RDB有關(guān)的參數(shù)一行行拆給你看默認安裝好Redis之后redis.conf里自帶了一套RDB相關(guān)的配置但默認值只適合開發(fā)環(huán)境生產(chǎn)環(huán)境需要仔細調(diào)。我們先看最核心的幾個save 900 1 save 300 10 save 60 10000這個格式很多新手看不懂我解釋一下save seconds changes意思是“在seconds秒內(nèi)如果至少有changes個key發(fā)生了變化就觸發(fā)一次BGSAVE”。上面三行合起來就是900秒15分鐘內(nèi)至少有1次寫操作就做一次快照300秒5分鐘內(nèi)至少有10次寫操作就做一次快照60秒1分鐘內(nèi)至少有10000次寫操作就做一次快照。這種多層配置的含義就是讓快照頻率跟寫入頻率聯(lián)動數(shù)據(jù)變化越頻繁備份就做得越勤絕不讓數(shù)據(jù)丟失窗口擴大到不可接受。接下來是和RDB文件本身相關(guān)的參數(shù)dbfilename dump.rdb dir /var/lib/redis rdbcompression yes rdbchecksum yesdbfilename是快照文件名dir是快照存放目錄這兩項決定了你恢復(fù)數(shù)據(jù)時去哪里找文件。rdbcompression表示是否用LZF算法壓縮RDB文件壓縮可以顯著減小文件體積對恢復(fù)速度影響不大我建議保持開啟。rdbchecksum表示是否對RDB文件做CRC64校驗開啟后會增加一些寫入開銷但能及早發(fā)現(xiàn)文件損壞生產(chǎn)環(huán)境建議開啟。還有一個參數(shù)容易被人忽略但生產(chǎn)環(huán)境特別重要stop-writes-on-bgsave-error yes這個參數(shù)的意思是如果BGSAVE執(zhí)行失敗比如磁盤滿了、權(quán)限錯誤Redis是否還繼續(xù)接受寫請求。默認是yes即一旦快照保存失敗Redis會拒絕所有寫操作。有人覺得這個設(shè)計太粗暴但官方這么做的理由很充分如果快照失敗你不停止寫入意味著數(shù)據(jù)正在悄然丟失而所有外部系統(tǒng)還以為Redis是可靠的。生產(chǎn)環(huán)境我建議就保持默認yes配合監(jiān)控在BGSAVE失敗時第一時間告警把問題暴露出來而不是讓它埋著。2.2 手動觸發(fā)RDB快照的三種方式及適用場景自動觸發(fā)是日常主力但有時你需要手動制造一份快照比如發(fā)布前備份、遷移前導(dǎo)出。手動觸發(fā)有三種方式第一種執(zhí)行SAVE命令。SAVE是同步的Redis主進程會被阻塞執(zhí)行期間所有客戶端請求都得不到響應(yīng)。數(shù)據(jù)量大時這個過程可能長達好幾秒甚至更久。因此SAVE只適用于數(shù)據(jù)量極小、能接受停服備份的場景。我在本地開發(fā)時會用生產(chǎn)環(huán)境絕不用。第二種執(zhí)行BGSAVE命令。BGSAVE是異步的立即返回Redis在后臺fork子進程完成快照。這也是我平時用得最多的方式。執(zhí)行后用LASTSAVE命令查看上次成功生成快照的時間確認真實執(zhí)行了。第三種通過SHUTDOWN SAVE命令關(guān)閉Redis時Redis會先執(zhí)行一次SAVE快照再退出。如果你沒配AOF正常關(guān)閉時最好用這個命令確保干凈退出且不丟數(shù)據(jù)。否則如果直接kill -9內(nèi)存里最后一次快照之后的數(shù)據(jù)就沒了。順便說一下從Redis 2.6開始支持BGSAVE的同時還支持異步AOF重寫可以并行執(zhí)行不過那是AOF相關(guān)的話題。RDB這邊你只需要記住生產(chǎn)環(huán)境手動備份一律用BGSAVE。2.3 數(shù)據(jù)恢復(fù)的標準流程從dump.rdb到重新上線RDB恢復(fù)說白了就是把dump.rdb放回配置的dir目錄下啟動Redis數(shù)據(jù)自動加載。但“放回去”這件事在生產(chǎn)環(huán)境常常會出各種幺蛾子。標準流程是先把Redis停掉防止進程還在寫文件導(dǎo)致文件不一致。然后確認你手里的dump.rdb文件完整且是最新的必要時用redis-check-rdb校驗一遍后面會細說。再把文件放到配置文件里dir指定的目錄文件名必須和dbfilename完全一致。確保Redis進程對目錄有讀寫權(quán)限。最后啟動Redis觀察啟動日志。如果出現(xiàn)類似“DB loaded from disk”的日志說明加載成功。啟動后隨手執(zhí)行一條命令驗證數(shù)據(jù)redis-cli DBSIZE把輸出的數(shù)量和你備份時的預(yù)期對比一下數(shù)量對得上說明恢復(fù)成功。如果數(shù)量差很多就要檢查是不是加載了舊文件或者dir配置指向了別的目錄?；謴?fù)做多了之后我養(yǎng)成了一個習(xí)慣每次配置Redis都會記下當前實例的CONFIG GET dir輸出因為有的人喜歡相對路徑有的人喜歡絕對路徑而且多實例部署時不同實例的dir可能還不一樣?？慈罩厩跋却_認路徑能少走很多彎路。2.4 小實驗親眼驗證BGSAVE不阻塞業(yè)務(wù)光說BGSAVE不阻塞不好使不如動手驗證一遍。我建議你在測試環(huán)境做這個小實驗先往Redis里灌幾萬條數(shù)據(jù)然后用redis-cli執(zhí)行BGSAVE同時用另一個終端快速執(zhí)行SET命令觀察延遲。再用SAVE做同樣的測試你會發(fā)現(xiàn)SAVE期間整個Redis瞬間沒有響應(yīng)。這個對比能讓你銘記SAVE和BGSAVE的使用邊界。再深入一點你可以在BGSAVE執(zhí)行期間用INFO persistence命令觀察輸出rdb_bgsave_in_progress:1 rdb_current_bgsave_time_sec:3這兩個字段表示當前是否正在生成快照、已經(jīng)耗時多久。如果耗時異常長說明可能有大key或者系統(tǒng)負載很高這就牽涉到生產(chǎn)環(huán)境優(yōu)化的問題了。3. 生產(chǎn)環(huán)境最佳實踐RDB不該“裸奔”配置完RDB你以為就高枕無憂了差遠了。生產(chǎn)環(huán)境里RDB只是第一條防線真正讓你數(shù)據(jù)安全的是一整套配套機制。3.1 備份要有“異地”意識dump.rdb要定期離開服務(wù)器我看到太多團隊Redis和它在同個機房連備份都放在同一臺機器上更有人把dump.rdb存在系統(tǒng)盤里。結(jié)果服務(wù)器磁盤故障備份和應(yīng)用活在一起一起去見上帝。RDB文件應(yīng)該定期復(fù)制到另一臺物理機、獨立存儲或云對象存儲上。做法不復(fù)雜寫個cron腳本每天凌晨把dump.rdb用scp、rsync等方式傳到備份中心同時對歷史備份做保留策略比如保留最近7天、最近4周各一份、最近6個月每月一份。只備份還不夠我見過最魔幻的場景是某團隊遠程拷貝了dump.rdb做災(zāi)備三年了從沒恢復(fù)驗證過。真到機房故障那天發(fā)現(xiàn)備份文件早就損壞了或者Redis版本升級不兼容備份文件。所以我堅持“備份三步走”定期備份、定期校驗、定期演練。3.2 官方推薦組合RDB AOF怎么搭配才合理Redis官方文檔其實不建議你在生產(chǎn)環(huán)境只用RDB或只用AOF而是推薦兩者結(jié)合RDB用于快速恢復(fù)和冷備份AOF保證數(shù)據(jù)完整性。原因在于如果只有RDB重啟后加載的是最后一次快照的數(shù)據(jù)之后到宕機前這段時間的數(shù)據(jù)全丟了。如果只有AOF重啟后雖然數(shù)據(jù)完整但AOF文件通常很大恢復(fù)時要逐條執(zhí)行命令大實例可能要幾分鐘這個時間窗口服務(wù)是不可用的。RDBAOF的組合在Redis重啟時優(yōu)先加載AOF文件因為AOF里記錄的數(shù)據(jù)通常比RDB新。但同時保留RDB文件一是可以做冷備二是當AOF文件損壞時還能用RDB兜底恢復(fù)。我的建議是按數(shù)據(jù)重要性分檔處理純緩存業(yè)務(wù)只開RDB訂單、庫存等核心數(shù)據(jù)RDBAOF都開且AOF刷盤策略選everysec最后一檔數(shù)據(jù)至關(guān)重要又不能容忍丟失用Redis主從加AOF的always策略但要做好性能開銷的準備。3.3 主從復(fù)制里的RDB全量同步的隱形依賴很多人沒注意到RDB不只是主節(jié)點自己用來持久化的主從復(fù)制的全量同步階段也在用RDB。當你給Redis主節(jié)點新掛一個從節(jié)點時主節(jié)點會做一次BGSAVE然后把生成的RDB文件傳給從節(jié)點從節(jié)點加載這份RDB實現(xiàn)數(shù)據(jù)對齊。理解了這一點你就能在生產(chǎn)環(huán)境里避開一些坑。比如主節(jié)點正在內(nèi)存吃緊的時候你給集群加從節(jié)點主節(jié)點fork生成RDBCOW機制把內(nèi)存占用翻倍很可能直接OOM。又比如主節(jié)點磁盤性能很差全量同步時RDB寫入慢從節(jié)點遲遲收不到完整數(shù)據(jù)兩個節(jié)點之間的同步延遲會越拉越大。增購節(jié)點前先看一眼主節(jié)點的內(nèi)存和磁盤IO情況不要在高峰期做擴容。如果數(shù)據(jù)量非常大、網(wǎng)絡(luò)帶寬又不愁可以打開repl-diskless-sync yes讓主節(jié)點直接把RDB快照通過網(wǎng)絡(luò)流向從節(jié)點不落盤減少磁盤壓力。3.4 性能提優(yōu)如何避免BGSAVE“卡”住線上業(yè)務(wù)RDB最讓人頭疼的問題是fork瞬間可能造成的服務(wù)停頓。理論上來講fork之后主進程繼續(xù)正常工作但fork本身是要復(fù)制頁表等內(nèi)核數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)量越大fork耗時越長。我見過一個32GB的Redis實例fork花了將近800毫秒期間明顯出現(xiàn)了請求毛刺。優(yōu)化方向有這么幾個控制單實例內(nèi)存上限。別把Redis當成無限大的內(nèi)存容器單實例超過10GB后Fork開銷就相當可觀建議拆實例或用集群分片。避免在短時間集中大量寫入。COW機制下寫操作越多復(fù)制內(nèi)存頁就越多內(nèi)存消耗和磁盤寫入量都翻倍。把你那些批處理腳本、定時任務(wù)錯峰執(zhí)行不要和自動快照時間重合。監(jiān)控系統(tǒng)負載磁盤IO到瓶頸時BGSAVE耗時會劇增觸發(fā)風(fēng)險成倍放大。Redis 7.0之后BGSAVE的實現(xiàn)做了不少優(yōu)化對Fork開銷的緩解有幫助。但算法改進不能替代架構(gòu)規(guī)劃基礎(chǔ)的內(nèi)存上限和寫入節(jié)奏控制任何時候都得做。3.5 別忘了安全這道底線RDB文件是敏感數(shù)據(jù)里面存放的數(shù)據(jù)可能包含用戶信息、訂單數(shù)據(jù)、業(yè)務(wù)密鑰。我見過有團隊把Redis綁定在0.0.0.0還開著默認端口RDB文件直接放在一個所有人都能讀的目錄里。這隱患非常大。生產(chǎn)環(huán)境建議把dump.rdb放到權(quán)限受限的目錄一般用redis用戶運行Redis時把目錄owner設(shè)為redis、權(quán)限設(shè)為750。如果數(shù)據(jù)敏感程度較高還要考慮對RDB文件加密落盤。Redis本身不提供加密但你可以通過文件系統(tǒng)加密比如加密盤來實現(xiàn)。還要防止RDB文件被惡意替換如果攻擊者能控制Redis寫文件路徑理論上可以構(gòu)造一個惡意RDB讓服務(wù)器啟動時加載執(zhí)行命令。所以Redis的運行用戶一定要獨立且低權(quán)限不能是root。4. 常見問題與排查技巧實錄寫配置、看文檔只能入門真正加深理解的是處理那些千奇百怪的問題。下面這幾個是我在實踐中最常遇到、也最具代表性的場景。4.1 RDB文件損壞了怎么辦redis-check-rdb來救場RDB文件可能在寫入過程中遇到斷電、磁盤滿、進程被殺等情況而損壞。Redis啟動時如果發(fā)現(xiàn)RDB文件不完整會拒絕啟動并報錯。這時候不要慌用Redis自帶的工具redis-check-rdb來檢查修復(fù)。用法很簡單redis-check-rdb /var/lib/redis/dump.rdb它會掃描整個文件揪出哪里損壞能修復(fù)的就自動修復(fù)生成一個正常文件。注意如果是硬盤物理壞道導(dǎo)致的文件損壞修復(fù)后的數(shù)據(jù)可能仍然不完整所以我在前面的備份策略里強調(diào)“多版本備份”目的就是這種情況下還能有備胎。4.2 磁盤IO暴漲罪魁竟是BGSAVE有段時間我們的Redis服務(wù)器明明只有每秒幾百次讀寫磁盤IO卻時不時沖到100%查了半天沒頭緒。最后用iostat -x 1盯了幾分鐘發(fā)現(xiàn)每次IO飆升都對應(yīng)著一個redis進程的寫文件操作再看INFO persistencerdb_last_bgsave_status:ok但rdb_last_bgsave_time_sec高達30多秒。問題出在我們的save配置太激進60秒內(nèi)只要1萬個key變化就觸發(fā)快照。當時業(yè)務(wù)正在做數(shù)據(jù)遷移大量寫入導(dǎo)致頻繁觸發(fā)BGSAVE文件又大寫盤時間成倍增加。解決辦法把自動save策略改成了一個每小時一次的低頻兜底日常高并發(fā)時段把寫遷移的熱key先行拆分并用監(jiān)控在BGSAVE執(zhí)行期間重點關(guān)注磁盤IO。調(diào)完之后IO峰值降了80%。4.3 重啟之后數(shù)據(jù)沒恢復(fù)三個隱藏原因排查“重啟后數(shù)據(jù)丟失”這種問題時大多數(shù)情況并不是Redis真把你數(shù)據(jù)弄丟了而是文件沒被正確加載。我總結(jié)了三個高頻原因。第一個dir配置不一致。你配置文件里寫的dir是/var/lib/redis但CentOS上用systemd部署時有些啟動腳本會覆蓋工作目錄實際找的是別處啟動后自然找不到dump.rdb。我總是用CONFIG GET dir確認運行時目錄。第二個文件權(quán)限問題。Redis用redis用戶跑的dump.rdb的權(quán)限若是root:rootRedis啟動時雖然能建新文件但舊的加載不了也不會報特別明顯的錯。排查看一下目錄屬主馬上就能定位。第三個啟動方式不對。沒有用SHUTDOWN SAVE或正常SIGTERM關(guān)閉Redis而是直接kill -9強制殺掉最后一次快照之后的數(shù)據(jù)自然就丟了文件本身還在。恢復(fù)時如果發(fā)現(xiàn)時間對不上看下機器有沒有異常斷電記錄就能印證是“沒來得及寫快照”。4.4 大實例全量同步慢到懷疑人生怎么破主從全量同步慢是運維大Redis時最常見的問題之一。數(shù)據(jù)量上了20GB之后主節(jié)點一邊BGSAVE一邊用網(wǎng)絡(luò)傳文件帶寬和磁盤雙雙打滿一個從節(jié)點完全同步可能要十幾分鐘期間主節(jié)點對外服務(wù)質(zhì)量明顯下降。我的處理經(jīng)驗是先給主節(jié)點和同步目標之間限速用repl-diskless-sync-delay和系統(tǒng)級帶寬限制錯峰同步別讓同步流量跟業(yè)務(wù)流量打架。同步盡量在業(yè)務(wù)低峰期做比如凌晨。如果源實例太大全量同步太傷可以在添加從節(jié)點之前從備份機上拿一份較新的RDB文件先啟動一個從節(jié)點把它作為級聯(lián)同步的中間層把主節(jié)點的壓力卸掉。最后說一點RDB全家桶雖然好用但定期檢查版本兼容性問題也是有必要的。大版本升級Redis后老版本RDB文件并不是總能被新版本直接加載先看官方Release Notes再在測試環(huán)境用真實備份驗證一次能省下很多線上事故。結(jié)語回看我這些年的實踐ROB持久化這塊最深的感悟就是一句話配置寫對只是及格能排查、能演練、能因地制宜做取舍才算真正把持久化用明白。每次給團隊做Redis培訓(xùn)我都會強調(diào)不要等項目重啟了才想起沒有持久化也不要因為開了RDB就安心躺著文件的完整性、備份的合規(guī)性、恢復(fù)的可行性都是需要持續(xù)關(guān)注的事。最后再分享一個小技巧。我習(xí)慣在每個Redis實例的配置里以注釋方式記錄持久化策略的決策原因比如“為什么這里只開RDB不開AOF”寫清楚當初的業(yè)務(wù)判斷。半年后回來看這些注釋比文檔還管用能幫你快速回憶當時的思路也避免繼任者在不了解背景的情況下胡亂改配置。希望這篇關(guān)于RDB的完整拆解能幫你在生產(chǎn)環(huán)境里把Redis持久化用得明明白白。