本文主要介紹了 Redis 提供的三大持久化機(jī)制，即 AOF 日志、RDB 快照以及混合持久化機(jī)制。

一、Redis 為什么需要進(jìn)行持久化

Redis 為了保證性能，會(huì)將所有數(shù)據(jù)存放在內(nèi)存中，這極大的提高了 Redis 的響應(yīng)速度，但是這也引入了一個(gè)十分嚴(yán)重的問題：一旦服務(wù)器宕機(jī)，內(nèi)存中的數(shù)據(jù)將全部丟失。這對(duì)于一款數(shù)據(jù)庫(kù)產(chǎn)品來(lái)說(shuō)是不能接受的。要避免數(shù)據(jù)丟失，最好將內(nèi)存數(shù)據(jù)持久化到磁盤等永久存儲(chǔ)介質(zhì)上。服務(wù)重啟時(shí)，先加載磁盤文件內(nèi)的數(shù)據(jù)到內(nèi)存，完成數(shù)據(jù)恢復(fù)。目前，Redis 主要提供了三大持久化機(jī)制，即 AOF（Append Only File）日志、RDB 快照、AOF 與 RDB 相結(jié)合的混合持久化。

二、AOF

2.1AOF 概述

AOF 全稱為 Append Only File，即實(shí)時(shí)將每一條寫命令記錄到 AOF 文件中，當(dāng) Redis 服務(wù)重啟時(shí)會(huì)順序執(zhí)行一遍 AOF 文件中的所有命令，以達(dá)到數(shù)據(jù)恢復(fù)的目的。我們常見的日志記錄方式主要為兩種，一種為寫前日志（Write Ahead Log, WAL），以 Mysql 數(shù)據(jù)庫(kù)為例，Mysql 在將數(shù)據(jù)寫入磁盤前，會(huì)先把修改的數(shù)據(jù)記到 redo 和 bin log 日志文件中，以便故障時(shí)進(jìn)行恢復(fù)。

而另一種則是 Redis AOF 日志所采用的寫后日志，“寫后”的意思是 Redis 會(huì)先執(zhí)行所接收到的寫命令，把數(shù)據(jù)寫入內(nèi)存，然后才將命令寫入 AOF 日志文件。Redis 在將命令記錄到 AOF 日志中的時(shí)候，并不會(huì)去檢驗(yàn)命令語(yǔ)法的正確性。因此先執(zhí)行命令，利用命令執(zhí)行這一環(huán)節(jié)對(duì)這些命令進(jìn)行語(yǔ)法校驗(yàn)，這樣既避免了寫日志時(shí)額外的檢查開銷，也不會(huì)將存在語(yǔ)法錯(cuò)誤的命令記錄到 AOF 日志中，保證了 Redis 在使用 AOF 日志恢復(fù)數(shù)據(jù)時(shí)的正確性。

2.2AOF 開啟方式

由于 AOF 功能開啟后對(duì) Redis 性能會(huì)產(chǎn)生一定影響，因此 AOF 功能默認(rèn)是關(guān)閉的。我們可以通過修改 redis.conf 配置文件中的配置參數(shù)來(lái)開啟 AOF 功能，還可以通過“config set”命令在線動(dòng)態(tài)的開啟和關(guān)閉 AOF 功能。

2.3 AOF 配置項(xiàng)

我們可以通過 redis.conf 配置文件中與 AOF 相關(guān)的配置項(xiàng)來(lái)自定義相應(yīng)的 AOF 功能，例如：

可以通過 appendfilename、appenddirname 配置項(xiàng)來(lái)指定 AOF 文件名以及文件存放目錄。

可以通過 appendfsync 配置項(xiàng)來(lái)指定 AOF 刷盤策略，其中不同的配置項(xiàng)值在數(shù)據(jù)安全性以及服務(wù)性能方面的表現(xiàn)都不相同。

配置項(xiàng) no-appendfsync-on-rewrite 表示是否在 AOF 重寫或?qū)?RDB 期間，進(jìn)行 AOF 刷盤。在 AOF 重寫和寫 RDB 文件期間會(huì)產(chǎn)生大量的磁盤 IO 讀寫操作，如果配置為 no，則表示在此期間可以進(jìn)行刷盤操作，此時(shí)如果需要同步的數(shù)據(jù)量非常大可能會(huì)阻塞 Redis 主線程，降低 Redis 服務(wù)性能。因此在生產(chǎn)環(huán)境中，如果存在大量并發(fā)的寫操作則可將該值設(shè)置為 yes；如果為大量并發(fā)的讀操作則可以設(shè)置為 no。

可以通過 auto-aof-rewrite-percentage、auto-aof-rewrite-min-size 配置項(xiàng)來(lái)指定觸發(fā) AOF 重寫的條件，以防止 AOF 文件過度膨脹，占用大量存儲(chǔ)空間。

在進(jìn)行 AOF 持久化期間，可能由于 Redis 服務(wù)突然宕機(jī)等原因?qū)е聦懭?AOF 文件的最后一條命令不完整。在 Redis 服務(wù)重啟并加載 AOF 文件時(shí)，配置項(xiàng) aof-load-truncated 的值決定了 Redis 服務(wù)能否重啟成功。若值為 yes，則刪除不完整的命令，Redis 服務(wù)正常啟動(dòng)；若值為 no，則 Redis 服務(wù)無(wú)法啟動(dòng)。

可以通過 aof-use-rdb-preamble 配置項(xiàng)來(lái)指定是否開啟混合持久化功能。

2.4 AOF 文件內(nèi)容

通過上述方式開啟 AOF 功能后，我們以一條 “set testkey testvalue” 命令來(lái)看一下命令是以怎樣的格式存儲(chǔ)在 AOF 文件中的。如圖所示其中，“*3” 表示當(dāng)前命令有三個(gè)部分，每部分都是由 “$+數(shù)字” 開頭，后面緊跟著具體的命令、鍵或值。這里，“數(shù)字”表示這部分中的命令、鍵或值一共有多少字節(jié)。例如，“$3” 表示這部分?jǐn)?shù)據(jù)有 3 個(gè)字節(jié)，也就是 “set” 命令。

2.5 寫回策略

Redis 是先執(zhí)行寫操作命令，然后將該命令記錄到 AOF 緩沖區(qū)中，最后再將緩沖區(qū)中的數(shù)據(jù)寫入磁盤。這么做避免了額外的檢查開銷，不會(huì)阻塞當(dāng)前寫操作命令的執(zhí)行。AOF 配置項(xiàng) appendfsync 的參數(shù)值，為 AOF 日志寫回磁盤的時(shí)機(jī)提供了三個(gè)選擇。

Always，同步寫回：每個(gè)寫命令執(zhí)行完，立馬將日志寫回磁盤；“同步寫回”可以做到基本不丟數(shù)據(jù)，但是在每一個(gè)寫命令執(zhí)行后都會(huì)有一個(gè)對(duì)磁盤的寫操作，這不可避免地會(huì)影響主線程性能。

Everysec，每秒寫回：每個(gè)寫命令執(zhí)行完，只是先把日志寫到 AOF 文件的內(nèi)存緩沖區(qū)，每隔一秒把緩沖區(qū)中的內(nèi)容寫入磁盤；“每秒寫回”采用一秒寫回一次的頻率，避免了“同步寫回”的性能開銷，減少了對(duì) Redis 性能的影響，但是如果發(fā)生宕機(jī)，將丟失一秒內(nèi)的所有寫操作。

No，操作系統(tǒng)控制的寫回：每個(gè)寫命令執(zhí)行完，只是先把日志寫到 AOF 文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時(shí)將緩沖區(qū)內(nèi)容寫回磁盤。由于 Redis 已不再掌握落盤的時(shí)機(jī)，因此一旦宕機(jī)沒有寫入 AOF 文件的數(shù)據(jù)就丟失了。

寫回策略對(duì)比：

2.6 AOF 重寫

在上面我們向 AOF 文件中記錄了一條 set 命令，如果此時(shí)我們對(duì)該 key 的值進(jìn)行了更新，那么 AOF 文件中記錄的日志是否也會(huì)隨之更新呢？通過 AOF 文件我們可以看到，原先寫入AOF 文件的 set 命令并沒有發(fā)生改變，而是在 AOF 文件末尾追加了一條 set testkey value 命令。

由于 AOF 日志文件中記錄的是自 Redis 啟動(dòng)后每一條寫操作，因此隨著寫操作的不斷增加，AOF 文件將越來(lái)越膨脹，為了防止 AOF 文件不斷地膨脹，Redis 為我們提供了一種 AOF 文件的重寫機(jī)制。AOF 文件在重寫時(shí)，Redis 會(huì)根據(jù)數(shù)據(jù)庫(kù)的現(xiàn)狀創(chuàng)建一個(gè)新的 AOF 文件，即讀取數(shù)據(jù)庫(kù)中的所有鍵值對(duì)，然后用一條命令將每一個(gè)鍵值對(duì)記錄到新的 AOF 文件中。比如說(shuō)，當(dāng)讀取了鍵值對(duì) “testkey”: “value” 之后，重寫機(jī)制會(huì)記錄 set testkey value 這條命令。

這樣，當(dāng)需要恢復(fù)時(shí)，可以重新執(zhí)行該命令，實(shí)現(xiàn) “testkey”: “value” 的寫入，而并不關(guān)心中間對(duì)這個(gè) key 的其他寫操作。以下圖為例，當(dāng)我們對(duì)一個(gè)列表先后做了 6 次修改操作后，列表的最后狀態(tài)是 [“D”, “E”, “F”]，此時(shí)，只用 LPUSH mylist “D”, “E”, "F" 這一條命令就能實(shí)現(xiàn)該數(shù)據(jù)的恢復(fù)，這就節(jié)省了五條命令的空間。這樣對(duì)于被頻繁修改過的鍵值對(duì)來(lái)說(shuō)，重寫能節(jié)省大量的空間。

注：圖片來(lái)源于 https://time.geekbang

雖然 AOF 重寫后，日志文件會(huì)縮小，但是，要把整個(gè)數(shù)據(jù)庫(kù)最新數(shù)據(jù)的操作日志都寫回磁盤，仍然是一個(gè)非常耗時(shí)的過程。為了避免阻塞主線程，導(dǎo)致數(shù)據(jù)庫(kù)性能下降，重寫過程是由 bgrewriteaof 子進(jìn)程來(lái)完成。每次執(zhí)行重寫時(shí)，主線程 fork 出 bgrewriteaof 子進(jìn)程。由子進(jìn)程逐一把內(nèi)存中的數(shù)據(jù)寫成操作，記入重寫日志。由于主線程未阻塞，仍然可以處理新來(lái)的操作。

此時(shí)，如果有寫操作，Redis 會(huì)把這個(gè)操作寫到 AOF 日志緩沖區(qū)。這樣一來(lái)，即使宕機(jī)了，這個(gè) AOF 日志的操作仍然是齊全的，可以用于恢復(fù)。并且這個(gè)操作也會(huì)被寫到重寫日志的緩沖區(qū)。這樣，重寫日志也不會(huì)丟失最新的操作。等到內(nèi)存數(shù)據(jù)的所有操作記錄重寫完成后，重寫日志記錄的這些最新操作也會(huì)寫入新的 AOF 文件，以保證數(shù)據(jù)庫(kù)最新狀態(tài)的記錄。此時(shí)，就可以用新的 AOF 文件替代舊文件了。

注：圖片來(lái)源于 https://time.geekbang

觸發(fā) AOF 后臺(tái)重寫的條件

AOF 重寫可以由用戶通過調(diào)用 `BGREWRITEAOF` 手動(dòng)觸發(fā)。

每次當(dāng) `serverCron`（服務(wù)器周期性操作函數(shù)）函數(shù)執(zhí)行時(shí)，它會(huì)檢查以下條件是否全部滿足，如果全部滿足的話，就觸發(fā)自動(dòng)的 AOF 重寫操作：

（1）沒有 BGSAVE 命令（RDB 持久化）/ AOF 持久化在執(zhí)行；

（2）沒有 BGREWRITEAOF 在進(jìn)行；

（3）當(dāng)前 AOF 文件大小要大于

`server.aof_rewrite_min_size`（默認(rèn)為1MB），或者在 `redis.conf` 配置了 `auto-aof-rewrite-min-size` 大?。?/p>

（4）當(dāng)前 AOF 文件大小和最后一次重寫后的大小之間的比率大于或者等于指定的增長(zhǎng)百分比（在配置文件設(shè)置了 `auto-aof-rewrite-percentage` 參數(shù)，不設(shè)置默認(rèn)為100%）

2.7 AOF 持久化詳細(xì)流程

Redis 在接收到一條客戶端發(fā)送過來(lái)的寫命令后，會(huì)先執(zhí)行該寫命令，待命令執(zhí)行成功后將該命令按照 Redis 通信協(xié)議格式寫入 AOF 緩沖區(qū)。

根據(jù)設(shè)置的 AOF 寫回策略，當(dāng)滿足寫回條件時(shí)，將 AOF 緩沖區(qū)中的數(shù)據(jù)寫入磁盤 AOF 文件中。

當(dāng) AOF 文件大小達(dá)到重寫條件后，主進(jìn)程 fork 出 bgrewriteaof 子進(jìn)程，由子進(jìn)程將內(nèi)存中的數(shù)據(jù)重寫為寫命令寫入臨時(shí)文件。

若重寫期間，主線程執(zhí)行了新的寫操作，主線程在將該寫操作記錄到 AOF 緩沖區(qū)的同時(shí)會(huì)將該寫操作寫入重寫緩存區(qū)。

待子進(jìn)程完成內(nèi)存中數(shù)據(jù)的記錄后，會(huì)將重寫緩存區(qū)記錄的數(shù)據(jù)一并寫入臨時(shí)文件。

最后利用臨時(shí)文件替換原來(lái)的 AOF 文件。

2.8 AOF 日志優(yōu)缺點(diǎn)

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

（1）AOF 可以更好的保護(hù)數(shù)據(jù)不丟失，一般 AOF 會(huì)每隔1秒，通過一個(gè)后臺(tái)線程執(zhí)行 fsync 操作，最多丟失 1 秒鐘的數(shù)據(jù)。

（2）Redis 提供了 AOF 文件的重寫機(jī)制，因此 AOF 日志文件不會(huì)膨脹的很大，并且在重寫期間也不會(huì)影響客戶端的讀寫。

（3）AOF 文件中保存的是執(zhí)行的指令，所以這個(gè)特性非常適合做災(zāi)難性的誤操作緊急恢復(fù)。

缺點(diǎn)：

（1）由于 AOF 文件中記錄的是寫操作的命令，因此對(duì)于同一份數(shù)據(jù)來(lái)說(shuō)，AOF 的日志文件通常要比 RDB 的數(shù)據(jù)快照文件要大。

（2）AOF 開啟之后，Redis 服務(wù)支持的寫 QPS 會(huì)比 RDB 支持的寫 QPS 低。

三、RDB

3.1 RDB 概述

RDB 持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。所謂內(nèi)存快照，就是指內(nèi)存中的數(shù)據(jù)在某一個(gè)時(shí)刻的狀態(tài)記錄。這樣一來(lái)，即使宕機(jī)，快照文件也不會(huì)丟失，數(shù)據(jù)的可靠性也就得到了保證。這個(gè)快照文件就稱為 RDB 文件，其中，RDB 就是 Redis DataBase 的縮寫。因?yàn)?RDB 記錄的是某一時(shí)刻的數(shù)據(jù)，并不是操作，所以，在做數(shù)據(jù)恢復(fù)時(shí)，我們可以直接把 RDB 文件讀入內(nèi)存，很快地完成數(shù)據(jù)恢復(fù)。

3.2 RDB 觸發(fā)方式

3.2.1save 觸發(fā)方式

save 命令執(zhí)行時(shí)將阻塞 Redis 服務(wù)器，在此期間 Redis 不能執(zhí)行其他客戶端的命令，直到 RDB 過程完成為止。執(zhí)行完成后，用新的 RDB 文件替代掉舊的 RDB 文件。由于 save 命令會(huì)阻塞 Redis 服務(wù)器，極大的影響了 Redis 的性能，因此不推薦 save 命令觸發(fā)方式。

3.2.2 bgsave 觸發(fā)方式

執(zhí)行該命令時(shí)，Redis 會(huì)在后臺(tái)異步將數(shù)據(jù)記錄到 RDB 文件中，同時(shí) Redis 還可以響應(yīng)客戶端請(qǐng)求。bgsave 命令執(zhí)行時(shí) Redis 主進(jìn)程將執(zhí)行 fork 操作創(chuàng)建子進(jìn)程，RDB 持久化過程由子進(jìn)程負(fù)責(zé)，完成后用新的 RDB 文件替換掉舊的 RDB 文件。阻塞只發(fā)生在 fork 階段，一般時(shí)間很短?；旧?Redis 內(nèi)部所有的 RDB 操作都是采用 bgsave 命令。

3.2.3 自動(dòng)觸發(fā)

自動(dòng)觸發(fā)是由我們的配置文件來(lái)完成的。在 redis.conf 配置文件中，里面有如下配置：

save：這里是用來(lái)配置觸發(fā) Redis 的 RDB 持久化條件，也就是什么時(shí)候?qū)?nèi)存中的數(shù)據(jù)保存到硬盤。比如 “save m n”。表示 m 秒內(nèi)數(shù)據(jù)集存在 n 次修改時(shí)，自動(dòng)觸發(fā) bgsave。因此自動(dòng)觸發(fā)的整體流程和 bgsave 命令觸發(fā)是一致的。

RDB 觸發(fā)方式對(duì)比

3.3 RDB 配置項(xiàng)

在 redis.conf 配置文件中除了用于開啟 RDB 功能的 save 配置項(xiàng)外，還有其他用于自定義 RDB 功能的配置項(xiàng)，例如：

開啟 RDB 功能后，可以將配置項(xiàng) stop-writes-on-bgsave-error 的值設(shè)置為 yes，在 bgsave 命令執(zhí)行失敗后阻止后續(xù)的寫命令執(zhí)行。通過這種方式可以讓用戶意識(shí)到數(shù)據(jù)并沒有被成功的持久化到磁盤，從而避免數(shù)據(jù)丟失問題。

可以通過配置項(xiàng) rdbcompression 來(lái)啟用 LZF 對(duì) RDB 文件進(jìn)行壓縮，雖然壓縮后 RDB 文件占用的存儲(chǔ)空間變小，但是壓縮過程會(huì)消耗系統(tǒng)資源，降低 Redis 服務(wù)性能。

從 RDB 5 開始，RDB 文件將 CRC64 校驗(yàn)和寫入文件末尾，以保證 RDB 文件的正確性，但這在保存和加載 RDB 文件時(shí)，對(duì)性能會(huì)產(chǎn)生影響。因此可以通過將配置項(xiàng) rdbchecksum 的值設(shè)置為 no，禁用校驗(yàn)和。

可以通過配置項(xiàng) dbfilename 和 dir 來(lái)指定 RDB 文件名和生成目錄。

3.4 寫時(shí)復(fù)制技術(shù)

當(dāng)由 bgsave 方式觸發(fā) RDB 持久化時(shí)，Redis 在寫 RDB 期間是可以正常處理客戶端發(fā)來(lái)的寫命令的。因此為了節(jié)省在 RDB 持久化過程中內(nèi)存的使用，Redis 會(huì)借助操作系統(tǒng)提供的寫時(shí)復(fù)制技術(shù)（Copy-On-Write, COW）。簡(jiǎn)單來(lái)說(shuō)，bgsave 子進(jìn)程是由主線程 fork 生成的，可以共享主線程的所有內(nèi)存數(shù)據(jù)。bgsave 子進(jìn)程運(yùn)行后，開始讀取主線程的內(nèi)存數(shù)據(jù)，并把它們寫入 RDB 文件。

此時(shí)，如果主線程對(duì)這些數(shù)據(jù)也都是讀操作（例如圖中的鍵值對(duì) A），那么，主線程和 bgsave 子進(jìn)程相互不影響。但是，如果主線程要修改一塊數(shù)據(jù)（例如圖中的鍵值對(duì) C），那么，這塊數(shù)據(jù)就會(huì)被復(fù)制一份，生成該數(shù)據(jù)的副本（鍵值對(duì) C’）。然后，主線程在這個(gè)數(shù)據(jù)副本上進(jìn)行修改。同時(shí)，bgsave 子進(jìn)程可以繼續(xù)把原來(lái)的數(shù)據(jù)（鍵值對(duì) C）寫入 RDB 文件。這既保證了快照的完整性，也允許主線程同時(shí)對(duì)數(shù)據(jù)進(jìn)行修改，避免了對(duì)正常業(yè)務(wù)的影響。

注：圖片來(lái)源于 https://time.geekbang

3.5RDB 文件格式

RDB 文件由以下五個(gè)部分組成；

SOF 為一個(gè)長(zhǎng)度為 5 的字符串常量 REDIS；用于標(biāo)識(shí) RDB 文件的開始，在加載 RDB 文件時(shí)可以快速識(shí)別該文件是否為 RDB 文件。

rdb_version 占 4 個(gè)字節(jié)，表示 RDB 文件的版本號(hào)。

database 是 RDB 文件中的重要部分，包含了多個(gè)非空的數(shù)據(jù)庫(kù)。每個(gè) database 又由3個(gè)部分組成：SODB 占一個(gè)字節(jié)表明數(shù)據(jù)庫(kù)的開始，db_number 表示數(shù)據(jù)庫(kù)的編號(hào)，key-value-pairs 表示當(dāng)前數(shù)據(jù)庫(kù)中的鍵值對(duì)。

EOF 占一個(gè)字節(jié)，用于標(biāo)識(shí)數(shù)據(jù)的結(jié)束，校驗(yàn)和的開始。

check_sum 校驗(yàn)和，用于校驗(yàn) RDB 文件數(shù)據(jù)是否出現(xiàn)損壞。

3.6RDB 快照優(yōu)缺點(diǎn)

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

（1）RDB 會(huì)生成多個(gè)數(shù)據(jù)文件，每個(gè)數(shù)據(jù)文件都代表了某一個(gè)時(shí)刻中 Redis 的數(shù)據(jù)，這種多個(gè)數(shù)據(jù)文件的方式，非常適合做冷備。

（2）由于 Redis 是通過子進(jìn)程執(zhí)行磁盤 IO 操作來(lái)記錄 RDB 文件的，因此 RDB 機(jī)制對(duì) Redis 的性能影響非常小，阻塞只發(fā)生在 fork 階段，可以保持 Redis 的高性能。

（3）相對(duì)于 AOF 持久化機(jī)制來(lái)說(shuō)，直接基于 RDB 數(shù)據(jù)文件來(lái)重啟和恢復(fù) Redis 進(jìn)程，更加的快速。

缺點(diǎn)：

（1）由于 RDB 文件記錄的是某個(gè)時(shí)間段內(nèi)的數(shù)據(jù)集，因此當(dāng)服務(wù)器發(fā)生宕機(jī)時(shí)，該時(shí)間段后的數(shù)據(jù)將丟失。

（2）主進(jìn)程每次在 fork 子進(jìn)程來(lái)記錄數(shù)據(jù)時(shí)，如果數(shù)據(jù)文件特別大，可能會(huì)導(dǎo)致主進(jìn)程阻塞數(shù)毫秒，或者甚至數(shù)秒。

四、混合持久化方式

由于 RDB 文件記錄的是某個(gè)時(shí)間段內(nèi)的數(shù)據(jù)集，因此兩次 RDB 期間的數(shù)據(jù)依然存在丟失的風(fēng)險(xiǎn)，但是制作 RDB 文件的頻率太高又會(huì)對(duì) Redis 性能帶來(lái)影響。因此為了避免兩次 RDB 期間數(shù)據(jù)的丟失，并且降低對(duì)性能所帶來(lái)的影響， Redis 4.0 提出了一個(gè)混合使用 AOF 日志和內(nèi)存快照的方法?？梢酝ㄟ^ redis.conf 配置文件中的配置項(xiàng) aof-use-rdb-preamble 來(lái)開啟混合持久化功能。

利用 AOF 日志記錄兩次快照間的操作，因此， AOF 文件也不會(huì)太大，也可以避免重寫開銷。如下圖所示，T1 和 T2 時(shí)刻的修改，用 AOF 日志記錄，等到第二次做全量快照時(shí)，就可以清空 AOF 日志，因?yàn)榇藭r(shí)的修改都已經(jīng)記錄到快照中了，恢復(fù)時(shí)就不再用日志了。

注：圖片來(lái)源于 https://time.geekbang

五、持久化方案選擇

Redis 官方推薦使用混合持久化方案，但我們也需要根據(jù)具體的業(yè)務(wù)需求和場(chǎng)景并結(jié)合三種持久化方案的優(yōu)缺點(diǎn)選擇合適的持久化方案。

如果對(duì)數(shù)據(jù)安全性有較高的要求，就可以選擇 AOF 或 混合持久化方案，其中 AOF 持久化方案可通過選擇不同的寫回策略來(lái)達(dá)到不同程度的數(shù)據(jù)安全性保證。

如果希望數(shù)據(jù)快速恢復(fù)，減少故障恢復(fù)時(shí)間，可以選擇 RDB 或混合持久化方案。

如果對(duì)持久化文件大小有要求，可以選擇 RDB 持久化方案，并可以啟用 LZF 對(duì) RDB 文件進(jìn)行壓縮。

如果對(duì) Redis 服務(wù)性能有較高的要求，可以選擇 RDB 或混合持久化方案。

若 Redis 僅用于緩存，可不開啟持久化功能以追求最大的服務(wù)性能。

六、參考資料

https://www.tkcnn.com/redis/manual/persistence.html

https://zhuanlan.zhihu.com/p/684331393

https://blog.csdn.net/weixin_43412762/article/details/134795648

https://developer.aliyun.com/article/1419933?spm=5176.26934562.main.1.1732527dM6Snpw

到此這篇關(guān)于Redis 持久化原理分析和使用建議詳解的文章就介紹到這了,更多相關(guān)Redis 持久化原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！