到這里為止榔昔，其實還是停留在簡單學習知識的程度聘殖，學會了redis的持久化的原理和操作，但是在企業(yè)中续挟，持久化到底是怎么去用得呢紧卒？
企業(yè)級的數(shù)據(jù)備份和各種災難下的數(shù)據(jù)恢復，是怎么做得呢诗祸？
1常侦、企業(yè)級的持久化的配置策略
在企業(yè)中，RDB的生成策略贬媒，用默認的也差不多
save 60 10000：如果你希望盡可能確保說，RDB最多丟1分鐘的數(shù)據(jù)肘习，那么盡量就是每隔1分鐘都生成一個快照际乘，低峰期，數(shù)據(jù)量很少漂佩，也沒必要
10000->生成RDB脖含，1000->RDB，這個根據(jù)你自己的應用和業(yè)務的數(shù)據(jù)量投蝉，你自己去決定
AOF一定要打開养葵，fsync，everysec
auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%瘩缆，上次的兩倍
auto-aof-rewrite-min-size 64mb: 根據(jù)你的數(shù)據(jù)量來定关拒，16mb，32mb
2庸娱、企業(yè)級的數(shù)據(jù)備份方案
RDB非常適合做冷備着绊，每次生成之后，就不會再有修改了
數(shù)據(jù)備份方案
（1）寫crontab定時調(diào)度腳本去做數(shù)據(jù)備份
（2）每小時都copy一份rdb的備份熟尉，到一個目錄中去归露，僅僅保留最近48小時的備份
（3）每天都保留一份當日的rdb的備份，到一個目錄中去斤儿，僅僅保留最近1個月的備份
（4）每次copy備份的時候剧包，都把太舊的備份給刪了
（5）每天晚上將當前服務器上所有的數(shù)據(jù)備份，發(fā)送一份到遠程的云服務上去
/usr/local/redis
每小時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ù)上傳一次到遠程的云服務器上去
3疆液、數(shù)據(jù)恢復方案
（1）如果是redis進程掛掉，那么重啟redis進程即可棚放，直接基于AOF日志文件恢復數(shù)據(jù)
不演示了枚粘，在AOF數(shù)據(jù)恢復那一塊，演示了飘蚯，fsync everysec馍迄，最多就丟一秒的數(shù)
（2）如果是redis進程所在機器掛掉福也，那么重啟機器后，嘗試重啟redis進程攀圈，嘗試直接基于AOF日志文件進行數(shù)據(jù)恢復
AOF沒有破損暴凑，也是可以直接基于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)了丟失/損壞到無法恢復犬辰，一般不是機器的故障嗦篱，人為
大數(shù)據(jù)系統(tǒng)，hadoop幌缝，有人不小心就把hadoop中存儲的大量的數(shù)據(jù)文件對應的目錄灸促，rm -rf一下，我朋友的一個小公司涵卵，運維不太靠譜浴栽，權限也弄的不太好
/var/redis/6379下的文件給刪除了
找到RDB最新的一份備份，小時級的備份可以了轿偎，小時級的肯定是最新的典鸡，copy到redis里面去，就可以恢復到某一個小時的數(shù)據(jù)
容災演練
我跟大家解釋一下坏晦，我其實上課萝玷，為什么大量的講師可能講課就是純PPT，或者是各種復制粘貼英遭，都不是現(xiàn)場講解和寫代碼演示的
很容易出錯间护，為了避免出錯，一般就會那樣玩兒
吐槽挖诸，念PPT汁尺，效果很差
真實的，備課多律，講課不可避免痴突，會出現(xiàn)一些問題，但是我覺得還好狼荞，真實
appendonly.aof + dump.rdb辽装，優(yōu)先用appendonly.aof去恢復數(shù)據(jù)，但是我們發(fā)現(xiàn)redis自動生成的appendonly.aof是沒有數(shù)據(jù)的
然后我們自己的dump.rdb是有數(shù)據(jù)的相味，但是明顯沒用我們的數(shù)據(jù)
redis啟動的時候拾积，自動重新基于內(nèi)存的數(shù)據(jù)，生成了一份最新的rdb快照，直接用空的數(shù)據(jù)拓巧，覆蓋掉了我們有數(shù)據(jù)的斯碌，拷貝過去的那份dump.rdb
你停止redis之后，其實應該先刪除appendonly.aof肛度，然后將我們的dump.rdb拷貝過去傻唾，然后再重啟redis
很簡單，就是雖然你刪除了appendonly.aof承耿，但是因為打開了aof持久化冠骄，redis就一定會優(yōu)先基于aof去恢復，即使文件不在加袋，那就創(chuàng)建一個新的空的aof文件
停止redis凛辣，暫時在配置中關閉aof，然后拷貝一份rdb過來职烧，再重啟redis蟀给，數(shù)據(jù)能不能恢復過來，可以恢復過來
腦子一熱阳堕，再關掉redis，手動修改配置文件择克，打開aof恬总，再重啟redis，數(shù)據(jù)又沒了肚邢，空的aof文件壹堰，所有數(shù)據(jù)又沒了
在數(shù)據(jù)安全丟失的情況下，基于rdb冷備骡湖，如何完美的恢復數(shù)據(jù)贱纠，同時還保持aof和rdb的雙開
停止redis，關閉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
（4）如果當前機器上的所有RDB文件全部損壞，那么從遠程的云服務上拉取最新的RDB快照回來恢復數(shù)據(jù)
（5）如果是發(fā)現(xiàn)有重大的數(shù)據(jù)錯誤改艇，比如某個小時上線的程序一下子將數(shù)據(jù)全部污染了收班，數(shù)據(jù)全錯了，那么可以選擇某個更早的時間點遣耍，對數(shù)據(jù)進行恢復
舉個例子闺阱，12點上線了代碼，發(fā)現(xiàn)代碼有bug舵变，導致代碼生成的所有的緩存數(shù)據(jù)酣溃，寫入redis，全部錯了
找到一份11點的rdb的冷備纪隙，然后按照上面的步驟赊豌，去恢復到11點的數(shù)據(jù)，不就可以了嗎
