# 詳解Redis持久化（RDB和AOF） #### 什麼是Redis持久化？ Redis讀寫速度快、效能優越是因為它將所有資料存在了記憶體中，然而，當Redis程序退出或重啟後，所有資料就會丟失。所以我們希望Redis能儲存資料到硬碟中，在Redis服務重啟之後，原來的資料能夠恢復，這個過程就叫持久化。 #### Redis持久化的兩種方式？RDB和AOF AOF：會將每次執行的命令及時儲存到硬碟中，實時性更好，丟失的資料更少 RDB：會根據指定的規則定時將記憶體中的資料儲存到硬碟中。 通常兩種方式結合使用，下面詳細介紹RDB和AOF #### AOF Append Only File，AOF會儲存伺服器執行的所有寫操作到日誌檔案中，在服務重啟以後，會執行這些命令來恢復資料。 日誌檔案預設為appendonly.aof，Redis以Redis協議格式將命令儲存至aof日誌檔案末尾，aof檔案還會被重寫，使aof檔案的體積不會大於儲存資料集狀態所需要的實際大小 預設情況下，aof沒有被開啟。需要在redis.conf開啟 ``` appendonly yes ``` 日誌檔名 ``` appendfilename "appendonly.aof" ``` 日誌檔案所在目錄（RDB日誌檔案也是在這裡） ``` dir ./ ``` fsync持久化策略 ``` appendfsync everysec ``` > always：命令寫入aof_buf後立即呼叫系統fsync操作同步到AOF檔案，fsync完成後執行緒返回。這種情況下，每次有寫命令都要同步到AOF檔案，硬碟IO成為效能瓶頸，Redis只能支援大約幾百TPS寫入，嚴重降低了Redis的效能；即便是使用固態硬碟（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。 > > no：命令寫入aof_buf後呼叫系統write操作，不對AOF檔案做fsync同步；同步由作業系統負責，通常同步週期為30秒。這種情況下，檔案同步的時間不可控，且緩衝區中堆積的資料會很多，資料安全性無法保證。 > > everysec：命令寫入aof_buf後呼叫系統write操作，write完成後執行緒返回；fsync同步檔案操作由專門的執行緒每秒呼叫一次。everysec是前述兩種策略的折中，是效能和資料安全性的平衡，因此是Redis的預設配置，也是我們推薦的配置。 其餘引數： ● no-appendfsync-on-rewrite no：在重寫 AOF 檔案的過程中，是否禁止 fsync。如果這個引數值設定為 yes（開啟），則可以減輕重寫 AOF 檔案時 CPU 和硬碟的負載，但同時可能會丟失重寫 AOF 檔案過程中的資料；需要在負載與安全性之間進行平衡。 ● auto-aof-rewrite-percentage 100：指定 Redis 重寫 AOF 檔案的條件，預設為 100，它會對比上次生成的 AOF 檔案大小。如果當前 AOF 檔案的增長量大於上次 AOF 檔案的 100%，就會觸發重寫操作；如果將該選項設定為 0，則不會觸發重寫操作。 ● auto-aof-rewrite-min-size 64mb：指定觸發重寫操作的 AOF 檔案的大小，預設為 64MB。如果當前 AOF 檔案的大小低於該值，此時就算當前檔案的增量比例達到了 auto-aof-rewrite-percentage 選項所設定的條件，也不會觸發重寫操作。換句話說，只有同時滿足以上這兩個選項所設定的條件，才會觸發重寫操作。 ● auto-load-truncated yes：當 AOF 檔案結尾遭到損壞時，Redis 在啟動時是否仍載入 AOF 檔案。 ##### AOF持久化的實現 （1）命令追加（append）：Redis 伺服器每執行一條寫命令，這條寫命令都會被追加到快取區 aof_buf 中。（避免每次執行的命令都直接寫入硬碟中，會導致硬碟 I/O 的負載過大，使得效能下降。） 命令追加的格式使用 Redis 命令請求的協議格式  （2）AOF 持久化檔案寫入（write）和檔案同步（sync）：根據 appendfsync 引數設定的不同的同步策略，將快取區 aof_buf 中的資料內容同步到硬碟中。 先了解作業系統的 write 和 fsync 函式。為了提高檔案的寫入效率，當用戶呼叫 write 函式將資料寫入檔案中時，作業系統會將這些資料暫存到一個記憶體快取區中，當這個快取區被填滿或者超過了指定時限後，才會將快取區中的資料寫入硬碟中，這樣做既提高了效率，又保證了安全性。 Redis 的伺服器程序是一個事件迴圈（loop），這個事件迴圈中的檔案事件負責接收客戶端的命令請求，處理之後，向客戶端傳送命令回覆；而其中的時間事件則負責執行像 serverCron 函式這樣需要定時執行的函式。 伺服器在處理檔案事件時，可能會執行客戶端傳送過來的寫命令，使得一些命令被追加到快取區 aof_buf 中。因此，在伺服器每次結束一個事件迴圈之前，都會呼叫 flushAppendOnlyFile 函式，來決定是否將快取區 aof_buf 中的資料寫入和儲存到 AOF 檔案中。 flushAppendOnlyFile 函式的執行與伺服器配置的 appendfsync 引數有關。 ##### AOF檔案的重寫 AOF檔案定期重寫，以達到壓縮的目的。 AOF檔案過於龐大，會影響Redis的寫入速度，在執行資料恢復時，也非常滿。AOF檔案重寫就是解決這個問題。 AOF 檔案重寫就是把 Redis 程序內的資料轉化為寫命令，然後同步到新的 AOF 檔案中。在重寫的過程中，Redis 伺服器會建立一個新的 AOF 檔案來替代現有的 AOF 檔案，新、舊兩個 AOF 檔案所儲存的資料庫狀態相同，但是新的 AOF 檔案不會包含冗餘命令。 AOF 檔案重寫並不會對舊的 AOF 檔案進行讀取、寫入操作，這個功能是通過讀取伺服器當前的資料庫狀態來實現的。 舉例說明： ​ 比如Redis使用五條rpush命令分別插入五種顏色 ``` rpush color 〝yellow〝 rpush color 〝green〝 ... ``` ​ AOF重寫後 ``` RPUSH color 〝yellow〝 〝green〝 〝black〝 〝pink〝〝white〝 ``` 所以AOF重寫的原理： ● AOF 檔案重寫功能會丟棄過期的資料，也就是過期的資料不會被寫入 AOF 檔案中。 ● AOF 檔案重寫功能會丟棄無效的命令，無效的命令將不會被寫入 AOF 檔案中。無效命令包括重複設定某個鍵值對時的命令、刪除某些資料時的命令等。 ● AOF 檔案重寫功能可以將多條命令合併為一條命令，然後寫入 AOF 檔案中。 怎麼觸發AOF重寫? ● 手動觸發：執行 BGREWRITEAOF 命令觸發 AOF 檔案重寫。該命令與 BGSAVE 命令相似，都是啟動（fork）子程序完成具體的工作，且都在啟動時阻塞。 ● 自動觸發：自動觸發 AOF 檔案重寫是通過設定 Redis 配置檔案中 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 引數的值，以及 aof_current_size 和 aof_base_size 狀態來確定何時觸發的。 auto-aof-rewrite-percentage 引數是在執行 AOF 檔案重寫時，當前 AOF 檔案的大小（aof_current_size）和上一次 AOF 檔案重寫時的大小（aof_base_size）的比值，預設為 100。 auto-aof-rewrite-min-size 引數設定了執行 AOF 檔案重寫時的最小體積，預設為 64MB。 ##### AOF檔案的後臺重寫： AOF重寫執行大量的寫入操作，就會使得這個函式的執行緒被長時間阻塞。Redis 伺服器使用單執行緒來處理命令請求。如果讓伺服器直接呼叫 aof_rewrite 重寫函式，那麼在 AOF 檔案重寫期間，伺服器將不能繼續執行其他命令，就會一直處於阻塞狀態。 Redis 將 AOF 檔案重寫程式放到了一個子程序中執行，這樣做的好處是： ● 子程序在執行 AOF 檔案重寫的過程中，Redis 伺服器程序可以繼續處理新的命令請求。 ● 子程序帶有伺服器程序的資料副本，使用子程序可以在使用鎖的情況下，保證資料的安全性。 使用子程序會導致資料庫狀態不一致，原因是：當子程序進行 AOF 檔案重寫的時候，Redis 伺服器可以繼續執行來自客戶端的命令請求，就會有新的命令對現有資料庫狀態進行修改，進而使得伺服器當前的資料庫狀態與重寫的 AOF 檔案所儲存的資料庫狀態不一致。 為了解決使用子程序導致資料庫狀態不一致的問題，Redis 伺服器設定了一個 AOF 檔案重寫快取區。這個 AOF 檔案重寫快取區在伺服器建立子程序之後開始使用，可以利用它來解決資料庫狀態不一致的問題。當 Redis 伺服器成功執行完一條寫命令後，它會同時將這條寫命令傳送給 AOF 檔案快取區（aof_buf）和 AOF 檔案重寫快取區。 子程序在執行 AOF 檔案重寫的過程中，伺服器程序的執行過程如下： （1）伺服器接收到來自客戶端的命令請求，併成功執行。 （2）伺服器將執行後的寫命令轉化為對應的協議格式，然後追加到 AOF 檔案快取區（aof_buf）中。 （3）伺服器再將執行後的寫命令追加到 AOF 檔案重寫快取區中。  有了 AOF 檔案重寫快取區，就可以保證資料庫狀態的一致性。AOF 檔案快取區的內容會被定期寫入和同步到 AOF 檔案中，AOF 檔案的寫入和同步不會因為 AOF 檔案重寫快取區的引入而受到影響。當伺服器建立子程序之後，伺服器執行的所有寫命令都會同時被追加到 AOF 檔案快取區和 AOF 檔案重寫快取區中。 如果子程序完成了 AOF 檔案重寫的工作，它就會發送一個完成訊號給父程序。當父程序接收到這個訊號後，就會呼叫訊號處理函式，繼續執行以下工作： （1）將 AOF 檔案重寫快取區中的所有內容寫入新的 AOF 檔案中。新的 AOF 檔案所儲存的資料庫狀態與伺服器當前的資料庫狀態保持一致。 （2）修改新的 AOF 檔案的檔名，新生成的 AOF 檔案將會覆蓋現有（舊）的 AOF 檔案，完成新、舊兩個檔案的互換。 在完成上述兩個步驟之後，就完成了一次 AOF 檔案後臺重寫工作。 在整個 AOF 檔案後臺重寫的過程中，只有在訊號處理函式執行的過程中，伺服器程序才會被阻塞，在其他時候不存在阻塞情況。 ##### AOF檔案恢復資料的過程 （1）建立一個偽客戶端，用於執行 AOF 檔案中的寫命令。這個偽客戶端是一個不帶網路連線的客戶端。因為只能在客戶端的上下文中才能執行 Redis 的命令，而在 AOF 檔案中包含了 Redis 伺服器啟動載入 AOF 檔案時所使用的所有命令，而不是網路連線，所以伺服器建立了一個不帶網路連線的偽客戶端來執行 AOF 檔案中的寫命令。 （2）讀取 AOF 檔案中的資料，分析並提取出 AOF 檔案所儲存的一條寫命令。 （3）使用偽客戶端執行被讀取出的寫命令。 （4）重複執行步驟（2）和（3），直到將 AOF 檔案中的所有命令讀取完畢，併成功執行為止。這個過程完成之後，就可以將伺服器的資料庫狀態還原為關閉之前的狀態。  如果在 Redis 伺服器啟動載入 AOF 檔案時，發現 AOF 檔案被損壞了，那麼伺服器會拒絕載入這個 AOF 檔案，以此來確保資料的一致性不被破壞。而 AOF 檔案被損壞的原因可能是程式正在對 AOF 檔案進行寫入與同步時，伺服器出現停機故障。如果 AOF 檔案被損壞了，則可以通過以下方法來修復。 ● 及時備份現有 AOF 檔案。 ● 利用 Redis 自帶的 redis-check-aof 程式，對原來的 AOF 檔案進行修復，命令如下： ● 使用 diff-u 來對比原始 AOF 檔案和修復後的 AOF 檔案，找出這兩個檔案的不同之處。 ● 修復 AOF 檔案之後，重啟 Redis 伺服器重新載入，進行資料恢復。 ##### AOF持久化的優劣 ● 使用 AOF 持久化會讓 Redis 持久化更長：通過設定不同的 fsync 策略來達到更長的持久化。具體有 3 種策略。 ● 相容性比較好：AOF 檔案是一個日誌檔案，它的作用是記錄伺服器執行的所有寫命令。當檔案因為某條寫命令寫入失敗時，可以使用 redis-check-aof 進行修復，然後繼續使用。 ● 支援後臺重寫：當 AOF 檔案的體積過大時，在後臺可以自動地對 AOF 檔案進行重寫，因此資料庫當前狀態的所有命令集合都會被重寫到 AOF 檔案中。重寫完成後，Redis 就會切換到新的 AOF 檔案，繼續執行寫命令的追加操作。 ● AOF 檔案易於讀取和載入：AOF 檔案儲存了對資料庫的所有寫命令，這些寫命令採用 Redis 協議格式追加到 AOF 檔案中，因此非常容易讀取和載入。 AOF 持久化具有以下缺點： ● AOF 檔案的體積會隨著時間的推移逐漸變大，導致在載入時速度會比較慢，進而影響資料庫狀態的恢復速度，效能快速下降。 ● 根據所使用的 fsync 策略，使用 AOF 檔案恢復資料的速度可能會慢於使用 RDB 檔案恢復資料的速度。 ● 因為 AOF 檔案的個別命令，可能會導致在載入時失敗，從而無法進行資料恢復。 #### RDB RDB 持久化生成的 RDB 檔案是一個經過壓縮的二進位制檔案，也可以稱之為快照檔案，通過該檔案可以還原生成 RDB 檔案時的資料庫狀態 在指定的時間間隔內，Redis 會自動將記憶體中的所有資料生成一份副本並存儲在硬碟上，這個過程就是「快照」。 ##### 快照怎麼生成 ● 根據 Redis 配置檔案 redis.conf 中的配置自動進行快照 ``` save 900 1 save 300 10 save 60 10000 save m n //時間 m 和被修改的鍵的個數 n ``` 當在時間 m 內被修改的鍵的個數大於 n 時，就會觸發 BGSAVE 命令，伺服器就會自動執行快照操作。 Redis 的 save m n 命令是通過 serverCron 函式、dirty 計數器及 lastsave 時間戳來實現的。 **serverCron 函式**：這是 Redis 伺服器的週期性操作函式，預設每隔 100 毫秒執行一次，它主要的作用是維護伺服器的狀態。其中一項工作就是判斷 save m n 配置的條件是否滿足，如果滿足就會觸發執行 BGSAVE 命令。 **dirty 計數器**：這是 Redis 伺服器維持的一種狀態，它主要用於記錄上一次執行 SAVE 或 BGSAVE 命令後，伺服器進行了多少次狀態修改（執行新增、刪除、修改等操作）；當 SAVE 或 BGSAVE 命令執行完成後，伺服器會將 dirty 重新設定為 0。dirty 計數器記錄的是伺服器進行了多少次狀態修改，而不是客戶端執行了多少次修改資料的命令。 **lastsave 時間戳**：主要用於記錄伺服器上一次成功執行 SAVE 或 BGSAVE 命令的時間，它是 Redis 伺服器維持的一種狀態。 dirty 計數器和 lastsave 時間戳屬性都儲存在伺服器狀態的 redisServer 結構中。 save m n 命令的實現原理：伺服器每隔 100 毫秒執行一次 serverCron 函式；serverCron 函式會遍歷 save m n 配置的儲存條件，判斷是否滿足。如果有一個條件滿足，就會觸發執行 BGSAVE 命令，進行快照儲存。 對於每個 save m n 條件，只有以下兩個條件同時滿足才算滿足： ➢ 當前伺服器時間減去 lastsave 時間戳大於 m。 ➢ 當前 dirty 計數器的個數大於等於 n。 ● 使用者在客戶端執行 SAVE 或 BGSAVE 命令時會觸發快照（手動觸發）。 ● 如果使用者定義了自動快照條件，則執行 FLUSHALL 命令也會觸發快照。 當執行 FLUSHALL 命令時，會清空資料庫中的所有資料。如果使用者定義了自動快照條件，則在使用 FLUSHALL 命令清空資料庫的過程中，就會觸發伺服器執行一次快照。 ● 如果使用者為 Redis 設定了主從複製模式，從節點執行全量複製操作，則主節點會執行 BGSAVE 命令，將生產的 RDB 檔案傳送給從節點完成快照操作。 ##### **快照的實現過程** （1）Redis 呼叫執行 fork 函式複製一份當前程序（父程序）的副本（子程序），也就是同時擁有父程序和子程序。 （2）父程序與子程序各自分工，父程序繼續處理來自客戶端的命令請求，而子程序則將記憶體中的資料寫到硬碟上的一個臨時 RDB 檔案中。 （3）當子程序把所有資料寫完後，也就表示快照生成完畢，此時舊的 RDB 檔案將會被這個臨時 RDB 檔案替換，這個舊的 RDB 檔案也會被刪除。這個過程就是一次快照的實現過程。 當 Redis 呼叫執行 fork 函式時，作業系統會使用寫時複製策略。也就是在執行 fork 函式的過程中，父、子程序共享同一記憶體資料，當父程序要修改某個資料時（執行一條寫命令），作業系統會將這個共享記憶體資料另外複製一份給子程序使用，以此來保證子程序的正確執行。因此，新的 RDB 檔案儲存的是執行 fork 函式過程中的記憶體資料。 寫時複製策略也保證了在執行 fork 函式的過程中生成的兩份記憶體副本在記憶體中的佔用量不會增加一倍。但是，在進行快照的過程中，如果寫操作比較多，就會造成 fork 函式執行前後資料差異較大，此時會使得記憶體使用量變大。因為記憶體中不僅儲存了當前資料庫資料，還會儲存 fork 過程中的記憶體資料。 在進行快照生成的過程中，Redis 不會修改 RDB 檔案。只有當快照生成後，舊的 RDB 檔案才會被臨時 RDB 檔案替換，同時舊的 RDB 檔案會被刪除。在整個過程中，RDB 檔案是完整的，因此我們可以使用 RDB 檔案來實現 Redis 資料庫的備份。 #### RDB 檔案 預設情況下，Redis 將資料庫快照儲存在名為 dump.rdb 的檔案中。這個檔案可以修改，即AOF的dir和dbfilename 屬性 RDB 檔案結構：  在 RDB 檔案結構中，通常使用大寫字母表示常量，使用小寫字母表示變數和資料。 ● REDIS 常量：該常量位於 RDB 檔案的頭部，它儲存著「REDIS」5 個字元，它的長度是 5 位元組。在 Redis 伺服器啟動載入檔案時，程式會根據這 5 個字元判斷載入的檔案是不是 RDB 檔案。 ● db_version 常量：該常量用於記錄 RDB 檔案的版本號，它的值是一個用字串表示的整數，佔 4 位元組，注意區分它不是 Redis 的版本號。 ● databases 資料：它包含 0 個或多個數據庫，以及各個資料庫中的鍵值對資料。 如果它包含 0 個數據庫，也就是伺服器的資料庫狀態為空，那麼 databases 也是空的，其長度為 0 位元組；如果它包含多個數據庫，也就是伺服器的資料庫狀態不為空，那麼 databases 不為空，根據它所儲存的鍵值對的數量、型別和內容不同，其長度也是不一樣的。 如果 databases 不為空，則 RDB 檔案結構如圖  其中，SELECTDB 是一個常量，表示其後的資料庫編號，這裡的 0 和 1 是資料庫編號。 pairs 資料：它儲存了具體的鍵值對資訊，包括鍵（key）、值（value）、資料型別、內部編碼、過期資訊、壓縮資訊等。 SELECT 0 pairs 表示 0 號資料庫；SELECT 1 pairs 表示 1 號資料庫。當資料庫中有鍵值對時，RDB 檔案才會記錄該資料庫的資訊；而如果資料庫中沒有鍵值對，這一部分就會被 RDB 檔案省略。 ● EOF 常量：該常量是一個結束標誌，它標誌著 RDB 檔案的正文內容結束，其長度為 1 位元組。在載入 RDB 檔案時，如果遇到 EOF 常量，則表示資料庫中的所有鍵值對都已經載入完畢。 ● check_sum 變數：該變數用於儲存一個校驗和，這個校驗和是通過對 REDIS、db_version、databases、EOF 4 部分的內容進行計算得出的，是一個無符號整數，其長度為 8 位元組。 當伺服器載入 RDB 檔案時，會將 check_sum 變數中儲存的校驗和與載入資料時所計算出來的校驗和進行比對，從而判斷載入的 RDB 檔案是否被損壞，或者是否有錯誤。 ##### RDB檔案壓縮 在預設情況下，Redis 伺服器會自動對 RDB 檔案進行壓縮。在 Redis 配置檔案 redis.conf 中，預設開啟壓縮。配置如下：  Redis 採用 LZF 演算法進行 RDB 檔案壓縮。在壓縮 RDB 檔案時，不要誤認為是壓縮整個 RDB 檔案。實際上，對 RDB 檔案的壓縮只是針對資料庫中的字串進行的，並且只有當字串達到一定長度（20 位元組）時才會進行壓縮。 ##### RDB檔案的建立 SAVE 命令： 會阻塞 Redis 伺服器程序，此時 Redis 伺服器將不能繼續執行其他命令請求，直到 RDB 檔案建立完畢為止。 BGSAVE 命令： 會派生出一個子程序，交由子程序將記憶體中的資料儲存到硬碟中，建立 RDB 檔案；而 BGSAVE 命令的父程序可以繼續處理來自客戶端的命令請求。 執行 BGSAVE 命令會返回 Background saving started 資訊，但我們並不能確定 BGSAVE 命令是否已經成功執行，此時可以使用 LASTSAVE 命令來檢視相關資訊。 執行 LASTSAVE 命令返回一個 UNIX 格式的時間戳，表示最近一次 Redis 成功將資料儲存到硬碟中的時間。 ##### RDB檔案的載入 RDB 檔案只有在啟動伺服器的時候才會被載入。當啟動伺服器時，它會檢查 RDB 檔案是否存在，如果存在，就會自動載入 RDB 檔案。除此之外，RDB 檔案不會被載入，因為 Redis 中沒有提供用於載入 RDB 檔案的命令。 那麼先載入AOF檔案還是RDB檔案呢？ ● 如果在 Redis 配置檔案中開啟了 AOF 持久化（appendonly yes），那麼在啟動伺服器的時候會優先載入 AOF 檔案來還原資料庫狀態。 ● 如果在 Redis 配置檔案中關閉了 AOF 持久化（appendonly no），那麼在啟動伺服器的時候會優先載入 RDB 檔案來還原資料庫狀態。 ##### RDB檔案的配置 除了save m n、 dbfilename dump.rdb、 dir./ 還有 ● stop-writes-on-bgsave-error yes：當執行 BGSAVE 命令出現錯誤時，Redis 是否終止執行寫命令。引數的值預設被設定為 yes，表示當硬碟出現問題時，伺服器可以及時發現，及時避免大量資料丟失；當設定為 no 時，就算執行 BGSAVE 命令發生錯誤，伺服器也會繼續執行寫命令；當對 Redis 伺服器的系統設定了監控時，建議將該引數值設定為 no。 ● rdbcompression yes：是否開啟 RDB 壓縮檔案，預設為 yes 表示開啟，不開啟則設定為 no。 ● rdbchecksum yes：是否開啟 RDB 檔案的校驗，在伺服器進行 RDB 檔案的寫入與讀取時會用到它。預設設定為 yes。如果將它設定為 no，則在伺服器對 RDB 檔案進行寫入與讀取時，可以提升效能，但是無法確定 RDB 檔案是否已經被損壞。 ##### RDB 持久化的優劣 ● RDB 檔案是一個經過壓縮的二進位制檔案，檔案緊湊，體積較小，非常適用於進行資料庫資料備份。 ● RDB 持久化適用於災難恢復，而且恢復資料時的速度要快於 AOF 持久化。 ● Redis 採用 RDB 持久化可以很大程度地提升效能。父程序在儲存 RDB 檔案時會啟動一個子程序，將所有與儲存相關的功能交由子程序處理，而父程序可以繼續處理其他相關的操作。 RDB 持久化具有以下缺點： ● 在伺服器出現故障時，如果沒有觸發 RDB 快照執行，那麼它可能會丟失大量資料。RDB 快照的持久化方式決定了必然做不到實時持久化，會存在大量資料丟失。 ● 當資料量非常龐大時，在儲存 RDB 檔案的時候，伺服器會啟動一個子程序來完成相關的儲存操作。這項操作比較耗時，將會佔用太多 CPU 時間，從而影響伺服器的效能。 ● RDB 檔案存在相容性問題，老版本的 Redis 不支援新版本的 RDB