前言

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

Redis有兩種持久化方案，一種是快照方式（SNAPSHOTTING）复罐，簡(jiǎn)稱RDB涝登；一種是只追加模式（APPEND ONLY MODE），稱為AOF效诅。接下來(lái)讓我們分別了解一下它們的使用與注意事項(xiàng)胀滚。

RDB

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

圖片

我們先來(lái)扒一下配置文件中的SNAPSHOTTING：

配置文件

save <seconds> <changes>
在給定的秒數(shù)內(nèi)，如果對(duì)數(shù)據(jù)庫(kù)執(zhí)行的寫入操作數(shù)達(dá)到設(shè)定的值剑刑，則將數(shù)據(jù)同步到數(shù)據(jù)文件媳纬。支持多個(gè)條件配合，Redis默認(rèn)配置文件中提供了三個(gè)條件：

save 900 1 //900s內(nèi)有1個(gè)更改
save 300 10 //300s內(nèi)有10個(gè)更改
save 60 10000 //60s內(nèi)有10000次更改

注意： 若不想用RDB方案施掏，可以把 save ""的注釋打開钮惠，上邊三個(gè)注釋掉。

stop-writes-on-bgsave-error yes
當(dāng)bgsave出現(xiàn)錯(cuò)誤時(shí)七芭，Redis是否停止執(zhí)行寫命令素挽；

如果為yes，則當(dāng)硬盤出現(xiàn)問(wèn)題時(shí)狸驳，Redis將停止接受寫入操作预明，這樣我們可以及時(shí)發(fā)現(xiàn)，避免數(shù)據(jù)的大量丟失耙箍；
如果為no撰糠，則Redis無(wú)視bgsave的錯(cuò)誤繼續(xù)執(zhí)行寫命令。
如果已經(jīng)設(shè)置了對(duì)Redis服務(wù)器的正確監(jiān)視和持久性究西，即采用了其他手段發(fā)現(xiàn)和控制數(shù)據(jù)完整性窗慎，可能希望禁用此功能，以便即使在磁盤卤材、權(quán)限等方面出現(xiàn)問(wèn)題時(shí)，Redis仍能正常工作峦失。

注意： 如果后臺(tái)保存過(guò)程將再次開始工作扇丛，Redis將自動(dòng)允許再次寫入。

rdbcompression yes
指定存儲(chǔ)到本地?cái)?shù)據(jù)庫(kù)時(shí)是否壓縮（Redis采用LZF壓縮）數(shù)據(jù)尉辑，默認(rèn)為yes帆精。如果為了節(jié)省CPU時(shí)間，可以關(guān)閉該選項(xiàng)隧魄，但會(huì)導(dǎo)致數(shù)據(jù)庫(kù)文件變得巨大卓练。

rdbchecksum yes

從RDB版本5開始，在存儲(chǔ)快照后购啄，還可以使用CRC64算法來(lái)進(jìn)行數(shù)據(jù)校驗(yàn)襟企，CRC64校驗(yàn)放在文件的末尾。開啟之后狮含，保存和加載RDB文件時(shí)會(huì)增加大約10%的性能消耗顽悼，如果希望獲取到最大的性能提升曼振，可以關(guān)閉此功能。

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

dbfilename dump.rdb

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

大坑請(qǐng)注意：flushall蹄殃、shutdown命令都會(huì)清空并提交至dump.rdb

dir ./
指定本地?cái)?shù)據(jù)庫(kù)存放目錄。

理論

工作方式

• 當(dāng) Redis 需要保存dump.rdb文件時(shí)裆泳，它會(huì)調(diào)用系統(tǒng)函數(shù)fork()祖今，創(chuàng)建一個(gè)子進(jìn)程（與主進(jìn)程完全一致）;

• 子進(jìn)程將數(shù)據(jù)集寫入臨時(shí)文件RDB中；

• 在這里插入圖片描述
  
  

  當(dāng)子進(jìn)程完成對(duì)新 RDB 文件的寫入時(shí)穷遂，Redis 用新 RDB 文件替換原來(lái)的 RDB 文件函匕，并刪除舊的 RDB 文件。
  這種工作方式使得 Redis 可以從寫時(shí)復(fù)制（copy-on-write）機(jī)制中獲益蚪黑。

如何觸發(fā)RDB快照

• 配置文件中默認(rèn)的快照配置盅惜；
• 命令save（阻塞， 只管保存快照忌穿，其他的等待）或者是bgsave（異步）命令抒寂，快照同時(shí)還可以響應(yīng)客戶端命令；
• 執(zhí)行flushall 命令掠剑，清空數(shù)據(jù)庫(kù)所有數(shù)據(jù)屈芜，意義不大;
• 執(zhí)行shutdown 命令，保證服務(wù)器正常關(guān)閉且不丟失任何數(shù)據(jù)朴译，意義也不大井佑。

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

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

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

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

缺點(diǎn)

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

AOF

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

AOF是Append Only File的縮寫，默認(rèn)不開啟份殿。AOF以日志的形式來(lái)記錄每個(gè)寫操作膜钓，只允許追加文件但不可以改寫文件，當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來(lái)恢復(fù)原始的數(shù)據(jù)卿嘲。

我們?cè)賮?lái)看一下配置文件中的APPEND ONLY MODE:

配置文件

appendonly no

默認(rèn)為關(guān)閉狀態(tài)颂斜，改為yes打開持久化。AOF和RDB可以同時(shí)啟用而不會(huì)出現(xiàn)問(wèn)題拾枣。

appendfilename "appendonly.aof"
文件默認(rèn)名稱沃疮，啟動(dòng)即創(chuàng)建。加載先于dump.rdb文件

appendfsync

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

appendfsync always //每次發(fā)生數(shù)據(jù)變更會(huì)被立即記錄到磁盤司蔬，性能較差但數(shù)據(jù)完整性比較好 appendfsync
everysec //默認(rèn)推薦，異步操作凭语，每秒記錄葱她，如果宕機(jī)，有1秒內(nèi)數(shù)據(jù)丟失 appendfsync no
//不同步似扔，只有在操作系統(tǒng)需要時(shí)在刷新數(shù)據(jù)

要想了解接下來(lái)的配置內(nèi)容，先得說(shuō)一下“日志重寫”的原理：

重寫

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

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

重寫原理：

• Redis 執(zhí)行系統(tǒng)函數(shù)fork() 霎苗，創(chuàng)建一個(gè)子進(jìn)程（與主進(jìn)程完全一致）；

• 子進(jìn)程開始將新 AOF 文件的內(nèi)容寫入到臨時(shí)文件榛做；

• 對(duì)于所有新執(zhí)行的寫入命令唁盏，父進(jìn)程一邊將它們累積到一個(gè)內(nèi)存緩存中，一邊將這些改動(dòng)追加到現(xiàn)有 AOF 文件的末尾检眯，這樣即使在重寫的中途發(fā)生停機(jī)厘擂，現(xiàn)有的 AOF 文件也是安全的；

• 當(dāng)子進(jìn)程完成重寫工作時(shí)锰瘸，它給父進(jìn)程發(fā)送一個(gè)信號(hào)刽严，父進(jìn)程在接收到信號(hào)之后，將內(nèi)存緩存中的所有數(shù)據(jù)追加到新 AOF 文件的末尾避凝。

• Redis 原子地用新文件替換舊文件舞萄，之后所有命令都會(huì)直接追加到新 AOF文件的末尾。
  no-appendfsync-on-rewrite no
  當(dāng)我們同時(shí)執(zhí)行主進(jìn)程的寫操作和子進(jìn)程的重寫操作時(shí)恕曲，兩者都會(huì)操作磁盤鹏氧，而重寫往往會(huì)涉及到大量的磁盤操作，這樣就會(huì)造成主進(jìn)程在寫aof文件的時(shí)候出現(xiàn)阻塞的情形佩谣。

為了解決這個(gè)問(wèn)題把还，no-appendfsync-on-rewrite參數(shù)出場(chǎng)了。

• 如果該參數(shù)設(shè)置為no茸俭，是最安全的方式吊履，不會(huì)丟失數(shù)據(jù)，但是要忍受阻塞的問(wèn)題调鬓；
• 如果設(shè)置為yes艇炎，這就相當(dāng)于將appendfsync設(shè)置為no，這說(shuō)明并沒有執(zhí)行磁盤操作腾窝，只是寫入了緩沖區(qū)缀踪。因此這樣并不會(huì)造成阻塞（因?yàn)闆]有競(jìng)爭(zhēng)磁盤），但是如果這個(gè)時(shí)候redis掛掉虹脯，就會(huì)丟失數(shù)據(jù)驴娃。丟失多少數(shù)據(jù)呢？在linux的操作系統(tǒng)的默認(rèn)設(shè)置下循集，最多會(huì)丟失30s的數(shù)據(jù)唇敞。
  因此，如果應(yīng)用系統(tǒng)無(wú)法忍受延遲，而可以容忍少量的數(shù)據(jù)丟失疆柔，則設(shè)置為yes咒精；如果應(yīng)用系統(tǒng)無(wú)法忍受數(shù)據(jù)丟失，則設(shè)置為no旷档。

auto-aof-rewrite-percentage 100

重寫百分比模叙，默認(rèn)為上次重寫后aof文件大小的一倍。

auto-aof-rewrite-min-size 64mb

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

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

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

aof-load-truncated yes

當(dāng)AOF文件被截?cái)鄷r(shí)湖蜕，即AOF文件的最后命令不完整，如果此時(shí)啟動(dòng)Redis宋列，會(huì)將AOF數(shù)據(jù)加載回內(nèi)存昭抒，此時(shí)便會(huì)出現(xiàn)問(wèn)題。

• yes：加載一個(gè)截?cái)嗟腁OF炼杖，Redis服務(wù)器開始發(fā)出日志灭返，通知用戶該事件；

• no：服務(wù)器將中止并出現(xiàn)錯(cuò)誤坤邪，拒絕啟動(dòng)熙含。
  當(dāng)我們得知AOF文件報(bào)錯(cuò)時(shí)，可以用以下方法來(lái)修復(fù)出錯(cuò)的 AOF 文件：

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

• 使用 Redis 附帶的 redis-check-aof 命令怎静，對(duì)原來(lái)的AOF文件進(jìn)行修復(fù)；

• redis-check-aof –fix

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

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

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

aof-use-rdb-preamble yes

在重寫AOF文件時(shí)侣签，Redis能夠在AOF文件中使用RDB前導(dǎo)塘装，以加快重寫和恢復(fù)速度。啟用此選項(xiàng)后影所，重寫的AOF文件由兩個(gè)不同的節(jié)組成：RDB file氢哮、AOF tail

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

理論

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

• 數(shù)據(jù)的完整性和一致性更高胀溺，AOF的持久化通過(guò)使用不同的策略裂七，最多丟失1秒的數(shù)據(jù)；
• AOF文件是一個(gè)只進(jìn)行追加的日志文件仓坞，不需要寫入seek背零；
• Redis可以在 AOF文件體積變得過(guò)大時(shí)，自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫无埃，重寫操作是絕對(duì)安全的徙瓶；
• AOF文件記錄的寫入操作以Redis協(xié)議的格式保存，容易讀懂嫉称，容易對(duì)文件進(jìn)行分析侦镇；

缺點(diǎn)

• 對(duì)于相同的數(shù)據(jù)集來(lái)說(shuō)，AOF文件的體積通常要大于RDB文件的體積织阅；
• 根據(jù)所使用的 fsync 策略壳繁，AOF的速度可能會(huì)慢于RDB 。
  在一般情況下荔棉，每秒 fsync 的性能依然非常高闹炉，而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負(fù)荷之下也是如此润樱。不過(guò)在處理巨大的寫入載入時(shí)渣触，RDB 可以提供更有保證的最大延遲時(shí)間（latency）。

對(duì)比與總結(jié)

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

一般來(lái)說(shuō)嗅钻，如果想達(dá)到足以媲美 PostgreSQL 的數(shù)據(jù)安全性，應(yīng)該同時(shí)使用兩種持久化功能舌稀。

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

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

有很多用戶都只使用AOF持久化语御，但我們并不推薦這種方式：因?yàn)槎〞r(shí)生成 RDB 快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫(kù)備份，并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度要快席怪。

AOF和RDB之間的相互作用

在版本號(hào)大于等于 2.4 的 Redis 中应闯，BGSAVE 執(zhí)行的過(guò)程中，不可以執(zhí)行 BGREWRITEAOF 挂捻。反過(guò)來(lái)說(shuō)碉纺，在 BGREWRITEAOF 執(zhí)行的過(guò)程中，也不可以執(zhí)行 BGSAVE。這可以防止兩個(gè) Redis 后臺(tái)進(jìn)程同時(shí)對(duì)磁盤進(jìn)行大量的I/O 操作骨田。

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

當(dāng) Redis 啟動(dòng)時(shí)悠汽，如果 RDB持久化和 AOF 持久化都被打開了箱吕， 那么程序會(huì)優(yōu)先使用 AOF 文件來(lái)恢復(fù)數(shù)據(jù)集，因?yàn)?AOF文件所保存的數(shù)據(jù)通常是最完整的柿冲。

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

• 創(chuàng)建一個(gè)定期任務(wù)（cron job）茬高，每小時(shí)將一個(gè) RDB 文件備份到一個(gè)文件夾，并且每天將一個(gè) RDB 文件備份到另一個(gè)文件夾姻采；
• 確毖挪桑快照的備份都帶有相應(yīng)的日期和時(shí)間信息，每次執(zhí)行定期任務(wù)腳本時(shí)慨亲，使用 find 命令來(lái)刪除過(guò)期的快照婚瓜；
  至少每天一次，將 RDB 備份到你的數(shù)據(jù)中心之外刑棵，或者至少是備份到你運(yùn)行 Redis 服務(wù)器的物理機(jī)器之外巴刻。

性能建議

在實(shí)際應(yīng)用時(shí)，因?yàn)镽DB文件只用作后備用途蛉签，建議只在slave上持久化RDB文件胡陪，而且只需要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則碍舍。

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

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

如果不開啟AOF，僅靠Master-Slave Replication實(shí)現(xiàn)高可用性也可以舆吮。能省掉一大筆IO揭朝，也減少了rewrite時(shí)帶來(lái)的系統(tǒng)波動(dòng)队贱。代價(jià)是如果Master/Slave同時(shí)倒掉，會(huì)丟失十幾分鐘的數(shù)據(jù)萝勤，啟動(dòng)腳本也要比較兩個(gè)Master/Slave中的RDB文件露筒，載入較新的那個(gè)。

最后

阿里敌卓、螞蟻、京東等大廠面試題.jpg

注：工種浩：程序媛小琬