Redis 日志篇：無畏宕機(jī)實(shí)現(xiàn)高可用的殺手锏
“特立獨(dú)行是對(duì)的，融入圈子也是對(duì)的，重點(diǎn)是要想清楚自己向往怎樣的生活，為此愿意付出怎樣的代價(jià)。
”
我們通常將 Redis 作為緩存使用，提高讀取響應(yīng)性能，一旦 Redis 宕機(jī)，內(nèi)存中的數(shù)據(jù)全部丟失，假如現(xiàn)在直接訪問數(shù)據(jù)庫大量流量打到 MySQL 可能會(huì)帶來更加嚴(yán)重的問題。
另外慢慢的從數(shù)據(jù)庫讀取放到 Redis 性能必然比不過從 Redis 獲取快，也會(huì)導(dǎo)致響應(yīng)變慢。
Redis 為了實(shí)現(xiàn)無畏宕機(jī)快速恢復(fù)，設(shè)計(jì)了兩大殺手锏，分別是 AOF（Append Only FIle）日志和 RDB 快照。
學(xué)習(xí)一個(gè)技術(shù)，通常只接觸了零散的技術(shù)點(diǎn)，沒有在腦海里建立一個(gè)完整的知識(shí)框架和架構(gòu)體系，沒有系統(tǒng)觀。這樣會(huì)很吃力，而且會(huì)出現(xiàn)一看好像自己會(huì)，過后就忘記，一臉懵逼。
跟著「碼哥」一起吃透 Redis，深層次的掌握 Redis 核心原理以及實(shí)戰(zhàn)技巧。搭建一套完整的知識(shí)框架，學(xué)會(huì)全局觀去整理整個(gè)知識(shí)體系。
本篇將圍繞如下幾點(diǎn)展開：- 宕機(jī)后，如何快速恢復(fù)？
- 宕機(jī)了，Redis 如何避免數(shù)據(jù)丟失？
- 什么是 RDB 內(nèi)存快照？
- AOF 日志實(shí)現(xiàn)機(jī)制
- 什么是 寫時(shí)復(fù)制技術(shù)？
- ….
涉及的知識(shí)點(diǎn)如圖所示：
Redis 日志篇：無畏宕機(jī)與快速恢復(fù)的殺手锏
Redis 全景圖
全景圖可以圍繞兩個(gè)維度展開，分別是：
應(yīng)用維度：緩存使用、集群運(yùn)用、數(shù)據(jù)結(jié)構(gòu)的巧妙使用
系統(tǒng)維度：可以歸類為三高
- 高性能：線程模型、網(wǎng)絡(luò) IO 模型、數(shù)據(jù)結(jié)構(gòu)、持久化機(jī)制；
- 高可用：主從復(fù)制、哨兵集群、Cluster 分片集群；
- 高拓展：負(fù)載均衡
Redis 系列篇章圍繞如下思維導(dǎo)圖展開，這次從 《Redis 日志篇：無畏宕機(jī)與快速恢復(fù)的殺手锏》一起探索 Redis 的高性能、持久化機(jī)制的秘密。
吃透Redis
擁有全景圖，掌握系統(tǒng)觀。
系統(tǒng)觀其實(shí)是至關(guān)重要的，從某種程度上說，在解決問題時(shí)，擁有了系統(tǒng)觀，就意味著你能有依據(jù)、有章法地定位和解決問題。
RDB 內(nèi)存快照，讓宕機(jī)快速恢復(fù)
“65 哥：Redis 因?yàn)槟承┰蝈礄C(jī)了，會(huì)導(dǎo)致所有的流量會(huì)打到后端 MySQL，我立馬重啟 Redis，可是它的數(shù)據(jù)存在內(nèi)存里面，重啟后如何還是沒有任何數(shù)據(jù)，如何防止重啟數(shù)據(jù)丟失呢？
”
65 哥別急，「碼哥字節(jié)」帶你一步步深入理解到底 Redis 宕機(jī)后如何快速恢復(fù)的。
Redis 數(shù)據(jù)存儲(chǔ)在內(nèi)存中，是否可以考慮將內(nèi)存中的數(shù)據(jù)寫到磁盤上呢？當(dāng) Redis 重啟的時(shí)候就把保存在磁盤上的數(shù)據(jù)快速恢復(fù)到內(nèi)存中，這樣就能實(shí)現(xiàn)重啟后正常提供服務(wù)了。
“65 哥：我想到一個(gè)方案，每次執(zhí)行「寫」操作操作內(nèi)存的同時(shí)寫入到磁盤
”
這個(gè)方案有一個(gè)致命問題：每次寫指令不僅寫內(nèi)存還是寫入磁盤，磁盤的性能相對(duì)內(nèi)存太慢，會(huì)導(dǎo)致 Redis 性能大大降低。
內(nèi)存快照
“65 哥：那如何規(guī)避這個(gè)同時(shí)寫入的問題呢？
”
我們通常將 Redis 當(dāng)作緩存使用，所以即使 Redis 沒有保存全部數(shù)據(jù)，還可以通過數(shù)據(jù)庫獲取，所以 Redis 不會(huì)保存所有的數(shù)據(jù)， Redis 的數(shù)據(jù)持久化使用了「RDB 數(shù)據(jù)快照」的方式來實(shí)現(xiàn)宕機(jī)快速恢復(fù)。
“65 哥：那什么是 RDB 內(nèi)存快照呢？
”
在 Redis 執(zhí)行「寫」指令過程中，內(nèi)存數(shù)據(jù)會(huì)一直變化。所謂的內(nèi)存快照，指的就是 Redis 內(nèi)存中的數(shù)據(jù)在某一刻的狀態(tài)數(shù)據(jù)。
好比時(shí)間定格在某一刻，當(dāng)我們拍照的，通過照片就能把某一刻的瞬間畫面完全記錄下來。
Redis 跟這個(gè)類似，就是把某一刻的數(shù)據(jù)以文件的形式拍下來，寫到磁盤上。這個(gè)快照文件叫做 RDB 文件，RDB 就是 Redis DataBase 的縮寫。
Redis 通過定時(shí)執(zhí)行 RDB 內(nèi)存快照，這樣就不必每次執(zhí)行「寫」指令都寫磁盤，只需要在執(zhí)行內(nèi)存快照的時(shí)候?qū)懘疟P。既保證了唯快不破，還實(shí)現(xiàn)了持久化，宕機(jī)快速恢復(fù)。
RDB內(nèi)存快照
在做數(shù)據(jù)恢復(fù)時(shí)，直接將 RDB 文件讀入內(nèi)存完成恢復(fù)。
“65 哥：對(duì)哪些數(shù)據(jù)做快照呢？或者多久做一次快照呢？這個(gè)會(huì)影響快照的執(zhí)行效率。
”
65 哥不錯(cuò)呀，開始考慮數(shù)據(jù)效率問題了。在《Redis 核心篇：唯快不破的秘密》中我們知道他的單線程模型決定了我們要盡可能的避免會(huì)阻塞主線程的操作，避免 RDB 文件生成阻塞主線程。
生成 RDB 策略
Redis 提供了兩個(gè)指令用于生成 RDB 文件：
- save：主線程執(zhí)行，會(huì)阻塞；
- bgsave：調(diào)用 glibc 的函數(shù)fork產(chǎn)生一個(gè)子進(jìn)程用于寫入 RDB 文件，快照持久化完全交給子進(jìn)程來處理，父進(jìn)程繼續(xù)處理客戶端請(qǐng)求，生成 RDB 文件的默認(rèn)配置。
“65 哥：那在對(duì)內(nèi)存數(shù)據(jù)做「快照」的時(shí)候，內(nèi)存數(shù)據(jù)還能修改么？也就是寫指令能否正常處理？
”
首先我們要明確一點(diǎn)，避免阻塞和 RDB 文件生成期間能處理寫操作不是一回事。雖然主線程沒有阻塞，到那時(shí)為了保證快照的數(shù)據(jù)的一致性，只能處理讀操作，不能修改正在執(zhí)行快照的數(shù)據(jù)。
很明顯，為了生成 RDB 而暫停寫操作，Redis 是不答應(yīng)的。
“65 哥：那 Redis 如何實(shí)現(xiàn)一邊處理寫請(qǐng)求，同時(shí)生成 RDB 文件呢？
”
Redis 使用操作系統(tǒng)的多進(jìn)程寫時(shí)復(fù)制技術(shù) COW(Copy On Write) 來實(shí)現(xiàn)快照持久化，這個(gè)機(jī)制很有意思，也很少人知道。多進(jìn)程 COW 也是鑒定程序員知識(shí)廣度的一個(gè)重要指標(biāo)。
Redis 在持久化時(shí)會(huì)調(diào)用 glibc 的函數(shù)fork產(chǎn)生一個(gè)子進(jìn)程，快照持久化完全交給子進(jìn)程來處理，父進(jìn)程繼續(xù)處理客戶端請(qǐng)求。
子進(jìn)程剛剛產(chǎn)生時(shí)，它和父進(jìn)程共享內(nèi)存里面的代碼段和數(shù)據(jù)段。這時(shí)你可以將父子進(jìn)程想像成一個(gè)連體嬰兒，共享身體。
這是 Linux 操作系統(tǒng)的機(jī)制，為了節(jié)約內(nèi)存資源，所以盡可能讓它們共享起來。在進(jìn)程分離的一瞬間，內(nèi)存的增長(zhǎng)幾乎沒有明顯變化。
bgsave子進(jìn)程可以共享主線程的所有內(nèi)存數(shù)據(jù)，讀取主線程的數(shù)據(jù)并寫入到 RDB 文件。
在執(zhí)行SAVE命令或者BGSAVE命令創(chuàng)建一個(gè)新的 RDB 文件時(shí)，程序會(huì)對(duì)數(shù)據(jù)庫中的鍵進(jìn)行檢查，已過期的鍵不會(huì)被保存到新創(chuàng)建的 RDB 文件中。
當(dāng)主線程執(zhí)行寫指令修改數(shù)據(jù)的時(shí)候，這個(gè)數(shù)據(jù)就會(huì)復(fù)制一份副本，bgsave子進(jìn)程讀取這個(gè)副本數(shù)據(jù)寫到 RDB 文件，所以主線程就可以直接修改原來的數(shù)據(jù)。
寫時(shí)復(fù)制技術(shù)保證快照期間數(shù)據(jù)可 修改
這既保證了快照的完整性，也允許主線程同時(shí)對(duì)數(shù)據(jù)進(jìn)行修改，避免了對(duì)正常業(yè)務(wù)的影響。
Redis 會(huì)使用 bgsave 對(duì)當(dāng)前內(nèi)存中的所有數(shù)據(jù)做快照，這個(gè)操作是子進(jìn)程在后臺(tái)完成的，這就允許主線程同時(shí)可以修改數(shù)據(jù)。
“65 哥：那可以每秒都執(zhí)行 RDB 文件么，這樣即使發(fā)生宕機(jī)最多丟失 1 秒的數(shù)據(jù)。
”
過于頻繁的執(zhí)行全量數(shù)據(jù)快照，有兩個(gè)嚴(yán)重性能開銷：
- 頻繁生成 RDB 文件寫入磁盤，磁盤壓力過大。會(huì)出現(xiàn)上一個(gè) RDB 還未執(zhí)行完，下一個(gè)又開始生成，陷入死循環(huán)。
- fork 出 bgsave 子進(jìn)程會(huì)阻塞主線程，主線程的內(nèi)存越大，阻塞時(shí)間越長(zhǎng)。
優(yōu)缺點(diǎn)
快照的恢復(fù)速度快，但是生成 RDB 文件頻率不好把握，頻率過低宕機(jī)丟失的數(shù)據(jù)就會(huì)比較多；太快，又會(huì)消耗額外開銷。
RDB 采用二進(jìn)制 + 數(shù)據(jù)壓縮的方式寫磁盤，文件體積小，數(shù)據(jù)恢復(fù)速度快。
Redis 除了 RDB 全量快照以外，還設(shè)計(jì)了 AOF 寫后日志，接下來我們一起來聊下什么是 AOF 日志。
AOF 寫后日志，避免宕機(jī)數(shù)據(jù)丟失
AOF 日志存儲(chǔ)的是 Redis 服務(wù)器的順序指令序列，AOF 日志只記錄對(duì)內(nèi)存進(jìn)行修改的指令記錄。
假設(shè) AOF 日志記錄了自 Redis 實(shí)例創(chuàng)建以來所有的修改性指令序列，那么就可以通過對(duì)一個(gè)空的 Redis 實(shí)例順序執(zhí)行所有的指令，也就是「重放」，來恢復(fù) Redis 當(dāng)前實(shí)例的內(nèi)存數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。
寫前與寫后日志對(duì)比
寫前日志（Write Ahead Log, WAL）： 在實(shí)際寫數(shù)據(jù)之前，將修改的數(shù)據(jù)寫到日志文件中，故障恢復(fù)得以保證。
比如 MySQL Innodb 存儲(chǔ)引擎 中的 redo log（重做日志）便是記錄修改的數(shù)據(jù)日志，在實(shí)際修改數(shù)據(jù)前先記錄修改日志在執(zhí)行修改數(shù)據(jù)。
寫后日志： 先執(zhí)行「寫」指令請(qǐng)求，將數(shù)據(jù)寫入內(nèi)存，再記錄日志。
AOF寫后指令
日志格式
當(dāng) Redis 接受到 「set key MageByte」命令將數(shù)據(jù)寫到內(nèi)存后，Redis 會(huì)按照如下格式寫入 AOF 文件。
- 「*3」：表示當(dāng)前指令分為三個(gè)部分，每個(gè)部分都是 「$ + 數(shù)字」開頭，緊跟后面是該部分具體的「指令、鍵、值」。
- 「數(shù)字」：表示這部分的命令、鍵、值多占用的字節(jié)大小。比如 「$3」表示這部分包含 3 個(gè)字節(jié)，也就是 「set」指令。
AOF 日志格式
“65 哥：為什么 Redis 使用寫后日志這種方式呢？
”
寫后日志避免了額外的檢查開銷，不需要對(duì)執(zhí)行的命令進(jìn)行語法檢查。如果使用寫前日志的話，就需要先檢查語法是否有誤，否則日志記錄了錯(cuò)誤的命令，在使用日志恢復(fù)的時(shí)候就會(huì)出錯(cuò)。
另外，寫后才記錄日志，不會(huì)阻塞當(dāng)前的「寫」指令執(zhí)行。
“65 哥：那有了 AOF 就萬無一失了么？
”
傻孩子，可沒這么簡(jiǎn)單。假如 Redis 剛執(zhí)行完指令，還沒記錄日志宕機(jī)了，就有可能丟失這個(gè)命令相關(guān)的數(shù)據(jù)。
還有，AOF 避免了當(dāng)前命令的阻塞，但是可能會(huì)給下一個(gè)命令帶來阻塞的風(fēng)險(xiǎn)。AOF 日志是主線程執(zhí)行，將日志寫入磁盤過程中，如果磁盤壓力大就會(huì)導(dǎo)致寫磁盤很慢，導(dǎo)致后續(xù)的「寫」指令阻塞。
發(fā)現(xiàn)了沒，這兩個(gè)問題與磁盤寫回有關(guān)，如果能合理的控制「寫」指令執(zhí)行完后 AOF 日志寫回磁盤的時(shí)機(jī)，問題就迎刃而解。
寫回策略
為了提高文件的寫入效率，當(dāng)用戶調(diào)用write函數(shù)，將一些數(shù)據(jù)寫入到文件的時(shí)候，操作系統(tǒng)通常會(huì)將寫入數(shù)據(jù)暫時(shí)保存在一個(gè)內(nèi)存緩沖區(qū)里面，等到緩沖區(qū)的空間被填滿、或者超過了指定的時(shí)限之后，才真正地將緩沖區(qū)中的數(shù)據(jù)寫入到磁盤里面。
這種做法雖然提高了效率，但也為寫入數(shù)據(jù)帶來了安全問題，因?yàn)槿绻?jì)算機(jī)發(fā)生停機(jī)，那么保存在內(nèi)存緩沖區(qū)里面的寫入數(shù)據(jù)將會(huì)丟失。
為此，系統(tǒng)提供了fsync和fdatasync兩個(gè)同步函數(shù)，它們可以強(qiáng)制讓操作系統(tǒng)立即將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里面，從而確保寫入數(shù)據(jù)的安全性。
Redis 提供的 AOF 配置項(xiàng)appendfsync寫回策略直接決定 AOF 持久化功能的效率和安全性。
- always：同步寫回，寫指令執(zhí)行完畢立馬將aof_buf緩沖區(qū)中的內(nèi)容刷寫到 AOF 文件。
- everysec：每秒寫回，寫指令執(zhí)行完，日志只會(huì)寫到 AOF 文件緩沖區(qū)，每隔一秒就把緩沖區(qū)內(nèi)容同步到磁盤。
- no： 操作系統(tǒng)控制，寫執(zhí)行執(zhí)行完畢，把日志寫到 AOF 文件內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時(shí)刷寫到磁盤。
沒有兩全其美的策略，我們需要在性能和可靠性上做一個(gè)取舍。
always同步寫回可以做到數(shù)據(jù)不丟失，但是每個(gè)「寫」指令都需要寫入磁盤，性能最差。
everysec每秒寫回，避免了同步寫回的性能開銷，發(fā)生宕機(jī)可能有一秒會(huì)寫入磁盤的數(shù)據(jù)丟失，在性能和可靠性之間做了折中。
no操作系統(tǒng)控制，執(zhí)行寫指令后就寫入 AOF 文件緩沖就可以執(zhí)行后續(xù)的「寫」指令，性能最好，但是有可能丟失很多的數(shù)據(jù)。
“65 哥：那我該如何選擇策略呢？
”
我們可以根據(jù)系統(tǒng)對(duì)高性能和高可靠性的要求，來選擇寫回策略。總結(jié)一下：想要獲得高性能，就選擇 No 策略；如果想要得到高可靠性保證，就選擇 Always 策略；如果允許數(shù)據(jù)有一點(diǎn)丟失，又希望性能別受太大影響的話，那么就選擇 Everysec 策略。
優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：執(zhí)行成功才記錄日志，避免了指令語法檢查開銷。同時(shí)，不會(huì)阻塞當(dāng)前「寫」指令。
缺點(diǎn)：由于 AOF 記錄的是一個(gè)個(gè)指令內(nèi)容，具體格式請(qǐng)看上面的日志格式。故障恢復(fù)的時(shí)候需要執(zhí)行每一個(gè)指令，如果日志文件太大，整個(gè)恢復(fù)過程就會(huì)非常緩慢。
另外文件系統(tǒng)對(duì)文件大小也有限制，不能保存過大文件，文件變大，追加效率也會(huì)變低。
日志過大：AOF 重寫機(jī)制
“65 哥：AOF 日志文件過大怎么辦？
”
AOF 寫前日志，記錄的是每個(gè)「寫」指令操作。不會(huì)像 RDB 全量快照導(dǎo)致性能損耗，但是執(zhí)行速度沒有 RDB 快，同時(shí)日志文件過大也會(huì)造成性能問題，對(duì)于唯快不破的 Redis 這個(gè)真男人來說，絕對(duì)不能忍受日志過大導(dǎo)致的問題。
所以，Redis 設(shè)計(jì)了一個(gè)殺手锏「AOF 重寫機(jī)制」，Redis 提供了bgrewriteaof指令用于對(duì) AOF 日志進(jìn)行瘦身。
其原理就是開辟一個(gè)子進(jìn)程對(duì)內(nèi)存進(jìn)行遍歷轉(zhuǎn)換成一系列 Redis 的操作指令，序列化到一個(gè)新的 AOF 日志文件中。序列化完畢后再將操作期間發(fā)生的增量 AOF 日志追加到這個(gè)新的 AOF 日志文件中，追加完畢后就立即替代舊的 AOF 日志文件了，瘦身工作就完成了。
“65 哥：為啥 AOF 重寫機(jī)制能縮小日志文件呢？
”
重寫機(jī)制有「多變一」功能，將舊日志中的多條指令，在重寫后就變成了一條指令。
如下所示：
AOF重寫機(jī)制（糾錯(cuò)：重寫前記錄了 3 條指令）
“65 哥：重寫后 AOF 日志變小，最后把整個(gè)數(shù)據(jù)庫最新數(shù)據(jù)的操作日志刷寫到磁盤了。重寫會(huì)不會(huì)阻塞主線程呢？
”
「碼哥」上文說了，AOF 日志是主線程寫回的，AOF 重寫的過程實(shí)際上后臺(tái)子進(jìn)程 bgrewriteaof 完成，防止阻塞主線程。
重寫過程
和 AOF 日志由主線程寫回不同，重寫過程是由后臺(tái)子進(jìn)程 bgrewriteaof 來完成的，這也是為了避免阻塞主線程，導(dǎo)致數(shù)據(jù)庫性能下降。
總的來說，一共出現(xiàn) 兩個(gè)日志，一次拷內(nèi)存數(shù)據(jù)拷貝，分別是舊的 AOF 日志和新的 AOF 重寫日志和 Redis 數(shù)據(jù)拷貝。
Redis 會(huì)將重寫過程中的接收到的「寫」指令操作同時(shí)記錄到舊的 AOF 緩沖區(qū)和 AOF 重寫緩沖區(qū)，這樣重寫日志也保存最新的操作。等到拷貝數(shù)據(jù)的所有操作記錄重寫完成后，重寫緩沖區(qū)記錄的最新操作也會(huì)寫到新的 AOF 文件中。
每次 AOF 重寫時(shí)，Redis 會(huì)先執(zhí)行一個(gè)內(nèi)存拷貝，用于遍歷數(shù)據(jù)生成重寫記錄；使用兩個(gè)日志保證在重寫過程中，新寫入的數(shù)據(jù)不會(huì)丟失，并且保持?jǐn)?shù)據(jù)一致性。
AOF 重寫過程
“65 哥：AOF 重寫也有一個(gè)重寫日志，為什么它不共享使用 AOF 本身的日志呢？
”
這個(gè)問題問得好，有以下兩個(gè)原因：
- 一個(gè)原因是父子進(jìn)程寫同一個(gè)文件必然會(huì)產(chǎn)生競(jìng)爭(zhēng)問題，控制競(jìng)爭(zhēng)就意味著會(huì)影響父進(jìn)程的性能。
- 如果 AOF 重寫過程中失敗了，那么原本的 AOF 文件相當(dāng)于被污染了，無法做恢復(fù)使用。所以 Redis AOF 重寫一個(gè)新文件，重寫失敗的話，直接刪除這個(gè)文件就好了，不會(huì)對(duì)原先的 AOF 文件產(chǎn)生影響。等重寫完成之后，直接替換舊文件即可。
Redis 4.0 混合日志模型
重啟 Redis 時(shí)，我們很少使用 rdb 來恢復(fù)內(nèi)存狀態(tài)，因?yàn)闀?huì)丟失大量數(shù)據(jù)。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對(duì) rdb 來說要慢很多，這樣在 Redis 實(shí)例很大的情況下，啟動(dòng)需要花費(fèi)很長(zhǎng)的時(shí)間。
Redis 4.0 為了解決這個(gè)問題，帶來了一個(gè)新的持久化選項(xiàng)——混合持久化。將 rdb 文件的內(nèi)容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結(jié)束的這段時(shí)間發(fā)生的增量 AOF 日志，通常這部分 AOF 日志很小。
于是在 Redis 重啟的時(shí)候，可以先加載 rdb 的內(nèi)容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。
所以 RDB 內(nèi)存快照以稍微慢一點(diǎn)的頻率執(zhí)行，在兩次 RDB 快照期間使用 AOF 日志記錄期間發(fā)生的所有「寫」操作。
這樣快照就不用頻繁的執(zhí)行，同時(shí)由于 AOF 只需要記錄兩次快照之間發(fā)生的「寫」指令，不需要記錄所有的操作，避免出現(xiàn)文件過大的情況。
總結(jié)
Redis 設(shè)計(jì)了 bgsave 和寫時(shí)復(fù)制，盡可能避免執(zhí)行快照期間對(duì)讀寫指令的影響，頻繁快照會(huì)給磁盤帶來壓力以及 fork 阻塞主線程。
Redis 設(shè)計(jì)了兩大殺手锏實(shí)現(xiàn)了宕機(jī)快速恢復(fù)，數(shù)據(jù)不丟失。
避免日志過大，提供了 AOF 重寫機(jī)制，根據(jù)數(shù)據(jù)庫的數(shù)據(jù)最新狀態(tài)，生成數(shù)據(jù)的寫操作作為新日志，并且通過后臺(tái)完成不阻塞主線程。
綜合 AOF 和 RDB 在 Redis 4.0 提供了新的持久化策略，混合日志模型。在 Redis 重啟的時(shí)候，可以先加載 rdb 的內(nèi)容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。
最后，關(guān)于 AOF 和 RDB 的選擇問題，「碼 哥 字 節(jié)」有三點(diǎn)建議：
- 數(shù)據(jù)不能丟失時(shí)，內(nèi)存快照和 AOF 的混合使用是一個(gè)很好的選擇；
- 如果允許分鐘級(jí)別的數(shù)據(jù)丟失，可以只使用 RDB；
- 如果只用 AOF，優(yōu)先使用 everysec 的配置選項(xiàng)，因?yàn)樗诳煽啃院托阅苤g取了一個(gè)平衡。
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問題，請(qǐng)聯(lián)系我們，謝謝！
下載文檔
