首頁  >  文章  >  資料庫  >  redis使用哪種持久化策略好

redis使用哪種持久化策略好

步履不停
步履不停原創
2019-06-25 11:58:262611瀏覽

redis使用哪種持久化策略好

Redis 提供了多種不同層級的持久化方式:

RDB 持久化可以在指定的時間間隔內產生資料集的時間點快照(point-in-time snapshot)。

AOF 持久化記錄伺服器執行的所有寫入操作命令,並在伺服器啟動時,透過重新執行這些命令來還原資料集。 AOF 檔案中的指令全部以 Redis 協定的格式來儲存,新指令會被追加到檔案的結尾。 Redis 也可以在背景對 AOF 檔案進行重寫(rewrite),使得 AOF 檔案的體積不會超出保存資料集狀態所需的實際大小。

Redis 還可以同時使用 AOF 持久化和 RDB 持久化。在這種情況下, 當 Redis 重新啟動時, 它會優先使用 AOF 檔案來還原資料集, 因為 AOF 檔案保存的資料集通常比 RDB 檔案所保存的資料集更完整。

你甚至可以關閉持久化功能,讓資料只在伺服器運行時存在。

RDB知識點

RDB 的優點

RDB 是一個非常緊湊(compact)的文件,它保存了Redis 在某個時間點上的資料集。這種文件非常適合用於進行備份: 例如,你可以在最近的 24 小時內,每小時備份一次 RDB 文件,並且在每個月的每一天,也備份一個 RDB 文件。這樣的話,即使遇上問題,也可以隨時將資料集還原到不同的版本。

RDB 非常適用於災難復原(disaster recovery):它只有一個文件,而且內容都非常緊湊,可以(在加密後)將它傳送到別的資料中心,或亞馬遜 S3 中。

RDB 可以最大化Redis 的效能:父進程在儲存RDB 檔案時唯一要做的就是fork 出一個子進程,然後這個子進程就會處理接下來的所有儲存工作,父進程無須執行任何磁碟I/O 操作。

RDB 在恢復大資料集時的速度比 AOF 的復原速度還要快。

RDB 的缺點

如果你需要盡量避免在伺服器故障時遺失數據,那麼 RDB 不適合你。雖然 Redis 允許你設定不同的保存點(save point)來控制保存 RDB 檔案的頻率, 但是, 因為RDB 檔案需要保存整個資料集的狀態, 所以它並不是一個輕鬆的操作。因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。在這種情況下, 一旦發生故障停機, 你就可能會遺失好幾分鐘的資料。

每次儲存 RDB 的時候,Redis 都要 fork() 出一個子程序,並由子程序來進行實際的持久化工作。在資料集比較龐大時, fork() 可能會非常耗時,造成伺服器在某某毫秒內停止處理客戶端; 如果資料集非常巨大,並且CPU 時間非常緊張的話,那麼這種停止時間甚至可能會長達整整一秒。雖然 AOF 重寫也需要進行 fork() ,但無論 AOF 重寫的執行間隔有多長,資料的耐久性都不會有任何損失。

AOF知識點

AOF 的優點

使用AOF 持久化會讓Redis 變得非常耐久(much more durable):你可以設定不同的fsync 策略,例如無fsync ,每秒鐘一次fsync ,或是每次執行寫入指令時fsync 。 AOF 的預設策略為每秒鐘fsync 一次,在這種配置下,Redis 仍然可以保持良好的性能,並且就算發生故障停機,也最多只會丟失一秒鐘的數據( fsync 會在後台線程執行,所以主線程可以繼續努力地處理命令請求)。

AOF 檔案是一個只進行追加操作的日誌檔案(append only log), 因此對AOF 檔案的寫入不需要進行seek , 即使日誌因為某些原因而包含了未寫入完整的命令(例如寫入時磁碟已滿,寫入中途停機,等等), redis-check-aof 工具也可以輕易地修復這種問題。

Redis 可以在 AOF 檔案體積變得過大時,自動地在背景對 AOF 進行重寫: 重寫後的新 AOF 檔案包含了恢復目前資料集所需的最小指令集。整個重寫操作是絕對安全的,因為Redis 在建立新AOF 檔案的過程中,會繼續將命令追加到現有的AOF 檔案裡面,即使重寫過程中發生停機,現有的AOF 檔案也不會遺失。而一旦新 AOF 文件創建完畢,Redis 就會從舊 AOF 文件切換到新 AOF 文件,並開始對新 AOF 文件進行追加操作。

AOF 檔案有序地保存了對資料庫執行的所有寫入操作, 這些寫入操作以Redis 協定的格式保存, 因此AOF 檔案的內容非常容易被人讀懂, 對檔案進行分析( parse)也很輕鬆。匯出(export) AOF 檔案也非常簡單: 舉個例子, 如果你不小心執行了FLUSHALL 指令, 但只要AOF 檔案未被重寫, 那麼只要停止伺服器, 移除AOF 檔案末尾的FLUSHALL 指令,並重啟Redis ,就可以將資料集還原到FLUSHALL 執行之前的狀態。

AOF 的缺點

對於相同的資料集來說,AOF 檔案的體積通常大於 RDB 檔案的體積。

根據所使用的 fsync 策略,AOF 的速度可能會慢於 RDB 。在一般情況下, 每秒 fsync 的效能依然非常高, 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快, 即使在高負載之下也是如此。不過在處理巨大的寫入載入時,RDB 可以提供更有保證的最大延遲時間(latency)。

AOF 在過去曾經發生過這樣的 bug : 因為個別指令的原因,導致 AOF 檔案在重新載入時,無法將資料集還原成保存時的原樣。 (舉個例子,阻塞指令BRPOPLPUSH 就曾經引起過這樣的bug 。) 測試套件裡為這種情況添加了測試: 它們會自動產生隨機的、複雜的資料集, 並透過重新載入這些資料來確保一切正常。雖然這種 bug 在 AOF 檔案中並不常見, 但對比來說, RDB 幾乎是不可能出現這種 bug 的。

更多Redis相關技術文章,請造訪Redis教學欄位進行學習!

以上是redis使用哪種持久化策略好的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
上一篇:redis用在哪裡下一篇:redis用在哪裡

相關文章

看更多