面試官：你說你精通Redis，你看過持久化的配置嗎？

前邊我們已經(jīng)介紹了Redis五種數(shù)據(jù)類型的命令與配置文件的基本配置，今天讓我們從理論和配置兩個層面來揭開Redis持久化的神秘面紗。

所謂持久化可以簡單理解為將內(nèi)存中的數(shù)據(jù)保存到硬盤上存儲的過程。持久化之后的數(shù)據(jù)在系統(tǒng)重啟或者宕機之后依然可以進行訪問，保證了數(shù)據(jù)的安全性。

Redis有兩種持久化方案，一種是快照方式（SNAPSHOTTING），簡稱RDB；一種是只追加模式（APPEND ONLY MODE），稱為AOF。接下來讓我們分別了解一下它們的使用與注意事項。

RDB

RDB為Redis DataBase的縮寫，是 Redis 默認的持久化方案。它能夠在指定的時間間隔內(nèi)將內(nèi)存數(shù)據(jù)集快照（snapshot）寫入磁盤，恢復(fù)時將快照文件（ dump.rdb ）讀回內(nèi)存。

我們先來扒一下配置文件中的SNAPSHOTTING:

配置文件

save ?

在給定的秒數(shù)內(nèi)，如果對數(shù)據(jù)庫執(zhí)行的寫入操作數(shù)達到設(shè)定的值，則將數(shù)據(jù)同步到數(shù)據(jù)文件。支持多個條件配合，Redis默認配置文件中提供了三個條件：

save?900?1?//900s內(nèi)有1個更改
save?300?10?//300s內(nèi)有10個更改
save?60?10000?//60s內(nèi)有10000次更改
注意：若不想用RDB方案，可以把 save ""的注釋打開，上邊三個注釋掉。

stop-writes-on-bgsave-error yes

當bgsave出現(xiàn)錯誤時，Redis是否停止執(zhí)行寫命令；

• 如果為yes，則當硬盤出現(xiàn)問題時，Redis將停止接受寫入操作，這樣我們可以及時發(fā)現(xiàn)，避免數(shù)據(jù)的大量丟失；
• 如果為no，則Redis無視bgsave的錯誤繼續(xù)執(zhí)行寫命令。

如果已經(jīng)設(shè)置了對Redis服務(wù)器的正確監(jiān)視和持久性，即采用了其他手段發(fā)現(xiàn)和控制數(shù)據(jù)完整性，可能希望禁用此功能，以便即使在磁盤、權(quán)限等方面出現(xiàn)問題時，Redis仍能正常工作。

注意：如果后臺保存過程將再次開始工作，Redis將自動允許再次寫入。

rdbcompression yes

指定存儲到本地數(shù)據(jù)庫時是否壓縮（Redis采用LZF壓縮）數(shù)據(jù)，默認為yes。如果為了節(jié)省CPU時間，可以關(guān)閉該選項，但會導(dǎo)致數(shù)據(jù)庫文件變得巨大。

rdbchecksum yes

從RDB版本5開始，在存儲快照后，還可以使用CRC64算法來進行數(shù)據(jù)校驗，CRC64校驗放在文件的末尾。開啟之后，保存和加載RDB文件時會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能。

禁用校驗和創(chuàng)建的RDB文件的校驗和為零，這將告訴加載代碼跳過檢查。

dbfilename dump.rdb

指定本地數(shù)據(jù)庫文件名，重啟之后自動加載進內(nèi)存，手動執(zhí)行save 命令的話即刻生效。

大坑請注意：flushall、shutdown命令都會清空并提交至dump.rdb

dir ./

指定本地數(shù)據(jù)庫存放目錄。

理論

工作方式

• 當 Redis 需要保存dump.rdb文件時，它會調(diào)用系統(tǒng)函數(shù)fork()，創(chuàng)建一個子進程（與主進程完全一致）;
• 子進程將數(shù)據(jù)集寫入臨時文件RDB中；
• 當子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫時復(fù)制（copy-on-write）機制中獲益。

如何觸發(fā)RDB快照

1. 配置文件中默認的快照配置；
2. 命令save（阻塞， 只管保存快照，其他的等待）或者是bgsave（異步）命令，快照同時還可以響應(yīng)客戶端命令；
3. 執(zhí)行flushall 命令，清空數(shù)據(jù)庫所有數(shù)據(jù)，意義不大;
4. 執(zhí)行shutdown 命令，保證服務(wù)器正常關(guān)閉且不丟失任何數(shù)據(jù)，意義也不大。

通過RDB文件恢復(fù)數(shù)據(jù)

在實際開發(fā)中，一般會考慮到物理機硬盤損壞的情況，所以我們會選擇備份dump.rdb文件。將備份的dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啟redis服務(wù)即可。

優(yōu)點

• RDB是一個非常緊湊的文件，非常適用于數(shù)據(jù)集的備份；
• RDB是一個緊湊的單一文件，很方便傳送到另一個遠端數(shù)據(jù)中心或者亞馬遜的S3（可能加密），非常適用于災(zāi)難恢復(fù)；
• Redis的主進程不進行I/O操作，確保了極高的性能；
• 適合大規(guī)模數(shù)據(jù)的恢復(fù)，對于數(shù)據(jù)的完整性和一致性要求不高的話，RDB比AOF方式更加高效。

缺點

• 在Redis意外宕機時，你可能會丟失幾分鐘的數(shù)據(jù)；
• RDB 需要經(jīng)常fork子進程來保存數(shù)據(jù)集到硬盤上，當數(shù)據(jù)集比較大的時候，fork的過程是非常耗時的，可能會導(dǎo)致Redis在一些毫秒級內(nèi)不能響應(yīng)客戶端的請求。如果數(shù)據(jù)集巨大并且CPU性能不是很好的情況下，這種情況會持續(xù)1秒；AOF也需要fork，但是可以調(diào)節(jié)重寫日志文件的頻率來提高數(shù)據(jù)集的耐久度。

AOF

為了解決RDB方式在宕機時丟失數(shù)據(jù)過多的問題，從1.1 版本開始，Redis增加了一種durable的持久化方式：AOF。

AOF是Append Only File的縮寫，默認不開啟。AOF以日志的形式來記錄每個寫操作，只允許追加文件但不可以改寫文件，當服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)。

我們再來看一下配置文件中的APPEND ONLY MODE:

配置文件

appendonly no

默認為關(guān)閉狀態(tài)，改為yes打開持久化。AOF和RDB可以同時啟用而不會出現(xiàn)問題。

appendfilename "appendonly.aof"

文件默認名稱，啟動即創(chuàng)建。加載先于dump.rdb文件

appendfsync

同步策略：系統(tǒng)函數(shù)fsync() 告訴操作系統(tǒng)在磁盤上實際寫入數(shù)據(jù)。Redis支持三種不同的模式

appendfsync?always?//每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤，性能較差但數(shù)據(jù)完整性比較好
appendfsync?everysec?//默認推薦，異步操作，每秒記錄，如果宕機，有1秒內(nèi)數(shù)據(jù)丟失
appendfsync?no?//不同步，只有在操作系統(tǒng)需要時在刷新數(shù)據(jù)
要想了解接下來的配置內(nèi)容，先得說一下“日志重寫”的原理：

重寫

由于AOF采用的是將命令追加到文件末尾的方式，所以隨著寫入命令的不斷增加，AOF文件的體積會變得越來越大。為避免出現(xiàn)此種情況，新增了重寫機制：可以在不打斷服務(wù)客戶端的情況下，對AOF文件進行重建（rebuild）。

重寫觸發(fā)： 通過執(zhí)行bgrewriteaof命令，可以生成一個新的AOF文件，該文件包含重建當前數(shù)據(jù)集所需的最少命令。Redis 2.2需手動執(zhí)行該命令，Redis 2.4則可以通過修改配置文件的方式自動觸發(fā)（配置在下邊涉及）。

重寫原理：

• Redis 執(zhí)行系統(tǒng)函數(shù)fork() ，創(chuàng)建一個子進程（與主進程完全一致）；
• 子進程開始將新 AOF 文件的內(nèi)容寫入到臨時文件；
• 對于所有新執(zhí)行的寫入命令，父進程一邊將它們累積到一個內(nèi)存緩存中，一邊將這些改動追加到現(xiàn)有 AOF 文件的末尾，這樣即使在重寫的中途發(fā)生停機，現(xiàn)有的 AOF 文件也是安全的；
• 當子進程完成重寫工作時，它給父進程發(fā)送一個信號，父進程在接收到信號之后，將內(nèi)存緩存中的所有數(shù)據(jù)追加到新 AOF 文件的末尾。
• Redis 原子地用新文件替換舊文件，之后所有命令都會直接追加到新 AOF文件的末尾。

no-appendfsync-on-rewrite no

當我們同時執(zhí)行主進程的寫操作和子進程的重寫操作時，兩者都會操作磁盤，而重寫往往會涉及到大量的磁盤操作，這樣就會造成主進程在寫aof文件的時候出現(xiàn)阻塞的情形。

為了解決這個問題，no-appendfsync-on-rewrite參數(shù)出場了。

• 如果該參數(shù)設(shè)置為no，是最安全的方式，不會丟失數(shù)據(jù)，但是要忍受阻塞的問題；
• 如果設(shè)置為yes，這就相當于將appendfsync設(shè)置為no，這說明并沒有執(zhí)行磁盤操作，只是寫入了緩沖區(qū)。因此這樣并不會造成阻塞（因為沒有競爭磁盤），但是如果這個時候redis掛掉，就會丟失數(shù)據(jù)。丟失多少數(shù)據(jù)呢？在linux的操作系統(tǒng)的默認設(shè)置下，最多會丟失30s的數(shù)據(jù)。

因此，如果應(yīng)用系統(tǒng)無法忍受延遲，而可以容忍少量的數(shù)據(jù)丟失，則設(shè)置為yes；如果應(yīng)用系統(tǒng)無法忍受數(shù)據(jù)丟失，則設(shè)置為no。

auto-aof-rewrite-percentage 100

重寫百分比，默認為上次重寫后aof文件大小的一倍。

auto-aof-rewrite-min-size 64mb

重寫觸發(fā)的最小值：64mb。

根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動觸發(fā)時機。Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。

大型互聯(lián)網(wǎng)公司一般都是3G起步

aof-load-truncated yes

當AOF文件被截斷時，即AOF文件的最后命令不完整，如果此時啟動Redis，會將AOF數(shù)據(jù)加載回內(nèi)存，此時便會出現(xiàn)問題。

• yes：加載一個截斷的AOF，Redis服務(wù)器開始發(fā)出日志，通知用戶該事件；
• no：服務(wù)器將中止并出現(xiàn)錯誤，拒絕啟動。

當我們得知AOF文件報錯時，可以用以下方法來修復(fù)出錯的 AOF 文件：

• 為現(xiàn)有的 AOF文件創(chuàng)建一個備份；

• 使用 Redis 附帶的 redis-check-aof 命令，對原來的AOF文件進行修復(fù)；

• redis-check-aof –fix

• redis-check-aof --fix appendonly.aof ?修復(fù)命令，殺光不符合規(guī)范的語法

• （可選）使用 diff -u 對比修復(fù)后的 AOF文件和原始 AOF 文件的備份，查看兩個文件之間的不同之處；

• 重啟 Redis服務(wù)器，等待服務(wù)器載入修復(fù)后的 AOF文件，并進行數(shù)據(jù)恢復(fù)。

aof-use-rdb-preamble yes

在重寫AOF文件時，Redis能夠在AOF文件中使用RDB前導(dǎo)，以加快重寫和恢復(fù)速度。啟用此選項后，重寫的AOF文件由兩個不同的節(jié)組成：RDB file、AOF tail

加載Redis時，會識別AOF文件以Redis字符串開頭，并加載帶前綴的RDB文件，然后繼續(xù)加載AOF尾部。

理論

優(yōu)點

• 數(shù)據(jù)的完整性和一致性更高，AOF的持久化通過使用不同的策略，最多丟失1秒的數(shù)據(jù)；
• AOF文件是一個只進行追加的日志文件，不需要寫入seek；
• Redis可以在 AOF文件體積變得過大時，自動地在后臺對 AOF 進行重寫，重寫操作是絕對安全的；
• AOF文件記錄的寫入操作以Redis協(xié)議的格式保存，容易讀懂，容易對文件進行分析；

缺點

• 對于相同的數(shù)據(jù)集來說，AOF文件的體積通常要大于RDB文件的體積；
• 根據(jù)所使用的 fsync 策略，AOF的速度可能會慢于RDB 。

在一般情況下，每秒 fsync 的性能依然非常高，而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

對比與總結(jié)

如何選擇使用哪種持久化方式？

一般來說，如果想達到足以媲美 PostgreSQL 的數(shù)據(jù)安全性，應(yīng)該同時使用兩種持久化功能。

如果非常關(guān)心數(shù)據(jù)，但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，那么可以只使用 RDB 持久化。

由于AOF持久化的實時性更好，即當進程意外退出時丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式。

有很多用戶都只使用AOF持久化，但我們并不推薦這種方式：因為定時生成 RDB 快照（snapshot）非常便于進行數(shù)據(jù)庫備份，并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度要快。

AOF和RDB之間的相互作用

在版本號大于等于 2.4 的 Redis 中，BGSAVE 執(zhí)行的過程中，不可以執(zhí)行 BGREWRITEAOF 。反過來說，在 BGREWRITEAOF 執(zhí)行的過程中，也不可以執(zhí)行 BGSAVE。這可以防止兩個 Redis 后臺進程同時對磁盤進行大量的I/O 操作。

如果 BGSAVE 正在執(zhí)行，并且用戶顯示地調(diào)用 BGREWRITEAOF 命令，那么服務(wù)器將向用戶回復(fù)一個 OK 狀態(tài)， 并告知用戶BGREWRITEAOF 已經(jīng)被預(yù)定執(zhí)行：一旦 BGSAVE 執(zhí)行完畢，BGREWRITEAOF就會正式開始。

當 Redis 啟動時，如果 RDB持久化和 AOF 持久化都被打開了， 那么程序會優(yōu)先使用 AOF 文件來恢復(fù)數(shù)據(jù)集，因為 AOF文件所保存的數(shù)據(jù)通常是最完整的。

備份redis數(shù)據(jù)

• 創(chuàng)建一個定期任務(wù)（cron job），每小時將一個 RDB 文件備份到一個文件夾，并且每天將一個 RDB 文件備份到另一個文件夾；
• 確?？煺盏膫浞荻紟в邢鄳?yīng)的日期和時間信息，每次執(zhí)行定期任務(wù)腳本時，使用 find 命令來刪除過期的快照；
• 至少每天一次，將 RDB 備份到你的數(shù)據(jù)中心之外，或者至少是備份到你運行 Redis 服務(wù)器的物理機器之外。

性能建議

在實際應(yīng)用時，因為RDB文件只用作后備用途，建議只在slave上持久化RDB文件，而且只需要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則。

如果開啟AOF，好處是在最惡劣情況下也只會丟失不超過2秒數(shù)據(jù)，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續(xù)的IO，二是AOF rewrite的最后將rewrite過程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。

只要硬盤許可，應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基礎(chǔ)大小默認值64M太小了，可以設(shè)置到5G以上。默認超過原大小的100%時重寫可以改到適當?shù)臄?shù)值。

如果不開啟AOF，僅靠Master-Slave Replication實現(xiàn)高可用性也可以。能省掉一大筆IO，也減少了rewrite時帶來的系統(tǒng)波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數(shù)據(jù)，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。