前言

緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項目中被廣泛使用。在讀取持久化，數(shù)據(jù)備份，數(shù)據(jù)的故障恢復方面你究竟了解多少呢?

1.redis持久化的意義----redis故障恢復

在實際的生產(chǎn)環(huán)境中，很可能會遇到redis突然掛掉的情況，比如redis的進程死掉了、電纜被施工隊挖了(支付寶例子)等等，總之一定會遇到各種奇葩的現(xiàn)象導致redis死掉，這時候放在redis內(nèi)存中的數(shù)據(jù)就會全部丟失，這些數(shù)據(jù)可能服務很多的系統(tǒng)或者服務，當然，我們可以重新啟動redis，重啟之后，如果redis沒有持久化，redis中的數(shù)據(jù)就會全部丟失。

[[252437]]

如果通過持久化將數(shù)據(jù)搞一份到磁盤，然后定期的同步和備份到云存儲服務上去，那么就可以保證數(shù)據(jù)不會全部丟失，還是可以恢復一部分數(shù)據(jù)的。

2.持久化的兩大機制(RDB和AOF)

RDB：對redis數(shù)據(jù)執(zhí)行周期性的持久化

AOF:將每條命令寫入日志，以append-only的模式寫入一個日志文件中，在redis重啟的時候，可以通過回放AOF的寫入指令來重新構(gòu)建整個數(shù)據(jù)集

是否實用持久化要看具體的業(yè)務場景：

如果只是想讓redis僅僅作為純內(nèi)存的緩存，那么可以禁止RDB和AOF。

故障恢復大致思路：

通過RDB或AOF，都可以將redis內(nèi)存中的數(shù)據(jù)持久化到磁盤上來，然后可以將數(shù)據(jù)備份到阿里云，如果redis掛了，服務器中內(nèi)存和磁盤的數(shù)據(jù)就都丟了，這時候可以將阿里云中的備份文件拷貝至指定目錄下，然后重啟redis，redis就會自動根據(jù)持久化數(shù)據(jù)文件去恢復內(nèi)存中的數(shù)據(jù)，繼續(xù)對外提供服務。如果同時室友了RDB和AOF兩種持久化機制，那么在重啟的時間建議使用AOF的方式重新構(gòu)建數(shù)據(jù)，因為AOF中的數(shù)據(jù)更加完整。

3.剖析RDB和AOF

RDB：早上7點，這個時候redis 中有500條數(shù)據(jù)，這個時候redis會在一定周期內(nèi)生成一個RDB快照文件，等到了9點的時候redis中有8000條數(shù)據(jù)，這個時候又在一定的周期內(nèi)生成了另一個RDB快照文件，這就是RDB持久化機制。

AOF：redis 中每寫入一條指令，就會把這條指令更新到磁盤中的文件中。然而在現(xiàn)代操作系統(tǒng)中，寫文件不是直接寫磁盤，會先寫進os cache，然后在一定時間內(nèi)再從os cache刷入disk file，對于AOF來說每隔一秒(可配置)調(diào)用一次操作系統(tǒng)餓fsync操作強制將os cache中的數(shù)據(jù)刷入磁盤文件中。但是redis內(nèi)存中的數(shù)據(jù)也不是***增長的，它是定期的根據(jù)LRU算法清理一些不常用的數(shù)據(jù)，這樣才能保證AOF不會***增長，但是如果LRU的清理速度比不上AOF的膨脹速度的時候，這時候當AOF大到一定程度就會進行AOF rewrite操作。AOF rewrite操作就會基于當時redis內(nèi)存中的數(shù)據(jù)來重新構(gòu)造一個更小的AOF文件，然后將舊的AOF文件刪除。

簡單的說，假設redis限定了只能存放10G數(shù)據(jù)，這時候不斷的在redis中寫入數(shù)據(jù)，當達到了10G的數(shù)據(jù)量的時候，這時候根據(jù)LRU清理了一些不常用的數(shù)據(jù)，清理了5G，這時候又寫了5G，這時候AOF文件記錄了15G的數(shù)據(jù)相關(guān)的寫入指令，假如這個時候AOF已經(jīng)膨脹了，這個時候redis進行AOF rewrite操作，重新生成了一個新的10G的數(shù)據(jù)指令的AOF文件，這個時候?qū)⒗^續(xù)寫入新的AOF文件，將老的AOF文件刪除。

4.RDB和AOF優(yōu)缺點

RDB優(yōu)點

(1).RDB會生成多個數(shù)據(jù)文件，每個數(shù)據(jù)文件都代表了某一個時刻中redis的數(shù)據(jù)，這種多個數(shù)據(jù)文件的方式，非常適合做冷備，可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠程的安全存儲上去，比如阿里云的ODPS分布式存儲上，以預定好的備份策略來定期備份redis中的數(shù)據(jù)。

RDB做冷備，生成多個文件，每個文件都代表了某一個時刻的完整的數(shù)據(jù)快照

AOF也可以做冷備，只有一個文件，但是你可以，每隔一定時間，去copy一份這個文件出來

但是RDB更適合做冷備，它的優(yōu)勢是由redis去控制固定時長生成快照文件的事情，比較方便; AOF，還需要自己寫一些腳本去做這個事情，需要自己寫定時腳本，而且RDB數(shù)據(jù)做冷備，在最壞的情況下，提供數(shù)據(jù)恢復的時候，速度比AOF快

(2).RDB對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高性能，因為redis主進程只需要fork一個子進程，讓子進程執(zhí)行磁盤IO操作來進行RDB持久化即可

RDB，每次寫，都是直接寫redis內(nèi)存，只是在一定的時候，才會將數(shù)據(jù)寫入磁盤中

AOF，每次都是要寫文件的，雖然可以快速寫入os cache中，但是還是有一定的時間開銷的,速度肯定比RDB略慢一些

(3).相對于AOF持久化機制來說，直接基于RDB數(shù)據(jù)文件來重啟和恢復redis進程，更加快速

RDB缺點

(1).如果想要在redis故障時，盡可能少的丟失數(shù)據(jù)，那么RDB沒有AOF好。一般來說，RDB數(shù)據(jù)快照文件，都是每隔5分鐘，或者更長時間生成一次，這個時候就得接受一旦redis進程宕機，那么會丟失最近5分鐘的數(shù)據(jù)，這也是rdb***的缺點，就是不適合做***優(yōu)先的恢復方案，如果你依賴RDB做***優(yōu)先恢復方案，會導致數(shù)據(jù)丟失的比較多。

(2).RDB每次在fork子進程來執(zhí)行RDB快照數(shù)據(jù)文件生成的時候，如果數(shù)據(jù)文件特別大，可能會導致對客戶端提供的服務暫停數(shù)毫秒，或者甚至數(shù)秒，所以一般不要讓RDB的間隔太長，否則每次生成的RDB文件太大了，對redis本身的性能可能會有影響的

AOF優(yōu)點

(1).AOF可以更好的保護數(shù)據(jù)不丟失，一般AOF會每隔1秒，通過一個后臺線程執(zhí)行一次fsync操作，最多丟失1秒鐘的數(shù)據(jù),每隔1秒，就執(zhí)行一次fsync操作，保證os cache中的數(shù)據(jù)寫入磁盤中，redis進程掛了，最多丟掉1秒鐘的數(shù)據(jù)。

(2).AOF日志文件以append-only模式寫入，所以沒有任何磁盤尋址的開銷，寫入性能非常高，而且文件不容易破損，即使文件尾部破損，也很容易修復。

(3).AOF日志文件即使過大的時候，出現(xiàn)后臺重寫操作，也不會影響客戶端的讀寫。因為在rewrite log的時候，會對其中的內(nèi)容進行壓縮，創(chuàng)建出一份需要恢復數(shù)據(jù)的最小日志出來。再創(chuàng)建新日志文件的時候，老的日志文件還是照常寫入。當新的merge后的日志文件ready的時候，再交換新老日志文件即可。

(4).AOF日志文件的命令通過可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個時候后臺rewrite還沒有發(fā)生，那么就可以立即拷貝AOF文件，將***一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數(shù)據(jù)

AOF缺點

(1).對于同一份數(shù)據(jù)來說，AOF日志文件通常比RDB數(shù)據(jù)快照文件更大

(2).AOF開啟后，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般會配置成每秒fsync一次日志文件，當然，每秒一次fsync，性能也還是很高的，如果你要保證一條數(shù)據(jù)都不丟，也是可以的，AOF的fsync設置成沒寫入一條數(shù)據(jù)，fsync一次，那就完蛋了，redis的QPS大降。

(3).以前AOF發(fā)生過bug，就是通過AOF記錄的日志，進行數(shù)據(jù)恢復的時候，沒有恢復一模一樣的數(shù)據(jù)出來。所以說，類似AOF這種較為復雜的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的數(shù)據(jù)快照文件的方式，更加脆弱一些，容易有bug。不過AOF就是為了避免rewrite過程導致的bug，因此每次rewrite并不是基于舊的指令日志進行merge的，而是基于當時內(nèi)存中的數(shù)據(jù)進行指令的重新構(gòu)建，這樣健壯性會好很多。

(4).唯一的比較大的缺點，其實就是做數(shù)據(jù)恢復的時候，會比較慢，還有做冷備，定期的備份，不太方便，可能要自己手寫復雜的腳本去做，做冷備不太合適

AOF和RDB數(shù)據(jù)恢復機制

AOF，存放的指令日志，做數(shù)據(jù)恢復的時候，其實是要回放和執(zhí)行所有的指令日志，來恢復出來內(nèi)存中的所有數(shù)據(jù)的

RDB，就是一份數(shù)據(jù)文件，恢復的時候，直接加載到內(nèi)存中即可

無論是AOF和RDB，在redis中都以一個文件的形式存在!!!

5.RDB和AOF如何選擇

(1).不要僅僅使用RDB，因為那樣會導致你丟失很多數(shù)據(jù)

(2).也不要僅僅使用AOF，因為那樣有兩個問題，***，你通過AOF做冷備，沒有RDB做冷備，來的恢復速度更快; 第二，RDB每次簡單粗暴生成數(shù)據(jù)快照，更加健壯，可以避免AOF這種復雜的備份和恢復機制的bug

(3).綜合使用AOF和RDB兩種持久化機制，用AOF來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復的***選擇; 用RDB來做不同程度的冷備，在AOF文件都丟失或損壞不可用的時候，還可以使用RDB來進行快速的數(shù)據(jù)恢復

6.如何配置RDB持久化

(1).redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化

例如：save 60 1000

(每隔60s，如果有超過1000個key發(fā)生了變更，那么就生成一個新的dump.rdb文件，就是當前redis內(nèi)存中完整的數(shù)據(jù)快照，這個操作也被稱之為snapshotting，快照

也可以手動調(diào)用save或者bgsave命令，同步或異步執(zhí)行rdb快照生成)

(2).save可以設置多個，就是多個snapshotting檢查點，每到一個檢查點，就會去check一下，是否有指定的key數(shù)量發(fā)生了變更，如果有，就生成一個新的dump.rdb文件

7.RDB持久化機制的工作流程

(1).redis根據(jù)配置自己嘗試去生成rdb快照文件，fork一個子進程出來，子進程嘗試將數(shù)據(jù)dump到臨時的rdb快照文件中，完成rdb快照文件的生成之后，就替換之前的舊的快照文件，dump.rdb，每次生成一個新的快照，都會覆蓋之前的老快照。

8.基于RDB持久化機制的數(shù)據(jù)恢復實驗

(1).在redis中保存幾條數(shù)據(jù)，立即停掉redis進程，然后重啟redis，看看剛才插入的數(shù)據(jù)還在不在

(2).在redis中再保存幾條新的數(shù)據(jù)，用kill -9粗暴殺死redis進程，模擬redis故障異常退出，導致內(nèi)存數(shù)據(jù)丟失的場景

注意：通過redis-cli SHUTDOWN這種方式去停掉redis，其實是一種安全退出的模式，redis在退出的時候會將內(nèi)存中的數(shù)據(jù)立即生成一份完整的rdb快照

9.如何配置AOF持久化

(1).AOF持久化，默認是關(guān)閉的，默認是打開RDB持久化

(2).appendonly yes，可以打開AOF持久化機制，在生產(chǎn)環(huán)境里面，一般來說AOF都是要打開的，除非你說隨便丟個幾分鐘的數(shù)據(jù)也無所謂，打開AOF持久化機制之后，redis每次接收到一條寫命令，就會寫入日志文件中，當然是先寫入os cache的，然后每隔一定時間再fsync一下，而且即使AOF和RDB都開啟了，redis重啟的時候，也是優(yōu)先通過AOF進行數(shù)據(jù)恢復的，因為aof數(shù)據(jù)比較完整

(3).可以配置AOF的fsync策略，有三種策略可以選擇，一種是每次寫入一條數(shù)據(jù)就執(zhí)行一次fsync; 一種是每隔一秒執(zhí)行一次fsync; 一種是不主動執(zhí)行fsync

always: 每次寫入一條數(shù)據(jù)，立即將這個數(shù)據(jù)對應的寫日志fsync到磁盤上去，性能非常非常差，吞吐量很低; 確保說redis里的數(shù)據(jù)一條都不丟，那就只能這樣了

everysec: 每秒將os cache中的數(shù)據(jù)fsync到磁盤，這個最常用的，生產(chǎn)環(huán)境一般都這么配置，性能很高，QPS還是可以上萬的

no: 僅僅redis負責將數(shù)據(jù)寫入os cache就撒手不管了，然后后面os自己會時不時有自己的策略將數(shù)據(jù)刷入磁盤，不可控了

10.AOF持久化的數(shù)據(jù)恢復實驗

(1).先僅僅打開RDB，寫入一些數(shù)據(jù)，然后kill -9殺掉redis進程，接著重啟redis，發(fā)現(xiàn)數(shù)據(jù)沒了，因為RDB快照還沒生成

(2).打開AOF的開關(guān)，啟用AOF持久化

(3).寫入一些數(shù)據(jù)，觀察AOF文件中的日志內(nèi)容

(4).kill -9殺掉redis進程，重新啟動redis進程，發(fā)現(xiàn)數(shù)據(jù)被恢復回來了，就是從AOF文件中恢復回來的(redis進程啟動的時候，直接就會從appendonly.aof中加載所有的日志，把內(nèi)存中的數(shù)據(jù)恢復回來)

注意：在appendonly.aof文件中，可以看到剛寫的日志，它們其實就是先寫入os cache的，然后1秒后才fsync到磁盤中，只有fsync到磁盤中了，才是安全的，要不然光是在os cache中，機器只要重啟，就什么都沒了

11.AOF rewrite

AOF工作原理

(1).redis fork一個子進程

(2).子進程基于當前內(nèi)存中的數(shù)據(jù)，構(gòu)建日志，開始往一個新的臨時的AOF文件中寫入日志

(3).redis主進程，接收到client新的寫操作之后，在內(nèi)存中的數(shù)據(jù)繼續(xù)寫入新日志到AOF文件中，同時新的數(shù)據(jù)也繼續(xù)寫入舊的AOF文件

(4).redis主進程將內(nèi)存中的新寫進去的日志再次追加到新的AOF文件中

(5).用新的日志文件替換掉舊的日志文件

redis中的數(shù)據(jù)其實有限的，很多數(shù)據(jù)可能會自動過期，可能會被用戶刪除，可能會被redis用緩存清除的算法清理掉，redis中的數(shù)據(jù)會不斷淘汰掉舊的，就一部分常用的數(shù)據(jù)會被自動保留在redis內(nèi)存中，所以可能很多之前的已經(jīng)被清理掉的數(shù)據(jù)，對應的寫日志還停留在AOF中，AOF日志文件就一個，會不斷的膨脹，到很大很大，所以AOF會自動在后臺每隔一定時間做rewrite操作，比如日志里已經(jīng)存放了針對100w數(shù)據(jù)的寫日志了; redis內(nèi)存只剩下10萬; 基于內(nèi)存中當前的10萬數(shù)據(jù)構(gòu)建一套***的日志，到AOF中; 覆蓋之前的老日志; 確保AOF日志文件不會過大，保持跟redis內(nèi)存數(shù)據(jù)量一致

redis 2.4之前，還需要手動，開發(fā)一些腳本，crontab，通過BGREWRITEAOF命令去執(zhí)行AOF rewrite，但是redis 2.4之后，會自動進行rewrite操作

注意：

在redis.conf中，可以配置rewrite策略

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

比如說上一次AOF rewrite之后，是128mb，然后就會接著128mb繼續(xù)寫AOF的日志，如果發(fā)現(xiàn)增長的比例，超過了之前的100%，也就是256mb，就可能會去觸發(fā)一次rewrite，但是此時還要去跟min-size，64mb去比較，256mb > 64mb，才會去觸發(fā)rewrite

12.AOF破損文件的修復

如果redis在append數(shù)據(jù)到AOF文件時，機器宕機了，可能會導致AOF文件破損，用redis-check-aof --fix命令來修復破損的AOF文件。

13.AOF和RDB同時工作

(1).如果RDB在執(zhí)行snapshotting操作，那么redis不會執(zhí)行AOF rewrite; 如果redis再執(zhí)行AOF rewrite，那么就不會執(zhí)行RDB snapshotting

(2).如果RDB在執(zhí)行snapshotting，此時用戶執(zhí)行BGREWRITEAOF命令，那么等RDB快照生成之后，才會去執(zhí)行AOF rewrite

(3).同時有RDB snapshot文件和AOF日志文件，那么redis重啟的時候，會優(yōu)先使用AOF進行數(shù)據(jù)恢復，因為其中的日志更完整

14.企業(yè)級的持久化的配置策略

企業(yè)中，RDB的生成策略，用默認的也差不多

save 60 10000：如果你希望盡可能確保說，RDB最多丟1分鐘的數(shù)據(jù)，那么盡量就是每隔1分鐘都生成一個快照，低峰期，數(shù)據(jù)量很少，也沒必要

AOF一定要打開，fsync，everysec

auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%，上次的兩倍

auto-aof-rewrite-min-size 64mb: 根據(jù)你的數(shù)據(jù)量來定，16mb，32mb

15.企業(yè)級的數(shù)據(jù)備份方案

(1).寫crontab定時調(diào)度腳本去做數(shù)據(jù)備份

(2).每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份

(3).每天都保留一份當日的rdb的備份，到一個目錄中去，僅僅保留最近1個月的備份

(4).每次copy備份的時候，都把太舊的備份給刪了

(5).每天晚上將當前服務器上所有的數(shù)據(jù)備份，發(fā)送一份到遠程的云服務上去

按小時和按天同時備份

每小時copy一次備份，刪除48小時前的數(shù)據(jù)

crontab -e 
　　0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh 
　　redis_rdb_copy_hourly.sh 
 
　　#!/bin/sh  
　　cur_date=`date +%Y%m%d%k` 
　　rm -rf /usr/local/redis/snapshotting/$cur_date 
　　mkdir /usr/local/redis/snapshotting/$cur_date 
　　cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date 
 
　　del_date=`date -d -48hour +%Y%m%d%k` 
　　rm -rf /usr/local/redis/snapshotting/$del_date 
 
　　每天copy一次備份 
　　crontab -e 
　　0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh 
　　redis_rdb_copy_daily.sh 
 
　　#!/bin/sh  
　　cur_date=`date +%Y%m%d` 
　　rm -rf /usr/local/redis/snapshotting/$cur_date 
　　mkdir /usr/local/redis/snapshotting/$cur_date 
　　cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date 
　　del_date=`date -d -1month +%Y%m%d` 
　　rm -rf /usr/local/redis/snapshotting/$del_date 

每天一次將所有數(shù)據(jù)上傳一次到遠程的云服務器上去

16.企業(yè)級數(shù)據(jù)恢復方案

(1).如果是redis進程掛掉，那么重啟redis進程即可，直接基于AOF日志文件恢復數(shù)據(jù)

(2).如果是redis進程所在機器掛掉，那么重啟機器后，嘗試重啟redis進程，嘗試直接基于AOF日志文件進行數(shù)據(jù)恢復，前提是AOF沒有破損，AOF append-only，順序?qū)懭耄绻鸄OF文件破損，那么用redis-check-aof fix修復。

(3).如果redis當前***的AOF和RDB文件出現(xiàn)了丟失/損壞，那么可以嘗試基于該機器上當前的某個***的RDB數(shù)據(jù)副本進行數(shù)據(jù)恢復，當前***的AOF和RDB文件都出現(xiàn)了丟失/損壞到無法恢復，一般不是機器的故障，而是人為。

17.容災演練

appendonly.aof + dump.rdb，優(yōu)先用appendonly.aof去恢復數(shù)據(jù)。

(1).如果關(guān)閉AOF持久化機制，并且dump.rdb是有數(shù)據(jù)的，這時候重啟redis，發(fā)現(xiàn)內(nèi)存中明顯沒有恢復數(shù)據(jù)。

原因：redis啟動的時候，自動重新基于內(nèi)存的數(shù)據(jù)，生成了一份***的rdb快照，直接用空的數(shù)據(jù)，覆蓋掉了我們有數(shù)據(jù)的dump.rdb

(2).如果打開AOF，停止redis之后，先刪除appendonly.aof，然后將我們的dump.rdb拷貝過去，然后再重啟redis，發(fā)現(xiàn)依然沒有恢復數(shù)據(jù)

原因：雖然你刪除了appendonly.aof，但是因為打開了aof持久化，redis就一定會優(yōu)先基于aof去恢復，即使文件不在，那就創(chuàng)建一個新的空的aof文件

(3).停止redis，暫時在配置中關(guān)閉aof，然后拷貝一份rdb過來，再重啟redis，這時候內(nèi)存中的數(shù)據(jù)恢復成功;假如不小心，再關(guān)掉redis，手動修改配置文件，打開aof，再重啟redis，數(shù)據(jù)又沒了，因為是空的aof文件，所以所有數(shù)據(jù)又沒了。

在數(shù)據(jù)安全丟失的情況下，基于rdb冷備，如何***的恢復數(shù)據(jù)，同時還保持aof和rdb的雙開?

(4).停止redis，關(guān)閉aof，拷貝rdb備份，重啟redis，確認數(shù)據(jù)恢復，直接在命令行熱修改redis配置，打開aof，這個redis就會將內(nèi)存中的數(shù)據(jù)對應的日志，寫入aof文件中，此時aof和rdb兩份數(shù)據(jù)文件的數(shù)據(jù)就同步了。

注意：redis config set熱修改配置參數(shù)，可能配置文件中的實際的參數(shù)沒有被持久化的修改，再次停止redis，手動修改配置文件，打開aof的命令，再次重啟redis

(5).如果當前機器上的所有RDB文件全部損壞，那么從遠程的云服務上拉取***的RDB快照回來恢復數(shù)據(jù)

(6).如果是發(fā)現(xiàn)有重大的數(shù)據(jù)錯誤，比如某個小時上線的程序一下子將數(shù)據(jù)全部污染了，數(shù)據(jù)全錯了，那么可以選擇某個更早的時間點，對數(shù)據(jù)進行恢復

舉個例子，12點上線了代碼，發(fā)現(xiàn)代碼有bug，導致代碼生成的所有的緩存數(shù)據(jù)，寫入redis，全部錯了，找到一份11點的rdb的冷備，然后按照上面的步驟，去恢復到11點的數(shù)據(jù)。