1. RDB快照（snapshot）

在默認情況下柱衔， Redis 將內(nèi)存數(shù)據(jù)庫快照保存在名字為?dump.rdb的二進制文件中。

你可以對 Redis 進行設置厅篓， 讓它在“N?秒內(nèi)數(shù)據(jù)集至少有?M?個改動”這一條件被滿足時秀存，

自動保存一次數(shù)據(jù)集捶码。

比如說羽氮， 以下設置會讓 Redis 在滿足“60?秒內(nèi)有至少有?1000?個鍵被改動”這一條件時，

自動保存一次數(shù)據(jù)集：

save 60 1000

優(yōu)點：

RDB?是一個非常緊湊（compact）的文件惫恼，體積小档押，因此在傳輸速度上比較快，因此適合災難恢復。

RDB?在恢復大數(shù)據(jù)集時的速度比?AOF?的恢復速度要快得多令宿。

缺點：

RDB是一個快照過程叼耙，無法完整的保存所有數(shù)據(jù)，尤其在數(shù)據(jù)量比較大時候粒没，一旦出現(xiàn)故障丟失的數(shù)據(jù)將更多筛婉。

RDB文件是特定的格式，閱讀性差癞松，由于格式固定爽撒，可能存在不兼容情況。

~~~

bgsave

~~~

bgsave執(zhí)行原理：

針對save命令進行優(yōu)化响蓉，Redis中所有涉及RDB操作都采用bgsava方式?

優(yōu)勢

1.采用子線程創(chuàng)建RDB文件()硕勿，不會對redis服務器性能造成大的影響( 性能最大化)；

2.快照生成的RDB文件是一種壓縮的二進制文件枫甲，可以方便的在網(wǎng)絡中傳輸和保存源武。通過RDB文件可以方便的將redis數(shù)據(jù)恢復到某一歷史時刻，可以提高數(shù)據(jù)安全性想幻，避免宕機等意外對數(shù)據(jù)的影響粱栖。

3.適合大規(guī)模的數(shù)據(jù)恢復, RDB的啟動恢復效率高。

4.如果業(yè)務對數(shù)據(jù)完整性和一致性要求不高脏毯，RDB是很好的選擇查排。?

劣勢

1.在redis文件在時間點A生成，之后產(chǎn)生了新數(shù)據(jù)抄沮，還未到達另一次生成RDB文件的條件跋核，redis服務器崩潰了，那么在時間點A之后的數(shù)據(jù)會丟失掉叛买，數(shù)據(jù)一致性不是完美的好砂代，如果可以接受這部分丟失的數(shù)據(jù)，可以用生成RDB的方式率挣；

2.快照持久化方法通過調(diào)用fork()方法創(chuàng)建子線程刻伊。當redis內(nèi)存的數(shù)據(jù)量比較大時，創(chuàng)建子線程和生成RDB文件會占用大量的系統(tǒng)資源和處理時間椒功，對 redis處理正常的客戶端請求造成較大影響捶箱。

3.數(shù)據(jù)的完整性和一致性不高，因為RDB可能在最后一次備份時宕機了动漾。

4.備份時占用內(nèi)存丁屎，因為Redis 在備份時會獨立創(chuàng)建一個子進程，將數(shù)據(jù)寫入到一個臨時文件（此時內(nèi)存中的數(shù)據(jù)是原來的兩倍哦）旱眯，最后再將臨時文件替換之前的備份文件晨川。所以 Redis 的持久化和數(shù)據(jù)的恢復要選擇在夜深人靜的時候執(zhí)行是比較合理的证九。

Q: 通過RDB文件恢復數(shù)據(jù)?

答: 將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啟redis服務即可共虑。在實際開發(fā)中愧怜，一般會考慮到物理機硬盤損壞情況，選擇備份dump.rdb 妈拌。 作者：WeiyiGeek https://www.bilibili.com/read/cv13235983 出處：bilibili

RDB文件恢復數(shù)據(jù)流程?

?1拥坛、先備份一份 dump.rdb 為 dump_bak.rdb（模擬線上）

?2、flushall 清空數(shù)據(jù)（模擬數(shù)據(jù)丟失,需要注意 flushall 也會觸發(fā)rbd持久化）?

3尘分、將 dump_bak.rdb 替換為 dump.rdb?

4渴逻、重啟redis服務，恢復數(shù)據(jù)?

2. AOF（append-only file）

快照功能并不是非常耐久（durable）： 如果 Redis 因為某些原因而造成故障停機音诫， 那么服務器將丟失最近寫入惨奕、且仍未保存到快照中的那些數(shù)據(jù)。從 1.1 版本開始竭钝， Redis 增加了一種完全耐久的持久化方式： AOF 持久化梨撞，將修改的每一條指令記錄進文件

AOF文件生成機制

答: 生成過程包括三個步驟,即。

redis 打開AOF持久化功能之后香罐，redis在執(zhí)行完一個寫命令后卧波，把執(zhí)行的命令首先追加到redis內(nèi)部的aof_buf緩沖區(qū)膜末尾，此時緩沖區(qū)的記錄還沒有寫到Appendonly.aof文件中庇茫。然后港粱，緩沖區(qū)的寫命令會被寫入到 AOF 文件，這一過程是文件寫入過程旦签。對于操作系統(tǒng)來說查坪，調(diào)用write函數(shù)并不會立刻將數(shù)據(jù)寫入到硬盤，為了將數(shù)據(jù)真正寫入硬盤宁炫，還需要調(diào)用fsync函數(shù)偿曙，調(diào)用fsync函數(shù)即是文件同步的過程，只有經(jīng)過了文件的同步過程羔巢，寫命令才真正的被保存到了AOF文件中望忆。選項 Appendfsync 就是配置同步的頻率的。?

你可以通過修改配置文件來打開 AOF 功能：

appendonly yes

從現(xiàn)在開始竿秆， 每當 Redis 執(zhí)行一個改變數(shù)據(jù)集的命令時（比如?SET）启摄， 這個命令就會被追加到 AOF 文件的末尾。

這樣的話幽钢， 當 Redis 重新啟動時歉备， 程序就可以通過重新執(zhí)行 AOF 文件中的命令來達到重建數(shù)據(jù)集的目的。

你可以配置 Redis 多久才將數(shù)據(jù)?fsync?到磁盤一次搅吁。

有三個選項：

appendfsync always威创。每次有新命令追加到 AOF 文件時就執(zhí)行一次?fsync?：非常慢，也非常安全谎懦。

appendfsync everysec肚豺。每秒?fsync?一次：足夠快（和使用 RDB 持久化差不多），并且在故障時只會丟失 1 秒鐘的數(shù)據(jù)界拦。

appendfsync no吸申。從不?fsync?：將數(shù)據(jù)交給操作系統(tǒng)來處理。更快享甸，也更不安全的選擇截碴。

推薦（并且也是默認）的措施為每秒?fsync?一次， 這種?fsync?策略可以兼顧速度和安全性蛉威。

優(yōu)點：

數(shù)據(jù)更完整日丹，秒級數(shù)據(jù)丟失(取決于設置fsync策略)。蚯嫌、

兼容性較高哲虾，由于是基于redis通訊協(xié)議而形成的命令追加方式，無論何種版本的redis都兼容择示。

aof文件是明文的束凑，可閱讀性較好。

缺點：

數(shù)據(jù)文件體積較大栅盲，即使有重寫機制汪诉，但是在相同的數(shù)據(jù)集情況下，AOF文件通常比RDB文件大谈秫。

相對RDB方式扒寄，AOF速度慢于RDB，并且在數(shù)據(jù)量大時候拟烫，恢復速度AOF速度也是慢于RDB旗们。

由于頻繁地將命令同步到文件中，AOF持久化對性能的影響相對RDB較大构灸。

AOF文件重寫

1谬返、redis不斷的將寫命令保存到AOF文件中揩懒，導致AOF文件越來越大，當AOF文件體積過大時，數(shù)據(jù)恢復的時間也是非常長的淮逊，因此，redis提供了重寫或者說壓縮AOF文件的功能混滔。

比如枢冤，AOF重寫功能就是干這個事情的。重寫時寂拆，可以調(diào)用BGREWRITEAOF命令重寫AOF文件奢米，與新建子線程bgsave命令的工作原理相似抓韩。也可以通過配置文件配置什么條件下對AOF文件重寫。

2鬓长、重寫的原理:Redis 會fork出一條新進程谒拴，讀取內(nèi)存中的數(shù)據(jù)，并重新寫到一個臨時文件中涉波。并沒有讀取舊文件（太大了）英上。最后替換舊的aof文件

3、重寫觸發(fā)機制:當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)啤覆，這里的“一倍”和“64M” 可以通過配置文件修改

aof 文件記錄的是每一條redis命令苍日，有時候我們會對某一個key進行多次set，中間會產(chǎn)生很多條命令窗声，但是結(jié)果只有一個相恃。

優(yōu)勢

1.該機制可以帶來更高的數(shù)據(jù)安全性，即數(shù)據(jù)持久化; 常規(guī)三種同步策略即每秒同步()笨觅、每修改同步()和不同步豆茫；

2.由于該機制對日志文件的寫入操作采用的是Append模式，即使過程中出現(xiàn)宕機也不會破壞日志文件中已經(jīng)存在的內(nèi)容,如果數(shù)據(jù)不完整在Redis下次啟動之前, 通過redis-check-aof解決數(shù)據(jù)一致性問題;

3.如果日志文件體積過大可以啟動rewrite機制屋摇，即redis以Append模式不斷的將修改數(shù)據(jù)寫到老的磁盤文件中揩魂，同時創(chuàng)建新文件記錄期間有哪些修改命令執(zhí)行，此項極大的保證數(shù)據(jù)的安全性;

4.AOF文件可讀性強,其包含一個格式清晰炮温、易于理解的日志文件用于記錄所有的修改操作（）

5.數(shù)據(jù)的完整性和一致性更高

劣勢

1.AOF文件比RDB文件較大, 對于相同數(shù)量的數(shù)據(jù)集而言;

2.redis負載較高時火脉，RDB文件比AOF文件具有更好的性能；

3.RDB使用快照的方式持久化整個redis數(shù)據(jù)柒啤，而aof只是追加寫命令倦挂，因此從理論上來說，RDB比AOF方式更加健壯担巩，另外方援，官方文檔也指出，在某些情況下涛癌，AOF的確也存在一些bug犯戏，比如使用阻塞命令時，這些bug的場景RDB是不存在的拳话。

4.因為AOF記錄的內(nèi)容多先匪，文件會越來越大，數(shù)據(jù)恢復也會越來越慢弃衍。

5.根據(jù)同步策略的不同呀非，AOF在運行效率上往往會慢于RDB,總的來說每秒同步策略的效率還是比較高的?

set name 1

...

set name 12

set name 123

...

set name 1234

set name 12345

例如我們執(zhí)行了上述命令，aof 文件會記錄著每一條命令。在redis重啟時岸裙，會逐條執(zhí)行上述的命令猖败。但是其實可以精簡為set name 12345，其余的幾條命令其實沒有意義降允。AOF重寫就是實現(xiàn)了這個功能恩闻。

相關(guān)配置：

auto-aof-rewrite-percentage 100? # 指當前aof文件比上次重寫的增長比例大小，達到這個大小就進行 aof 重寫

auto-aof-rewrite-min-size 64mb? # 最開始aof文件必須要達到這個文件時才觸發(fā)拟糕，后面的每次重寫就不會根據(jù)這個變量了

以上配置的意思是：

在 aof 文件小于64mb的時候不進行重寫判呕，當?shù)竭_64mb的時候倦踢，就重寫一次送滞。重寫后的 aof 文件可能是10mb。上面配置了auto-aof-rewrite-percentage 100辱挥，即 aof 文件到了20mb的時候犁嗅，又開始重寫一次。以此類推晤碘。

AOF 是在后臺自動重寫（redis會fork一個子進程來進行備份褂微，保證主進程不會阻塞），也可以人為執(zhí)行命令?bgrewriteaof?重寫 AOF园爷。

使用子進程來進行AOF重寫時會遇到的問題

問題：

子進程在進行AOF重寫期間宠蚂，服務器進程還要繼續(xù)處理命令請求，而新的命令可能對現(xiàn)有的數(shù)據(jù)進行修改童社，這會讓當前數(shù)據(jù)庫的數(shù)據(jù)和重寫后的AOF文件中的數(shù)據(jù)不一致求厕。

解決方案：

要知道redis是怎么處理這個問題的，需要先了解下AOF重寫的具體實現(xiàn)：

AOF文件重寫過程與RDB快照bgsave工作過程有點相似扰楼，都是通過fork子進程呀癣，由子進程完成相應的操作，同樣的在fork子進程簡短的時間內(nèi)弦赖，redis是阻塞的项栏。

（1）開始bgrewriteaof，判斷當前有沒有bgsave命令(RDB持久化)/bgrewriteaof在執(zhí)行蹬竖，倘若有沼沈，則這些命令執(zhí)行完成以后在執(zhí)行。

（2）主進程fork出子進程币厕，在這一個短暫的時間內(nèi)庆冕，redis是阻塞的。

（3）主進程fork完子進程繼續(xù)接受客戶端請求劈榨。此時访递，客戶端的寫請求不僅僅寫入aof_buf緩沖區(qū)，還寫入aof_rewrite_buf重寫緩沖區(qū)同辣。一方面是寫入aof_buf緩沖區(qū)并根據(jù)appendfsync策略同步到磁盤拷姿，保證原有AOF文件完整和正確惭载。另一方面寫入aof_rewrite_buf重寫緩沖區(qū)，保存fork之后的客戶端的寫請求响巢，防止新AOF文件生成期間丟失這部分數(shù)據(jù)描滔。

（4.1）子進程寫完新的AOF文件后，向主進程發(fā)信號踪古，父進程更新統(tǒng)計信息含长。

（4.2）主進程把aof_rewrite_buf中的數(shù)據(jù)寫入到新的AOF文件。

（5.）使用新的AOF文件覆蓋舊的AOF文件伏穆，標志AOF重寫完成拘泞。

手動執(zhí)行重寫

AOF寫和重寫流程：

Q: 如何觸發(fā)AOF快照?

答: 根據(jù)配置文件觸發(fā)，可以是每次執(zhí)行觸發(fā)枕扫，可以是每秒觸發(fā)陪腌，可以不同步。

Q: 如何根據(jù)AOF文件恢復數(shù)據(jù)?

答: 正常情況下烟瞧，將Appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下诗鸭，重啟redis服務即可。但在實際開發(fā)中参滴，可能因為某些原因?qū)е??文件格式異常强岸，從而導致數(shù)據(jù)還原失敗，可以通過命令進行修復 砾赔。?

配置說明:?

~~~

cat > redis.conf <<'EOF'

# 持久化數(shù)據(jù)存儲

dir "/data"

# 是否開啟AOF默認為否

appendonly yes

# AOF文件名字及路徑蝌箍，若RDB路徑已設置這里可不設置

appendfilename "appendonly.aof"

# AOF的3種模式，no(使用系統(tǒng)緩存處理过蹂，快）十绑、always(記錄全部操作，慢但比較安全）酷勺、everysec(每秒同步本橙，折中方案，默認使用）

appendfsync everysec

# 重寫期間是否同步數(shù)據(jù)脆诉，默認為no

no-appendfsync-on-rewrite no

# 配置重寫觸發(fā)機制: 確保AOF日志文件不會過大甚亭，保持跟redis內(nèi)存數(shù)據(jù)量一致。

# 配置說明:當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)(根據(jù)實際環(huán)境進行配置)

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 256mb

# AOF重寫策略是否啟用击胜，默認為yes

aof-rewrite-incremental-fsync yes

# 加載AOF時如果報錯則會繼續(xù)但寫入log亏狰，如果為no則不會繼續(xù)

aof-load-truncated yes

# Redis5.0有的功能AOF重寫及恢復可以使用RDB文件及AOF文件，速度更快偶摔，默認yes

aof-use-rdb-preamble yes

EOF

~~~

Q: 如何通過AOF文件恢復數(shù)據(jù)流程??

1暇唾、執(zhí)行flushall，模擬數(shù)據(jù)丟失

2、重啟 redis 服務策州，恢復數(shù)據(jù)

3瘸味、修改 appendonly.aof，模擬文件異常

4够挂、重啟 Redis 服務失敗旁仿，這同時也說明了RDB和AOF可以同時存在，且優(yōu)先加載AOF文件孽糖。

5枯冈、使用 redis-check-aof 校驗 appendonly.aof 文件。

#? 針對Redis aof 持久化文件進行完整性檢測并進行修復

/usr/local/redis/bin/redis-check-aof --fix appendonly.aof

? # The AOF appears to start with an RDB preamble.

? # Checking the RDB preamble to start:

? # [offset 0] Checking RDB file appendonly.aof

? # [offset 27] AUX FIELD redis-ver = '5.0.10'

? # [offset 41] AUX FIELD redis-bits = '64'

? # [offset 53] AUX FIELD ctime = '1631088747'

? # [offset 68] AUX FIELD used-mem = '31554944'

? # [offset 84] AUX FIELD aof-preamble = '1'

? # [offset 86] Selecting DB ID 0

? # [offset 13350761] Checksum OK

? # [offset 13350761] \o/ RDB looks OK! \o/

? # [info] 157070 keys read

? # [info] 0 expires

? # [info] 0 already expired

? # RDB preamble is OK, proceeding with AOF tail...

? # 0x? ? ? ? 27b66b0: Expected prefix '*', got: 'R'

? # AOF analyzed: size=116993914, ok_up_to=41641648, ok_up_to_line=1816854, diff=75352266

? # AOF is not valid. Use the option to try fixing it.

6办悟、重啟Redis 服務后正常尘奏。

# 利用源實例生成的aof文件數(shù)據(jù)進行恢復到其它主機中。

redis-cli -h 17.20.0.2 -a password --pipe < applendonly.aof

注意:當你使用 flushall 清空數(shù)據(jù)的時候誉尖，重啟redis服務發(fā)現(xiàn)數(shù)據(jù)沒恢復罪既，是因為 FLUSHALL 命令也被寫入AOF文件中铸题，會導致數(shù)據(jù)恢復失敗铡恕，所只需要刪除aof文件中的flushall就行了。

在數(shù)據(jù)庫恢復時把 aof(Append only file) 從中對redis數(shù)據(jù)庫操作的命令丢间，增刪改操作的命令探熔，執(zhí)行了一遍即可。

實際案例:

描述: 用于異步執(zhí)行一個??文件重寫操作, 重寫會創(chuàng)建一個當前 AOF 文件的體積優(yōu)化版本烘挫，因為AOF為記錄每次的操作會導致實際記錄冗雜诀艰、使得文件過大，所以需要做重寫操作饮六。

重寫方式分為以下兩種:

# (1) AOF自動重寫:按配置文件條件自動觸發(fā)重寫

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 256mb

# (2) AOF手動重寫:使用 redis-cli 連接到 server 端執(zhí)行 bgrewriteaof 進行手動重寫其垄。

# 注意:從 Redis 2.4 開始， AOF 重寫由 Redis 自行觸發(fā)卤橄， BGREWRITEAOF 僅僅用于手動觸發(fā)重寫操作绿满。

127.0.0.1:6379> BGREWRITEAOF

# 即使 Bgrewriteaof 執(zhí)行失敗，也不會有任何數(shù)據(jù)丟失窟扑，因為舊的 AOF 文件在 Bgrewriteaof 成功之前不會被修改喇颁。

Background append only file rewriting started?

合并兩個不同實例的數(shù)據(jù)?

描述: 我們可以利用如下方式進行集群多個主節(jié)點持久化數(shù)據(jù)的合并。

(1) AOF 備份合并: 我們說過它實際上是一些列Redis的命令文本嚎货。

例如橘霎，假設有兩臺 Redis（6379, 6479），它們的AOF文件名分別為(6379.aof, 6479.aof)殖属，現(xiàn)在要將6379的數(shù)據(jù)合并到 6479.aof?

# 首先

cp 6379.aof 6379.aof.bak, cp 6479.aof 6479.aof.bak

# 合并

cat 6379.aof 6479.aof > new.aof

# 檢查&修復

/usr/local/redis/bin/redis-check-aof --fix appendonly.aof

(2) RDB 備份合并: 注意以下方法可能由于服務端版本不同而有些許差異姐叁。

RDB格式如下：頭5個字節(jié)是字符REDIS,之后4個字節(jié)代表版本號，阿里的版本分別是 00 00 00 06,之后2個字節(jié) FE 00，F(xiàn)E是標識 00是數(shù)據(jù)庫外潜，還好我們只有一個庫, 最后的結(jié)尾9個字節(jié) , FF 加上8個字節(jié)的CRC64校驗碼（實在沒空弄谭溉，后來偷了一個懶）

# 1.線上服務使用的阿里云的集群版本redis服務，數(shù)據(jù)量1千萬橡卤，rdb文件4GB,8個rdb文件扮念，每個500MB。

#文件1 大小566346503碧库，截取尾部的9個字節(jié)

dd bs=1 if=src_1.rdb of=1.rdb count=566346494

#文件2 大小570214520柜与，跳過頭部的11個字節(jié)，再截取尾部的9個字節(jié)

dd bs=1 if=src_2.rdb of=2.rdb skip=11 count=570214500

...

#文件8 大小569253061嵌灰，跳過頭部的11個字節(jié)弄匕，再截取尾部的8個字節(jié)，保留FF沽瞭。

dd bs=1 if=src_8.rdb of=8.rdb skip=11 count=569253042

# 2.合并文件(得到備份文件dump.rdb)

cat 1.rdb > dump.rdb

cat 2.rdb >> dump.rdb

...

cat 8.rdb >> dump.rdb

# 3.檢查備份文件(應該會提示沒有crc校驗)

redis-check-rdb dump.rdb

# 4.修改配置文件,因為數(shù)據(jù)庫備份文件里面不包含crc64的校驗碼迁匠，配置文件中關(guān)閉選項。

rdbchecksum no?

Tips : 數(shù)據(jù)恢復到此結(jié)束驹溃，此方法只適合用于臨時恢復和導出數(shù)據(jù)城丧，數(shù)據(jù)完整性不敢保證。

參考地址:?https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format

其它工具:

https://github.com/leonchen83/redis-rdb-cli/?| 一個可以解析, 過濾, 分割, 合并 rdb 離線內(nèi)存分析的工具. 也可以在兩個redis之前同步數(shù)據(jù)并允許用戶自定義同步服務來把redis數(shù)據(jù)同步到其他地方.?

3.混合持久化(redis4.0之后才支持)

重啟 Redis 時豌鹤，我們很少使用 rdb 來恢復內(nèi)存狀態(tài)亡哄，因為會丟失大量數(shù)據(jù)。

如果使用 AOF 日志重放布疙，性能則相對 rdb 來說要慢很多蚊惯，這樣在 Redis 實例很大的情況下，啟動的時候需要花費很長的時間灵临。

Redis 4.0 為了解決這個問題截型，帶來了一個新的持久化選項——混合持久化。

混合持久化同樣也是通過bgrewriteaof完成的儒溉，不同的是當開啟混合持久化時宦焦，fork出的子進程先將共享的內(nèi)存副本全量的以RDB方式寫入aof文件，然后在將aof_rewrite_buf重寫緩沖區(qū)的增量命令以AOF方式寫入到文件睁搭，寫入完成后通知主進程更新統(tǒng)計信息赶诊，并將新的含有RDB格式和AOF格式的AOF文件替換舊的的AOF文件。簡單的說：新的AOF文件前半段是RDB格式的全量數(shù)據(jù)后半段是AOF格式的增量數(shù)據(jù)园骆，如下圖：

在redis重啟的時候舔痪，加載 aof 文件進行恢復數(shù)據(jù)：先加載 rdb 內(nèi)容再加載剩余的 aof。

混合持久化配置：

aof-use-rdb-preamble yes? # yes：開啟锌唾，no：關(guān)閉

RDB和AOF锄码，應該用哪一個夺英？

如果你可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失， 那么你可以只使用 RDB 持久化滋捶。

有很多用戶都只使用 AOF 持久化痛悯， 但我們并不推薦這種方式： 因為定時生成 RDB 快照（snapshot）非常便于進行數(shù)據(jù)庫備份， 并且 RDB 恢復數(shù)據(jù)集的速度也要比 AOF 恢復的速度要快重窟。如果只用AOF持久化载萌，數(shù)據(jù)量很大時，在redis啟動的時候需要花費大量的時間巡扇。

如果你非常關(guān)心你的數(shù)據(jù)扭仁，建議使用 redis 4.0 以后的混合持久化特性。

混合模式配置項

save " "

dbfilename "dump.rdb"

appendonly "yes"

appendfilename "appendonly.aof"

AOF重寫

aof文件里可能有太多“瑣碎”指令厅翔，所以aof會定期根據(jù)內(nèi)存的最新數(shù)據(jù)重新生成aof文件

有兩個配置可以控制aof自動重寫的頻率：

auto-aof-rewrite-min-size? 64mb

#aof文件至少要達到64m才會觸發(fā)制動重寫乖坠，文件太小恢復速度本來就很快，重寫的意義不大

auto-aof-rewrite-percentage? 100

#aof文件上一次重寫后文件大小增長了100%則再次觸發(fā)重寫

appendfsync? ?"everysec"

aof-use-rdb-preamble "yes"

參考：https://www.bilibili.com/read/cv13235983?