redis redis的兩種持久化機制

Redis 提供了兩種方式，實現數據的持久化到硬盤。

• 一、【全量】RDB 持久化，是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。實際操做過程是，fork 一個子進程，先將數據集寫入臨時文件，寫入成功後，再替換以前的文件，用二進制壓縮存儲。 - 默認開啓rdb持久化
• 二、【增量】AOF持久化，以日誌的形式記錄服務器所處理的每個寫、刪除操做，查詢操做不會記錄，以文本的方式記錄，能夠打開文件看到詳細的操做記錄。 - 默認關閉 每次寫，刪除操做就同步或者每秒同步

（1）RDB 優缺點

優勢：

• 靈活設置備份頻率和週期。你可能打算每一個小時歸檔一次最近 24 小時的數據，同時還要天天歸檔一次最近 30 天的數據。經過這樣的備份策略，一旦系統出現災難性故障，咱們能夠很是容易的進行恢復。
• 很是適合冷備份，對於災難恢復而言，RDB 是很是不錯的選擇。由於咱們能夠很是輕鬆的將一個單獨的文件壓縮後再轉移到其它存儲介質上。推薦，能夠將這種完整的數據文件發送到一些遠程的安全存儲上去，好比說 Amazon 的 S3 雲服務上去，在國內能夠是阿里雲的 OSS 分佈式存儲上。
• 性能最大化。對於 Redis 的服務進程而言，在開始持久化時，它惟一須要作的只是 fork 出子進程，以後再由子進程完成這些持久化的工做，這樣就能夠極大的避免服務進程執行 IO 操做了。也就是說，RDB 對 Redis 對外提供的讀寫服務，影響很是小，可讓 Redis 保持高性能。
• 恢復更快。相比於 AOF 機制，RDB 的恢復速度更更快，更適合恢復數據，特別是在數據集很是大的狀況。

缺點：

• 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼 RDB 將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。

  因此，RDB 實際場景下，須要和 AOF 一塊兒使用。

• 因爲 RDB 是經過 fork 子進程來協助完成數據持久化工做的，所以，若是當數據集較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是 1 秒鐘。

  因此，RDB 建議在業務低估，例如在半夜執行。

（2）AOF 優缺點

優勢：

• 該機制能夠帶來更高的數據安全性，即數據持久性。Redis 中提供了 3 種同步策略，即每秒同步、每修改(執行一個命令)同步和不一樣步。事實上，每秒同步也是異步完成的，其效率也是很是高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘以內修改的數據將會丟失。而每修改同步，咱們能夠將其視爲同步持久化，即每次發生的數據變化都會被當即記錄到磁盤中。能夠預見，這種方式在效率上是最低的。至於無同步，無需多言，我想你們都能正確的理解它。
• 因爲該機制對日誌文件的寫入操做採用的是 append 模式，所以在寫入過程當中即便出現宕機現象，也不會破壞日誌文件中已經存在的內容。由於以 append-only 模式寫入，因此沒有任何磁盤尋址的開銷，寫入性能很是高。另外，若是咱們本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，在 Redis 下一次啓動以前，咱們能夠經過 redis-check-aof 工具來幫助咱們解決數據一致性的問題。
• 若是日誌過大，Redis能夠自動啓用 rewrite 機制。即便出現後臺重寫操做，也不會影響客戶端的讀寫。由於在 rewrite log 的時候，會對其中的指令進行壓縮，建立出一份須要恢復數據的最小日誌出來。再建立新日誌文件的時候，老的日誌文件仍是照常寫入。當新的 merge 後的日誌文件 ready 的時候，再交換新老日誌文件便可。
• AOF 包含一個格式清晰、易於理解的日誌文件用於記錄全部的修改操做。事實上，咱們也能夠經過該文件完成數據的重建。

缺點：

• 對於相同數量的數據集而言，AOF 文件一般要大於 RDB 文件。RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
• 根據同步策略的不一樣，AOF 在運行效率上每每會慢於 RDB 。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和 RDB 同樣高效。
• 之前 AOF 發生過 bug ，就是經過 AOF 記錄的日誌，進行數據恢復的時候，沒有恢復如出一轍的數據出來。因此說，相似 AOF 這種較爲複雜的基於命令日誌/merge/回放的方式，比基於 RDB 每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有 bug 。不過 AOF 就是爲了不 rewrite 過程致使的 bug ，所以每次 rewrite 並非基於舊的指令日誌進行 merge 的，而是基於當時內存中的數據進行指令的從新構建，這樣健壯性會好不少。

（3）如何選擇

• 不要僅僅使用 RDB，由於那樣會致使你丟失不少數據

• 也不要僅僅使用 AOF，由於那樣有兩個問題，第一，你經過 AOF 作冷備，沒有 RDB 作冷備，來的恢復速度更快; 第二，RDB 每次簡單粗暴生成數據快照，更加健壯，能夠避免 AOF 這種複雜的備份和恢復機制的 bug 。

• Redis 支持同時開啓開啓兩種持久化方式，咱們能夠綜合使用 AOF 和 RDB 兩種持久化機制，用 AOF 來保證數據不丟失，做爲數據恢復的第一選擇; 用 RDB 來作不一樣程度的冷備，在 AOF 文件都丟失或損壞不可用的時候，還可使用 RDB 來進行快速的數據恢復。

  • 若是同時使用 RDB 和 AOF 兩種持久化機制，那麼在 Redis 重啓的時候，會使用 AOF 來從新構建數據，由於 AOF 中的數據更加完整。

    通常來講， 若是想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。若是你很是關心你的數據， 但仍然能夠承受數分鐘之內的數據丟失，那麼你能夠只使用 RDB 持久化。

    有不少用戶都只使用 AOF 持久化，但並不推薦這種方式：由於定時生成 RDB 快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比AOF恢復的速度要快，除此以外，使用 RDB 還能夠避免以前提到的 AOF 程序的 bug。