Redis 持久化 RDB，AOF介紹

一.什麼是持久化

二.rdb

1.1 優點

1.2 缺點

2.1 優點

2.2 缺點

四. 持久化選擇策略

持久化就是將記憶體中的資料定時的儲存到磁碟中的過程。持久化是redis高可用中比較重要的乙個環節，因為redis資料在記憶體的特性，持久化必須得有，不然伺服器死機會導致資料全丟。

兩種方式都可以把redis記憶體中的資料持久化到磁碟上，然後再將這些資料備份到別的地方去，rdb更適合做冷備，aof更適合做熱備，如某電商公司有這兩個資料，備份乙份到杭州的節點，再備份乙個到上海的，就算發生無法避免的自然災害，兩個地方同時掛掉的概率極低，這災備也就是異地容災。

rdb持久化是把當前程序資料生成快照儲存到硬碟的過程，觸發rdb持久化過程分為手動觸發和自動觸發。

1.生成多個資料檔案，每個資料檔案分別都代表了某一時刻redis裡面的資料。完整的資料運維設定定時任務，定時同步到遠端的伺服器，比如阿里的雲服務，這樣一旦線上掛了，你想恢復多少分鐘之前的資料，就去遠端拷貝乙份之前的資料就好了。

2.rdb對redis的效能影響非常小，是因為在同步資料的時候他只是fork了乙個子程序去做持久化的。

3.在資料恢復的時候速度比aof快。

1.rdb都是快照檔案，都是預設五分鐘甚至更久的時間才會生成一次，這意味著這次同步到下次同步這中間五分鐘的資料都很可能全部丟失掉。aof則最多丟一秒的資料，資料完整性上高下立判。

2.rdb在生成資料快照的時候，如果檔案很大，客戶端可能會暫停幾毫秒甚至幾秒，公司在做秒殺的時候他剛好在這個時候fork了乙個子程序去生成乙個大快照，那就出問題了。

1.rdb五分鐘一次生成快照，但是aof是一秒一次去通過乙個後台的執行緒fsync操作，那最多丟這一秒的資料。

3.aof的日誌是通過乙個叫非常可讀的方式記錄的，這樣的特性就適合做災難性資料誤刪除的緊急恢復，比如公司的實習生通過flushall清空了所有的資料，只要這個時候後台重寫還沒發生，馬上拷貝乙份aof日誌檔案，把最後一條flushall命令刪了就完事了。

1.一樣的資料，aof檔案比rdb還要大。

2.aof開啟後，redis支援寫的qps會比rdb支援寫的要低，因為每秒都要去非同步重新整理一次日誌fsync。

3.重啟是載入熟讀沒有rdb快。

單獨用rdb你會丟失很多資料，你單獨用aof，資料恢復沒rdb來的快，真出什麼時候第一時間用rdb恢復，然後aof做資料補全！冷備熱備一起上，才是網際網路時代乙個高健壯性系統的王道。