Redis數據持久化、數據備份、數據的故障恢復

1.redis持久化的意義----redis故障恢復
　　在實際的生產環境中，極可能會遇到redis忽然掛掉的狀況，好比redis的進程死掉了、電纜被施工隊挖了（支付寶例子）等等，總之必定會遇到各類奇葩的現象致使redis死掉，這時候放在redis內存中的數據就會所有丟失，這些數據可能服務不少的系統或者服務，固然，咱們能夠從新啓動redis，重啓以後，若是redis沒有持久化，redis中的數據就會所有丟失。
若是經過持久化將數據搞一份到磁盤，而後按期的同步和備份到雲存儲服務上去，那麼就能夠保證數據不會所有丟失，仍是能夠恢復一部分數據的。

2.持久化的兩大機制（RDB和AOF）
　　RDB：對redis數據執行週期性的持久化
　　AOF:將每條命令寫入日誌，以append-only的模式寫入一個日誌文件中，在redis重啓的時候，能夠經過回放AOF的寫入指令來從新構建整個數據集

　　是否實用持久化要看具體的業務場景：
　　若是隻是想讓redis僅僅做爲純內存的緩存，那麼能夠禁止RDB和AOF。

　　故障恢復大體思路：
　　　　經過RDB或AOF，均可以將redis內存中的數據持久化到磁盤上來，而後能夠將數據備份到阿里雲，若是redis掛了，服務器中內存和磁盤的數據就都丟了，這時候能夠將阿里雲中的備份文件拷貝至指定目錄下，而後重啓redis，redis就會自動根據持久化數據文件去恢復內存中的數據，繼續對外提供服務。若是同時室友了RDB和AOF兩種持久化機制，那麼在重啓的時間建議使用AOF的方式從新構建數據，由於AOF中的數據更加完整。

3.剖析RDB和AOF
　　RDB：早上7點，這個時候redis 中有500條數據，這個時候redis會在必定週期內生成一個RDB快照文件，等到了9點的時候redis中有8000條數據，這個時候又在必定的週期內生成了另外一個RDB快照文件，這就是RDB持久化機制。
　　AOF：redis 中每寫入一條指令，就會把這條指令更新到磁盤中的文件中。然而在現代操做系統中，寫文件不是直接寫磁盤，會先寫進os cache，而後在必定時間內再從os cache刷入disk file，對於AOF來講每隔一秒（可配置）調用一次操做系統餓fsync操做強制將os cache中的數據刷入磁盤文件中。可是redis內存中的數據也不是無限增加的，它是按期的根據LRU算法清理一些不經常使用的數據，這樣才能保證AOF不會無限增加，可是若是LRU的清理速度比不上AOF的膨脹速度的時候，這時候當AOF大到必定程度就會進行AOF rewrite操做。AOF rewrite操做就會基於當時redis內存中的數據來從新構造一個更小的AOF文件，而後將舊的AOF文件刪除。
簡單的說，假設redis限定了只能存放10G數據，這時候不斷的在redis中寫入數據，當達到了10G的數據量的時候，這時候根據LRU清理了一些不經常使用的數據，清理了5G，這時候又寫了5G，這時候AOF文件記錄了15G的數據相關的寫入指令，假如這個時候AOF已經膨脹了，這個時候redis進行AOF rewrite操做，從新生成了一個新的10G的數據指令的AOF文件，這個時候將繼續寫入新的AOF文件，將老的AOF文件刪除。

4.RDB和AOF優缺點
　　RDB優勢
　　(1).RDB會生成多個數據文件，每一個數據文件都表明了某一個時刻中redis的數據，這種多個數據文件的方式，很是適合作冷備，能夠將這種完整的數據文件發送到一些遠程的安全存儲上去，好比阿里雲的ODPS分佈式存儲上，以預約好的備份策略來按期備份redis中的數據。
　　RDB作冷備，生成多個文件，每一個文件都表明了某一個時刻的完整的數據快照
　　AOF也能夠作冷備，只有一個文件，可是你能夠，每隔必定時間，去copy一份這個文件出來
可是RDB更適合作冷備，它的優點是由redis去控制固定時長生成快照文件的事情，比較方便; AOF，還須要本身寫一些腳本去作這個事情，須要本身寫定時腳本，並且RDB數據作冷備，在最壞的狀況下，提供數據恢復的時候，速度比AOF快

　　(2).RDB對redis對外提供的讀寫服務，影響很是小，可讓redis保持高性能，由於redis主進程只須要fork一個子進程，讓子進程執行磁盤IO操做來進行RDB持久化便可
RDB，每次寫，都是直接寫redis內存，只是在必定的時候，纔會將數據寫入磁盤中
AOF，每次都是要寫文件的，雖然能夠快速寫入os cache中，可是仍是有必定的時間開銷的,速度確定比RDB略慢一些

　　(3).相對於AOF持久化機制來講，直接基於RDB數據文件來重啓和恢復redis進程，更加快速

　　RDB缺點
　　(1).若是想要在redis故障時，儘量少的丟失數據，那麼RDB沒有AOF好。通常來講，RDB數據快照文件，都是每隔5分鐘，或者更長時間生成一次，這個時候就得接受一旦redis進程宕機，那麼會丟失最近5分鐘的數據，這也是rdb最大的缺點，就是不適合作第一優先的恢復方案，若是你依賴RDB作第一優先恢復方案，會致使數據丟失的比較多。
　　(2).RDB每次在fork子進程來執行RDB快照數據文件生成的時候，若是數據文件特別大，可能會致使對客戶端提供的服務暫停數毫秒，或者甚至數秒，因此通常不要讓RDB的間隔太長，不然每次生成的RDB文件太大了，對redis自己的性能可能會有影響的


　　AOF優勢
　　(1).AOF能夠更好的保護數據不丟失，通常AOF會每隔1秒，經過一個後臺線程執行一次fsync操做，最多丟失1秒鐘的數據,每隔1秒，就執行一次fsync操做，保證os cache中的數據寫入磁盤中，redis進程掛了，最多丟掉1秒鐘的數據。
　　(2).AOF日誌文件以append-only模式寫入，因此沒有任何磁盤尋址的開銷，寫入性能很是高，並且文件不容易破損，即便文件尾部破損，也很容易修復。
　　(3).AOF日誌文件即便過大的時候，出現後臺重寫操做，也不會影響客戶端的讀寫。由於在rewrite log的時候，會對其中的內容進行壓縮，建立出一份須要恢復數據的最小日誌出來。再建立新日誌文件的時候，老的日誌文件仍是照常寫入。當新的merge後的日誌文件ready的時候，再交換新老日誌文件便可。
　　(4).AOF日誌文件的命令經過可讀的方式進行記錄，這個特性很是適合作災難性的誤刪除的緊急恢復。好比某人不當心用flushall命令清空了全部數據，只要這個時候後臺rewrite尚未發生，那麼就能夠當即拷貝AOF文件，將最後一條flushall命令給刪了，而後再將該AOF文件放回去，就能夠經過恢復機制，自動恢復全部數據

　　AOF缺點
　　(1).對於同一份數據來講，AOF日誌文件一般比RDB數據快照文件更大
　　(2).AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，由於AOF通常會配置成每秒fsync一第二天志文件，固然，每秒一次fsync，性能也仍是很高的，若是你要保證一條數據都不丟，也是能夠的，AOF的fsync設置成沒寫入一條數據，fsync一次，那就完蛋了，redis的QPS大降。
　　(3).之前AOF發生過bug，就是經過AOF記錄的日誌，進行數據恢復的時候，沒有恢復如出一轍的數據出來。因此說，相似AOF這種較爲複雜的基於命令日誌/merge/回放的方式，比基於RDB每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有bug。不過AOF就是爲了不rewrite過程致使的bug，所以每次rewrite並非基於舊的指令日誌進行merge的，而是基於當時內存中的數據進行指令的從新構建，這樣健壯性會好不少。
　　(4).惟一的比較大的缺點，其實就是作數據恢復的時候，會比較慢，還有作冷備，按期的備份，不太方便，可能要本身手寫複雜的腳本去作，作冷備不太合適


　　AOF和RDB數據恢復機制
　　AOF，存放的指令日誌，作數據恢復的時候，實際上是要回放和執行全部的指令日誌，來恢復出來內存中的全部數據的
　　RDB，就是一份數據文件，恢復的時候，直接加載到內存中便可

　　不管是AOF和RDB，在redis中都以一個文件的形式存在！！！


5.RDB和AOF如何選擇
　　(1).不要僅僅使用RDB，由於那樣會致使你丟失不少數據
　　(2).也不要僅僅使用AOF，由於那樣有兩個問題，第一，你經過AOF作冷備，沒有RDB作冷備，來的恢復速度更快; 第二，RDB每次簡單粗暴生成數據快照，更加健壯，能夠避免AOF這種複雜的備份和恢復機制的bug
　　(3).綜合使用AOF和RDB兩種持久化機制，用AOF來保證數據不丟失，做爲數據恢復的第一選擇; 用RDB來作不一樣程度的冷備，在AOF文件都丟失或損壞不可用的時候，還可使用RDB來進行快速的數據恢復

6.如何配置RDB持久化
　　(1).redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化
例如：save 60 1000
(每隔60s，若是有超過1000個key發生了變動，那麼就生成一個新的dump.rdb文件，就是當前redis內存中完整的數據快照，這個操做也被稱之爲snapshotting，快照
也能夠手動調用save或者bgsave命令，同步或異步執行rdb快照生成)
　　(2).save能夠設置多個，就是多個snapshotting檢查點，每到一個檢查點，就會去check一下，是否有指定的key數量發生了變動，若是有，就生成一個新的dump.rdb文件


7.RDB持久化機制的工做流程
　　(1).redis根據配置本身嘗試去生成rdb快照文件，fork一個子進程出來，子進程嘗試將數據dump到臨時的rdb快照文件中，完成rdb快照文件的生成以後，就替換以前的舊的快照文件，dump.rdb，每次生成一個新的快照，都會覆蓋以前的老快照。


8.基於RDB持久化機制的數據恢復實驗
　　(1).在redis中保存幾條數據，當即停掉redis進程，而後重啓redis，看看剛纔插入的數據還在不在
　　(2).在redis中再保存幾條新的數據，用kill -9粗暴殺死redis進程，模擬redis故障異常退出，致使內存數據丟失的場景

　　注意：經過redis-cli SHUTDOWN這種方式去停掉redis，實際上是一種安全退出的模式，redis在退出的時候會將內存中的數據當即生成一份完整的rdb快照


9.如何配置AOF持久化
　　(1).AOF持久化，默認是關閉的，默認是打開RDB持久化
　　(2).appendonly yes，能夠打開AOF持久化機制，在生產環境裏面，通常來講AOF都是要打開的，除非你說隨便丟個幾分鐘的數據也無所謂，打開AOF持久化機制以後，redis每次接收到一條寫命令，就會寫入日誌文件中，固然是先寫入os cache的，而後每隔必定時間再fsync一下，並且即便AOF和RDB都開啓了，redis重啓的時候，也是優先經過AOF進行數據恢復的，由於aof數據比較完整
　　(3).能夠配置AOF的fsync策略，有三種策略能夠選擇，一種是每次寫入一條數據就執行一次fsync; 一種是每隔一秒執行一次fsync; 一種是不主動執行fsync
always: 每次寫入一條數據，當即將這個數據對應的寫日誌fsync到磁盤上去，性能很是很是差，吞吐量很低; 確保說redis裏的數據一條都不丟，那就只能這樣了
everysec: 每秒將os cache中的數據fsync到磁盤，這個最經常使用的，生產環境通常都這麼配置，性能很高，QPS仍是能夠上萬的
no: 僅僅redis負責將數據寫入os cache就撒手無論了，而後後面os本身會時不時有本身的策略將數據刷入磁盤，不可控了


10.AOF持久化的數據恢復實驗
　　(1).先僅僅打開RDB，寫入一些數據，而後kill -9殺掉redis進程，接着重啓redis，發現數據沒了，由於RDB快照還沒生成
　　(2).打開AOF的開關，啓用AOF持久化
　　(3).寫入一些數據，觀察AOF文件中的日誌內容
　　(4).kill -9殺掉redis進程，從新啓動redis進程，發現數據被恢復回來了，就是從AOF文件中恢復回來的(redis進程啓動的時候，直接就會從appendonly.aof中加載全部的日誌，把內存中的數據恢復回來)

　　注意：在appendonly.aof文件中，能夠看到剛寫的日誌，它們其實就是先寫入os cache的，而後1秒後才fsync到磁盤中，只有fsync到磁盤中了，纔是安全的，要否則光是在os cache中，機器只要重啓，就什麼都沒了


11.AOF rewrite
　　AOF工做原理
　　(1).redis fork一個子進程
　　(2).子進程基於當前內存中的數據，構建日誌，開始往一個新的臨時的AOF文件中寫入日誌
　　(3).redis主進程，接收到client新的寫操做以後，在內存中的數據繼續寫入新日誌到AOF文件中，同時新的數據也繼續寫入舊的AOF文件
　　(4).redis主進程將內存中的新寫進去的日誌再次追加到新的AOF文件中
　　(5).用新的日誌文件替換掉舊的日誌文件


　　redis中的數據其實有限的，不少數據可能會自動過時，可能會被用戶刪除，可能會被redis用緩存清除的算法清理掉，redis中的數據會不斷淘汰掉舊的，就一部分經常使用的數據會被自動保留在redis內存中，因此可能不少以前的已經被清理掉的數據，對應的寫日誌還停留在AOF中，AOF日誌文件就一個，會不斷的膨脹，到很大很大，因此AOF會自動在後臺每隔必定時間作rewrite操做，好比日誌裏已經存放了針對100w數據的寫日誌了; redis內存只剩下10萬; 基於內存中當前的10萬數據構建一套最新的日誌，到AOF中; 覆蓋以前的老日誌; 確保AOF日誌文件不會過大，保持跟redis內存數據量一致
redis 2.4以前，還須要手動，開發一些腳本，crontab，經過BGREWRITEAOF命令去執行AOF rewrite，可是redis 2.4以後，會自動進行rewrite操做

　　注意：
　　在redis.conf中，能夠配置rewrite策略
　　auto-aof-rewrite-percentage 100
　　auto-aof-rewrite-min-size 64mb
　　好比說上一次AOF rewrite以後，是128mb，而後就會接着128mb繼續寫AOF的日誌，若是發現增加的比例，超過了以前的100%，也就是256mb，就可能會去觸發一次rewrite，可是此時還要去跟min-size，64mb去比較，256mb > 64mb，纔會去觸發rewrite


12.AOF破損文件的修復
　　若是redis在append數據到AOF文件時，機器宕機了，可能會致使AOF文件破損，用redis-check-aof --fix命令來修復破損的AOF文件。


13.AOF和RDB同時工做
　　(1).若是RDB在執行snapshotting操做，那麼redis不會執行AOF rewrite; 若是redis再執行AOF rewrite，那麼就不會執行RDB snapshotting
　　(2).若是RDB在執行snapshotting，此時用戶執行BGREWRITEAOF命令，那麼等RDB快照生成以後，纔會去執行AOF rewrite
　　(3).同時有RDB snapshot文件和AOF日誌文件，那麼redis重啓的時候，會優先使用AOF進行數據恢復，由於其中的日誌更完整



14.企業級的持久化的配置策略
　　企業中，RDB的生成策略，用默認的也差很少
　　save 60 10000：若是你但願儘量確保說，RDB最多丟1分鐘的數據，那麼儘可能就是每隔1分鐘都生成一個快照，低峯期，數據量不多，也不必
　　AOF必定要打開，fsync，everysec
　　auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%，上次的兩倍
　　auto-aof-rewrite-min-size 64mb: 根據你的數據量來定，16mb，32mb

15.企業級的數據備份方案
　　(1).寫crontab定時調度腳本去作數據備份
　　(2).每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份
　　(3).天天都保留一份當日的rdb的備份，到一個目錄中去，僅僅保留最近1個月的備份
　　(4).每次copy備份的時候，都把太舊的備份給刪了
　　(5).天天晚上將當前服務器上全部的數據備份，發送一份到遠程的雲服務上去

　　按小時和按天同時備份

　　每小時copy一次備份，刪除48小時前的數據
　　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

　　天天一次將全部數據上傳一次到遠程的雲服務器上去

16.企業級數據恢復方案
　　(1).若是是redis進程掛掉，那麼重啓redis進程便可，直接基於AOF日誌文件恢復數據
　　(2).若是是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，嘗試直接基於AOF日誌文件進行數據恢復，前提是AOF沒有破損，AOF append-only，順序寫入，若是AOF文件破損，那麼用redis-check-aof fix修復。
　　(3).若是redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼能夠嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復，當前最新的AOF和RDB文件都出現了丟失/損壞到沒法恢復，通常不是機器的故障，而是人爲。


17.容災演練
　　appendonly.aof + dump.rdb，優先用appendonly.aof去恢復數據。

　　(1).若是關閉AOF持久化機制，而且dump.rdb是有數據的，這時候重啓redis，發現內存中明顯沒有恢復數據。
緣由：redis啓動的時候，自動從新基於內存的數據，生成了一份最新的rdb快照，直接用空的數據，覆蓋掉了咱們有數據的dump.rdb
　　(2).若是打開AOF，中止redis以後，先刪除appendonly.aof，而後將咱們的dump.rdb拷貝過去，而後再重啓redis，發現依然沒有恢復數據
緣由：雖然你刪除了appendonly.aof，可是由於打開了aof持久化，redis就必定會優先基於aof去恢復，即便文件不在，那就建立一個新的空的aof文件
　　(3).中止redis，暫時在配置中關閉aof，而後拷貝一份rdb過來，再重啓redis，這時候內存中的數據恢復成功；假如不當心，再關掉redis，手動修改配置文件，打開aof，再重啓redis，數據又沒了，由於是空的aof文件，因此全部數據又沒了。

　　在數據安全丟失的狀況下，基於rdb冷備，如何完美的恢復數據，同時還保持aof和rdb的雙開?
　　(4).中止redis，關閉aof，拷貝rdb備份，重啓redis，確認數據恢復，直接在命令行熱修改redis配置，打開aof，這個redis就會將內存中的數據對應的日誌，寫入aof文件中，此時aof和rdb兩份數據文件的數據就同步了。
注意：redis config set熱修改配置參數，可能配置文件中的實際的參數沒有被持久化的修改，再次中止redis，手動修改配置文件，打開aof的命令，再次重啓redis
　　(5).若是當前機器上的全部RDB文件所有損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢復數據
　　(6).若是是發現有重大的數據錯誤，好比某個小時上線的程序一會兒將數據所有污染了，數據全錯了，那麼能夠選擇某個更早的時間點，對數據進行恢復
舉個例子，12點上線了代碼，發現代碼有bug，致使代碼生成的全部的緩存數據，寫入redis，所有錯了，找到一份11點的rdb的冷備，而後按照上面的步驟，去恢復到11點的數據。