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點的數據。
