1. RDB

Redis DataBase

• 在指定的時間間隔內(nèi)，將內(nèi)存中的數(shù)據(jù)集的快照寫入磁盤；
• 默認(rèn)保存在/usr/local/bin中，文件名dump.rdb;

1.1 自動備份

• redis是內(nèi)存數(shù)據(jù)庫，當(dāng)我們每次用完redis，關(guān)閉linux時，按道理來說，內(nèi)存釋放，redis中的數(shù)據(jù)也會隨之消失
• 為什么我們再次啟動redis的時候，昨天的數(shù)據(jù)還在，并沒有消失呢？
• 正是因為，每次關(guān)機時，redis會自動將數(shù)據(jù)備份到一個文件中 ：/usr/local/bin/dump.rdb
• 接下來我們就來全方位的認(rèn)識 自動備份機制

默認(rèn)的自動備份策略不利于我們測試，所以修改redis.conf文件中的自動備份策略

vim redis.conf
/SNAP  # 搜索
save 900 1   # 900秒內(nèi)，至少變更1次，才會自動備份
save 120 10 # 120秒內(nèi)，至少變更10次，才會自動備份
save 60 10000 # 60秒內(nèi)，至少變更10000次，才會自動備份

當(dāng)然如果你只是用Redis的緩存功能，不需要持久化，那么你可以注釋掉所有的 save 行來停用保存功能?？梢灾苯右粋€空字符串來實現(xiàn)停用：save “”

使用shutdown模擬關(guān)機 ，關(guān)機之前和關(guān)機之后，對比dump.rdb文件的更新時間

注意：當(dāng)我們使用shutdown命令，redis會自動將數(shù)據(jù)庫備份，所以，dump.rdb文件創(chuàng)建時間更新了

開機啟動redis，我們要在120秒內(nèi)保存10條數(shù)據(jù)，再查看dump.rdb文件的更新時間（開兩個終端
窗口，方便查看）

120秒內(nèi)保存10條數(shù)據(jù)這一動作觸發(fā)了備份指令，目前，dump.rdb文件中保存了10條數(shù)據(jù)，將
dump.rdb拷貝一份dump10.rdb，此時兩個文件中都保存10條數(shù)據(jù)

既然有數(shù)據(jù)已經(jīng)備份了，那我們就肆無忌憚的將數(shù)據(jù)全部刪除flushall，再次shutdown關(guān)機
再次啟動redis，發(fā)現(xiàn)數(shù)據(jù)真的消失了，并沒有按照我們所想的 將dump.rdb文件中的內(nèi)容恢復(fù)到redis中。為什么？

因為，當(dāng)我們保存10條以上的數(shù)據(jù)時，數(shù)據(jù)備份起來了； 然后刪除數(shù)據(jù)庫，備份文件中的數(shù)據(jù)，也沒問題；

但是，問題出在shutdown上，這個命令一旦執(zhí)行，就會立刻備份，將刪除之后的空數(shù)據(jù)庫生成備份文件，將之前裝10條數(shù)據(jù)的備份文件覆蓋掉了。所以，就出現(xiàn)了上圖的結(jié)果。自動 恢復(fù)失敗。

怎么解決這個問題呢？要將備份文件再備份

• 將dump.rdb文件刪除，將dump10.rdb重命名為dump.rdb
• 啟動redis服務(wù)，登錄redis，數(shù)據(jù)10條，全部恢復(fù)！

1.2 手動備份

之前自動備份，必須更改好多數(shù)據(jù)，例如上邊，我們改變了十多條數(shù)據(jù)，才會自動備份；

現(xiàn)在，我只保存一條數(shù)據(jù)，就想立刻備份，應(yīng)該怎么做？

每次操作完成，執(zhí)行命令 save 就會立刻備份

1.3 與RDB相關(guān)的配置

• stop-writes-on-bgsave-error：進水口和出水口，出水口發(fā)生故障與否
  • yes：當(dāng)后臺備份時候反生錯誤，前臺停止寫入
  • no：不管死活，就是往里懟
• rdbcompression：對于存儲到磁盤中的快照，是否啟動LZF壓縮算法，一般都會啟動，因為這點性能，多買一臺電腦，完全搞定N個來回了。
  • yes：啟動
  • no：不啟動（不想消耗CPU資源，可關(guān)閉）
• rdbchecksum：在存儲快照后，是否啟動CRC64算法進行數(shù)據(jù)校驗；
  • 開啟后，大約增加10%左右的CPU消耗；
  • 如果希望獲得最大的性能提升，可以選擇關(guān)閉
• dbfilename：快照備份文件名字
• dir：快照備份文件保存的目錄，默認(rèn)為當(dāng)前目錄

優(yōu)勢and劣勢

• 優(yōu)：適合大規(guī)模數(shù)據(jù)恢復(fù)，對數(shù)據(jù)完整性和一致行要求不高；
• 劣：一定間隔備份一次，意外down掉，就失去最后一次快照的所有修改

2. AOF

Append Only File

• 以日志的形式記錄每個寫操作；
• 將redis執(zhí)行過的寫指令全部記錄下來（讀操作不記錄）；
• 只許追加文件，不可以改寫文件；
• redis在啟動之初會讀取該文件從頭到尾執(zhí)行一遍，這樣來重新構(gòu)建數(shù)據(jù)；

2.1 開啟AOF

為了避免失誤，最好將redis.conf總配置文件備份一下，然后再修改內(nèi)容如下：

appendonly yes
appendfilename appendonly.aof

重新啟動redis，以新配置文件啟動

redis-server /usr/local/redis5.0.4/redis.conf

連接redis，加數(shù)據(jù)，刪庫，退出

查看當(dāng)前文件夾多一個aof文件，看看文件中的內(nèi)容,保存的都是 寫 操作

文件中最后一句要刪除，否則數(shù)據(jù)恢復(fù)不了編輯這個文件，最后要 :wq! 強制執(zhí)行

只需要重新連接，數(shù)據(jù)恢復(fù)成功

2.2 共存？誰優(yōu)先？

我們查看redis.conf文件，AOF和RDB兩種備份策略可以同時開啟，那系統(tǒng)會怎樣選擇？

• 動手試試，編輯appendonly.aof，胡搞亂碼，保存退出
• 啟動redis 失敗，所以是AOF優(yōu)先載入來恢復(fù)原始數(shù)據(jù)！因為AOF比RDB數(shù)據(jù)保存的完整性更高！
• 修復(fù)AOF文件，殺光不符合redis語法規(guī)范的代碼

reids-check-aof --fix appendonly.aof

2.3 與AOF相關(guān)的配置

• appendonly：開啟aof模式
• appendfilename：aof的文件名字，最好別改！
• appendfsync：追寫策略
  • always：每次數(shù)據(jù)變更，就會立即記錄到磁盤，性能較差，但數(shù)據(jù)完整性好
  • everysec：默認(rèn)設(shè)置，異步操作，每秒記錄，如果一秒內(nèi)宕機，會有數(shù)據(jù)丟失
  • no：不追寫
• no-appendfsync-on-rewrite：重寫時是否運用Appendfsync追寫策略；用默認(rèn)no即可，保證數(shù)據(jù)安全性。
  • AOF采用文件追加的方式，文件會越來越大，為了解決這個問題，增加了重寫機制，redis會自動記錄上一次AOF文件的大小，當(dāng)AOF文件大小達到預(yù)先設(shè)定的大小時，redis就會啟動AOF文件
• 進行內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集合
• auto-aof-rewrite-percentage：如果AOF文件大小已經(jīng)超過原來的100%，也就是一倍，才重寫壓縮
• auto-aof-rewrite-min-size：如果AOF文件已經(jīng)超過了64mb，才重寫壓縮

3 總結(jié)

• RDB：只用作后備用途，建議15分鐘備份一次就好
• AOF：
  • 在最惡劣的情況下，也只丟失不超過2秒的數(shù)據(jù)，數(shù)據(jù)完整性比較高，但代價太大，會帶來持續(xù)的IO
  • 對硬盤的大小要求也高，默認(rèn)64mb太小了，企業(yè)級最少都是5G以上；
  • master/slave才是新浪微博的選擇

到此這篇關(guān)于淺談Redis持久化的幾種方式的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論