對長期奮戰在一線的後端開發人員來說，都知道redis有兩種持久化方式RDB和AOF，雖說大家都知道這兩種方式大概運作方式，但想必有實操瞭解得不會太多。 這裡是自己實操兩種持久化方式的一點點記錄。 先看以下摘錄自redis官網原文解釋(當然原文是English，這裡用google翻譯過了。) Redi ...
對長期奮戰在一線的後端開發人員來說，都知道redis有兩種持久化方式RDB和AOF，雖說大家都知道這兩種方式大概運作方式，但想必有實操瞭解得不會太多。
這裡是自己實操兩種持久化方式的一點點記錄。
先看以下摘錄自redis官網原文解釋(當然原文是English，這裡用google翻譯過了。)
Redis持久性
Redis提供了不同的持久性選項範圍：
RDB持久性按指定的時間間隔執行數據集的時間點快照。
AOF持久性會記錄伺服器接收的每個寫入操作，這些操作將在伺服器啟動時再次播放，以重建原始數據集。 使用與Redis協議本身相同的格式記錄命令，並且僅採用追加方式。 當日誌太大時，Redis可以在後臺重寫日誌。
如果希望，只要您的數據在伺服器運行時就一直存在，則可以完全禁用持久性。
可以在同一實例中同時合併AOF和RDB。 請註意，在這種情況下，當Redis重新啟動時，AOF文件將用於重建原始數據集，因為它可以保證是最完整的。
要理解的最重要的事情是RDB與AOF持久性之間的不同權衡。 讓我們從RDB開始：
RDB的優勢
RDB是Redis數據的非常緊湊的單文件時間點表示。 RDB文件非常適合備份。 例如，您可能希望在最近的24小時內每小時存檔一次RDB文件，併在30天之內每天保存一次RDB快照。 這使您可以在發生災難時輕鬆還原數據集的不同版本。
RDB對於災難恢復非常有用，它是一個緊湊的文件，可以傳輸到遠程數據中心或Amazon S3（可能已加密）上。
RDB最大限度地提高了Redis的性能，因為Redis父進程為了持久化所需要做的唯一工作就是分叉一個孩子，其餘的都將做。 父實例將永遠不會執行磁碟I / O或類似操作。
與AOF相比，RDB允許大型數據集更快地重啟。
RDB的缺點
如果您需要在Redis停止工作（例如斷電後）的情況下最大程度地減少數據丟失的機會，則RDB不好。 您可以在生成RDB的位置配置不同的保存點 （例如，在至少五分鐘之後，對數據集進行100次寫入，但是您可以有多個保存點）。 但是，通常會每隔五分鐘或更長時間創建一次RDB快照，因此，如果Redis出於任何原因在沒有正確關閉的情況下停止工作，則應該準備丟失最新的數據分鐘。
RDB需要經常使用fork（）才能使用子進程將其持久化在磁碟上。 如果數據集很大，Fork（）可能很耗時，並且如果數據集很大且CPU性能不佳，則可能導致Redis停止為客戶端服務幾毫秒甚至一秒鐘。 AOF還需要fork（），但您可以調整要重寫日誌的頻率，而無需在持久性上進行權衡。
AOF的優勢
使用AOF Redis更加持久：您可以有不同的fsync策略：完全沒有fsync，每秒fsync，每個查詢fsync。 使用預設策略fsync時，每秒的寫入性能仍然很好（fsync是使用後臺線程執行的，並且在沒有進行fsync的情況下，主線程將儘力執行寫入操作。）但是您只能損失一秒鐘的寫入時間。
AOF日誌僅是一個追加日誌，因此，如果斷電，也不會出現尋道或損壞問題。 即使由於某種原因（磁碟已滿或其他原因）以半寫命令結束日誌，redis-check-aof工具也可以輕鬆修複它。
Redis太大時，Redis可以在後臺自動重寫AOF。 重寫是完全安全的，因為Redis繼續追加到舊文件時，會生成一個全新的文件，其中包含創建當前數據集所需的最少操作集，一旦準備好第二個文件，Redis會切換這兩個文件並開始追加到新的那一個。
AOF以易於理解和解析的格式包含所有操作的日誌。 您甚至可以輕鬆導出AOF文件。 例如，即使您使用FLUSHALL命令刷新了所有錯誤文件 ，如果在此期間未執行任何日誌重寫操作，您仍然可以保存數據集，只是停止伺服器，刪除最新命令並重新啟動Redis。
AOF的缺點
對於相同的數據集，AOF文件通常大於等效的RDB文件。
根據確切的fsync策略，AOF可能比RDB慢。 通常，在將fsync設置為每秒的情況下，性能仍然很高，並且在禁用fsync的情況下，即使在高負載下，它也應與RDB一樣快。 即使在巨大的寫負載情況下，RDB仍然能夠提供有關最大延遲的更多保證。
過去，我們在特定命令中遇到過罕見的錯誤（例如，其中有一個涉及阻塞命令，例如BRPOPLPUSH ），導致生成的AOF在重載時無法重現完全相同的數據集。 這些錯誤很少見，我們在測試套件中進行了測試，自動創建了隨機的複雜數據集，然後重新載入它們以檢查一切是否正常。 但是，RDB持久性幾乎是不可能的。 更明確地說：Redis AOF通過增量更新現有狀態來工作，就像MySQL或MongoDB一樣，而RDB快照一次又一次地創建所有內容，從概念上講更健壯。 但是-1）應該註意的是，每次Redis重寫AOF時，都會從數據集中包含的實際數據開始從頭開始重新創建AOF，與始終附加AOF文件相比（或重寫後的讀數），對錯誤的抵抗力更強舊的AOF，而不是讀取記憶體中的數據）。 2）我們從未收到過有關真實環境中檢測到的AOF損壞的用戶報告。
未完待續，今天困了，明天開始寫
