來說說Redis兩種持久化方式的優缺點

前言

Redis是一種K-V資料庫，它的數據也可以進行持久化操作。因為redis的數據都保存在內存中，如果不進行及時的持久化，可能就會因為重啟導致數據的丟失。這時候就需要對redis進行持久化操作，將數據保存在磁碟上。

redis提供了兩種持久化方式，分別是AOF和RDB。下面分別對這裡持久化方式進行解析。

1.RDB

RDB是將redis 的數據生成快照保存在磁碟上。

RDB有多種實現方式，分別如下：

1. 執行save或bgsave命令。save命令會阻塞redis，此時不會響應客戶端發送的請求直到RDB文件執行完成，所以一般不推薦使用。bgsave會創建子進程，由子進程完成數據快照，不會阻塞父進程。
2. 根據配置文件的save m n規則進行快照。
3. 主從複製時，從庫全量複製同步主庫數據，此時主庫會執行bgsave命令進行快照；
4. 客戶端執行資料庫清空命令FLUSHALL時候，觸發快照；
5. 客戶端執行shutdown關閉redis時，觸發快照；

bgsave命令的工作流程如下：

1. 執行bgsave命令，redis父進程判斷當前是否存在子進程如AOF\RDB子進程，如果存在說明正在備份，直接返回。
2. 父進程進行fork創建子進程，此時redis父線程被阻塞。
3. 子進程創建完成，bgsave返回「* Background saving started by pid xxx」信息，並不再阻塞父進程，可以繼續響應其他命令。
4. 子進程進程創建RDB文件，根據內存生成臨時快照文件，完成後對原有文件進行原子替換。
5. 進程發送信號給父進程表示完成，父進程更新統計信息。

save m n規則

save m n規則表示每隔m秒，redis中有n個鍵改變則自動觸發bgsave，在redis.conf文件中可以進行配置，並且可以組合使用。

RDB持久化配置：

save m nsave 900 1 900秒內至少有1個key被改變則做一次快照save 60 10000 60秒內至少有10000個key被改變則做一次快照rdb持久化存儲資料庫文件名，默認為dump.rdbstop-write-on-bgsave-error yes 在寫入文件和讀取文件時是否開啟rdb文件檢查，檢查是否有無損壞，如果在啟動是檢查發現損壞，則停止啟動。dir &34;是否開啟RDB文件壓縮，該功能可以節約磁碟空間

優點

1. RDB 是一個非常緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數據集。這種文件非常適合用於進行備份：比如說，你可以在最近的 24 小時內，每小時備份一次 RDB 文件，並且在每個月的每一天，也備份一個 RDB 文件。這樣的話，即使遇上問題，也可以隨時將數據集還原到不同的版本。
2. RDB 非常適用於災難恢復（disaster recovery）：它只有一個文件，並且內容都非常緊湊，可以（在加密後）將它傳送到別的數據中心，或者亞馬遜 S3 中。
3. RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁碟 I/O 操作。
4. RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快

缺點

1. 如果你需要儘量避免在伺服器故障時丟失數據，那麼 RDB 不適合你。雖然 Redis 允許你設置不同的保存點（save point）來控制保存 RDB 文件的頻率， 但是， 因為RDB 文件需要保存整個數據集的狀態， 所以它並不是一個輕鬆的操作。因此你可能會至少 5 分鐘才保存一次 RDB 文件。在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。
2. 每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工作。在數據集比較龐大時， fork()可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端；如果數據集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失。

2. AOF

redis還提供了AOF(Append Only File)，將每次的命令追加到磁碟文件中。當伺服器出現故障時，從文件中讀取丟失數據時間點之後的命令，重新執行一遍命令達到恢復的目的。

redis默認是關閉AOF持久化的，需要通過配置appendonlyfile為yes開啟，我們修改配置文件或者在命令行直接使用config set修改，再用config rewrite同步到配置文件。通過客戶端修改好處是不用重啟redis，AOF持久化直接生效。

AOF工作流程：

1. 追加寫入redis將每一條命令先添加到緩存區aof_buf，而不是直接寫入磁碟，然後根據同步策略將命令一次性寫入磁碟。這樣做可以減少磁碟I/O次數，提高性能。
2. 同步命令磁碟當命令在緩存區中後，redis根據策略將命令寫入磁碟。redis提供了三種策略，由配置參數appendfsync決定，下面是每種策略的含義：no：不使用fsync方法同步，而是交給作業系統write函數去執行同步操作，在linux作業系統中大約每30秒刷一次緩衝。這種情況下，緩衝區數據同步不可控，並且在大量的寫操作下，aof_buf緩衝區會堆積會越來越嚴重，一旦redis出現故障，數據丟失嚴重。always：這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因為每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬碟的使用壽命會降低。everysec：數據將使用調用作業系統write寫入文件，並使用fsync每秒一次從內核刷新到磁碟。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。
3. 文件重寫當開啟的AOF時，隨著時間推移，AOF文件會越來越大,當然redis也對AOF文件進行了優化，即觸發AOF文件重寫條件的時候，redis將使用bgrewriteaof對AOF文件進行重寫。這樣的好處在於減少AOF文件大小，同時有利於數據的恢復。相當於對AOF文件進行了一次壓縮。下面是重寫的一些策略：重複或無效的命令不寫入文件過期的數據不再寫入文件多條命令合併寫入（當多個命令能合併一條命令時候會對其優化合併作為一個命令寫入，例如「RPUSH list1 a RPUSH list1 b&AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫,4.0默認配置64mb。auto-aof-rewrite-percentage 100no：不使用fsync方法同步，而是交給作業系統write函數去執行同步操作，在linux作業系統中大約每30秒刷一次緩衝。這種情況下，緩衝區數據同步不可控，並且在大量的寫操作下，aof_buf緩衝區會堆積會越來越嚴重，一旦redis出現故障，數據everysec：數據將使用調用作業系統write寫入文件，並使用fsync每秒一次從內核刷新到磁碟。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。aof-load-truncated yes如果aof-load-truncated設置為yes，則加載截斷的AOF文件，Redis伺服器啟動發出日誌以通知用戶該事件。yes開啟AOF，no關閉AOFappendfilename appendonly.aofRDB文件和AOF文件存放目錄

   優點

   1. 使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。AOF 的默認策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，並且就算發生故障停機，也最多只會丟失一秒鐘的數據（ fsync 會在後臺線程執行，所以主線程可以繼續努力地處理命令請求）。
   2. AOF 文件是一個只進行追加操作的日誌文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日誌因為某些原因而包含了未寫入完整的命令（比如寫入時磁碟已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
   3. Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫：重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裡面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。
   4. AOF 文件有序地保存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。導出（export） AOF 文件也非常簡單：舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止伺服器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。

   缺點

   1. 對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
   2. 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
   3. AOF 在過去曾經發生過這樣的 bug ：因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。（舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件裡為這種情況添加了測試：它們會自動生成隨機的、複雜的數據集， 並通過重新載入這些數據來確保一切正常。雖然這種 bug 在 AOF 文件中並不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的

   3. 混合方式

   混合方式就是將AOF和RDB混合使用，同時結合RDB持久化以及AOF持久化混合寫入AOF文件。這樣做的好處是可以結合 rdb 和 aof 的優點, 快速加載同時避免丟失過多的數據，缺點是 aof 裡面的 rdb 部分就是壓縮格式不再是 aof 格式，可讀性差。

   4.0版本的混合持久化默認關閉的，通過aof-use-rdb-preamble配置參數控制，yes則表示開啟，no表示禁用，默認是禁用的，可通過config set修改。

   混合持久化同樣也是通過bgrewriteaof完成的，不同的是當開啟混合持久化時，fork出的子進程先將共享的內存副本全量的以RDB方式寫入aof文件，然後再將重寫緩衝區的增量命令以AOF方式寫入到文件，寫入完成後通知主進程更新統計信息，並將新的含有RDB格式和AOF格式的AOF文件替換舊的的AOF文件。簡單的說：新的AOF文件前半段是RDB格式的全量數據後半段是AOF格式的增量數據

   當我們開啟了混合持久化時，啟動redis依然優先加載aof文件，aof文件加載可能有兩種情況如下：

   aof文件開頭是rdb的格式, 先加載 rdb內容再加載剩餘的 aof。
   aof文件開頭不是rdb的格式，直接以aof格式加載整個文件。

   總結

   

   ---

   關注我，私信回復【資料】即可領取視頻中java相關資料以及一份227頁最新的bat大廠面試寶典

   最後

   歡迎大家一起交流，喜歡文章記得關注我點個讚喲，感謝支持！