到這裏爲止，其實還是停留在簡單學習知識的程度，學會了redis的持久化的原理和操作，但是在企業中，持久化到底是怎麼去用得呢？
企業級的數據備份和各種災難下的數據恢復，是怎麼做得呢？
1、企業級的持久化的配置策略
在企業中，RDB的生成策略，用默認的也差不多
save 60 10000：如果你希望儘可能確保說，RDB最多丟1分鐘的數據，那麼儘量就是每隔1分鐘都生成一個快照，低峯期，數據量很少，也沒必要
10000->生成RDB，1000->RDB，這個根據你自己的應用和業務的數據量，你自己去決定
AOF一定要打開，fsync，everysec
auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%，上次的兩倍
auto-aof-rewrite-min-size 64mb: 根據你的數據量來定，16mb，32mb
2、企業級的數據備份方案
RDB非常適合做冷備，每次生成之後，就不會再有修改了
數據備份方案
（1）寫crontab定時調度腳本去做數據備份
（2）每小時都copy一份rdb的備份，到一個目錄中去，僅僅保留最近48小時的備份
（3）每天都保留一份當日的rdb的備份，到一個目錄中去，僅僅保留最近1個月的備份
（4）每次copy備份的時候，都把太舊的備份給刪了
（5）每天晚上將當前服務器上所有的數據備份，發送一份到遠程的雲服務上去
/usr/local/redis
每小時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
每天一次將所有數據上傳一次到遠程的雲服務器上去
3、數據恢復方案
（1）如果是redis進程掛掉，那麼重啓redis進程即可，直接基於AOF日誌文件恢復數據
不演示了，在AOF數據恢復那一塊，演示了，fsync everysec，最多就丟一秒的數
（2）如果是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，嘗試直接基於AOF日誌文件進行數據恢復
AOF沒有破損，也是可以直接基於AOF恢復的
AOF append-only，順序寫入，如果AOF文件破損，那麼用redis-check-aof fix
（3）如果redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼可以嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復
當前最新的AOF和RDB文件都出現了丟失/損壞到無法恢復，一般不是機器的故障，人爲
大數據系統，hadoop，有人不小心就把hadoop中存儲的大量的數據文件對應的目錄，rm -rf一下，我朋友的一個小公司，運維不太靠譜，權限也弄的不太好
/var/redis/6379下的文件給刪除了
找到RDB最新的一份備份，小時級的備份可以了，小時級的肯定是最新的，copy到redis裏面去，就可以恢復到某一個小時的數據
容災演練
我跟大家解釋一下，我其實上課，爲什麼大量的講師可能講課就是純PPT，或者是各種複製粘貼，都不是現場講解和寫代碼演示的
很容易出錯，爲了避免出錯，一般就會那樣玩兒
吐槽，念PPT，效果很差
真實的，備課，講課不可避免，會出現一些問題，但是我覺得還好，真實
appendonly.aof + dump.rdb，優先用appendonly.aof去恢復數據，但是我們發現redis自動生成的appendonly.aof是沒有數據的
然後我們自己的dump.rdb是有數據的，但是明顯沒用我們的數據
redis啓動的時候，自動重新基於內存的數據，生成了一份最新的rdb快照，直接用空的數據，覆蓋掉了我們有數據的，拷貝過去的那份dump.rdb
你停止redis之後，其實應該先刪除appendonly.aof，然後將我們的dump.rdb拷貝過去，然後再重啓redis
很簡單，就是雖然你刪除了appendonly.aof，但是因爲打開了aof持久化，redis就一定會優先基於aof去恢復，即使文件不在，那就創建一個新的空的aof文件
停止redis，暫時在配置中關閉aof，然後拷貝一份rdb過來，再重啓redis，數據能不能恢復過來，可以恢復過來
腦子一熱，再關掉redis，手動修改配置文件，打開aof，再重啓redis，數據又沒了，空的aof文件，所有數據又沒了
在數據安全丟失的情況下，基於rdb冷備，如何完美的恢復數據，同時還保持aof和rdb的雙開
停止redis，關閉aof，拷貝rdb備份，重啓redis，確認數據恢復，直接在命令行熱修改redis配置，打開aof，這個redis就會將內存中的數據對應的日誌，寫入aof文件中
此時aof和rdb兩份數據文件的數據就同步了
redis config set熱修改配置參數，可能配置文件中的實際的參數沒有被持久化的修改，再次停止redis，手動修改配置文件，打開aof的命令，再次重啓redis
（4）如果當前機器上的所有RDB文件全部損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢復數據
（5）如果是發現有重大的數據錯誤，比如某個小時上線的程序一下子將數據全部污染了，數據全錯了，那麼可以選擇某個更早的時間點，對數據進行恢復
舉個例子，12點上線了代碼，發現代碼有bug，導致代碼生成的所有的緩存數據，寫入redis，全部錯了
找到一份11點的rdb的冷備，然後按照上面的步驟，去恢復到11點的數據，不就可以了嗎