什么是Redis持久化

什么是Redis持久化,就是將內存數據保存到硬盤。

Redis 持久化存儲 (AOF 與 RDB 兩種模式)

RDB持久化

RDB 是以二進制文件，是在某個時間 點將數據寫入一個臨時文件，持久化結束后，用這個臨時文件替換上次持久化的文件，達到數據恢復。
優點：使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 redis 的高性能
缺點：RDB 是間隔一段時間進行持久化，如果持久化之間 redis 發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候

這里說的這個執行數據寫入到臨時文件的時間點是可以通過配置來自己確定的，通過配置redis 在 n 秒內如果超過 m 個 key 被修改這執行一次 RDB 操作。這個操作就類似于在這個時間點來保存一次 Redis 的所有數據，一次快照數據。所有這個持久化方法也通常叫做 snapshots。

RDB 默認開啟，redis.conf 中的具體配置參數如下；

#dbfilename：持久化數據存儲在本地的文件 dbfilename dump.rdb #dir：持久化數據存儲在本地的路徑，如果是在/redis/redis-3.0.6/src下啟動的redis-cli，則數據會存儲在當前src目錄下 dir ./ ##snapshot觸發的時機，save ##如下為900秒后，至少有一個變更操作，才會snapshot ##對于此值的設置，需要謹慎，評估系統的變更操作密集程度 ##可以通過“save “””來關閉snapshot功能 #save時間，以下分別表示更改了1個key時間隔900s進行持久化存儲；更改了10個key300s進行存儲；更改10000個key60s進行存儲。 save 900 1 save 300 10 save 60 10000 ##當snapshot時出現錯誤無法繼續時，是否阻塞客戶端“變更操作”，“錯誤”可能因為磁盤已滿/磁盤故障/OS級別異常等 stop-writes-on-bgsave-error yes ##是否啟用rdb文件壓縮，默認為“yes”，壓縮往往意味著“額外的cpu消耗”，同時也意味這較小的文件尺寸以及較短的網絡傳輸時間 rdbcompression yes

AOF持久化

Append-only file，將“操作 + 數據”以格式化指令的方式追加到操作日志文件的尾部，在 append 操作返回后(已經寫入到文件或者即將寫入)，才進行實際的數據變更，“日志文件”保存了歷史所有的操作過程；當 server 需要數據恢復時，可以直接 replay 此日志文件，即可還原所有的操作過程。AOF 相對可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 簡直異曲同工。AOF 文件內容是字符串，非常容易閱讀和解析。
優點：可以保持更高的數據完整性，如果設置追加 file 的時間是 1s，如果 redis 發生故障，最多會丟失 1s 的數據；且如果日志寫入不完整支持 redis-check-aof 來進行日志修復；AOF 文件沒被 rewrite 之前（文件過大時會對命令進行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）。
缺點：AOF 文件比 RDB 文件大，且恢復速度慢。

我們可以簡單的認為 AOF 就是日志文件，此文件只會記錄“變更操作”(例如：set/del 等)，如果 server 中持續的大量變更操作，將會導致 AOF 文件非常的龐大，意味著 server 失效后，數據恢復的過程將會很長；事實上，一條數據經過多次變更，將會產生多條 AOF 記錄，其實只要保存當前的狀態，歷史的操作記錄是可以拋棄的；因為 AOF 持久化模式還伴生了“AOF rewrite”。
AOF 的特性決定了它相對比較安全，如果你期望數據更少的丟失，那么可以采用 AOF 模式。如果 AOF 文件正在被寫入時突然 server 失效，有可能導致文件的最后一次記錄是不完整，你可以通過手工或者程序的方式去檢測并修正不完整的記錄，以便通過 aof 文件恢復能夠正常；同時需要提醒，如果你的 redis 持久化手段中有 aof，那么在 server 故障失效后再次啟動前，需要檢測 aof 文件的完整性。

AOF 默認關閉，開啟方法，修改配置文件 reds.conf：appendonly yes

##此選項為aof功能的開關，默認為“no”，可以通過“yes”來開啟aof功能 ##只有在“yes”下，aof重寫/文件同步等特性才會生效 appendonly yes ##指定aof文件名稱 appendfilename appendonly.aof ##指定aof操作中文件同步策略，有三個合法值：always everysec no,默認為everysec appendfsync everysec ##在aof-rewrite期間，appendfsync是否暫緩文件同步，"no"表示“不暫緩”，“yes”表示“暫緩”，默認為“no” no-appendfsync-on-rewrite no ##aof文件rewrite觸發的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才會觸發rewrite，默認“64mb”，建議“512mb” auto-aof-rewrite-min-size 64mb ##相對于“上一次”rewrite，本次rewrite觸發時aof文件應該增長的百分比。 ##每一次rewrite之后，redis都會記錄下此時“新aof”文件的大小(例如A)，那么當aof文件增長到A*(1 + p)之后 ##觸發下一次rewrite，每一次aof記錄的添加，都會檢測當前aof文件的尺寸。 auto-aof-rewrite-percentage 100

AOF 是文件操作，對于變更操作比較密集的 server，那么必將造成磁盤 IO 的負荷加重；此外 linux 對文件操作采取了“延遲寫入”手段，即并非每次 write 操作都會觸發實際磁盤操作，而是進入了 buffer 中，當 buffer 數據達到閥值時觸發實際寫入(也有其他時機)，這是 linux 對文件系統的優化，但是這卻有可能帶來隱患，如果 buffer 沒有刷新到磁盤，此時物理機器失效(比如斷電)，那么有可能導致最后一條或者多條 aof 記錄的丟失。通過上述配置文件，可以得知 redis 提供了 3 中 aof 記錄同步選項：

always：每一條 aof 記錄都立即同步到文件，這是最安全的方式，也以為更多的磁盤操作和阻塞延遲，是 IO 開支較大。

everysec：每秒同步一次，性能和安全都比較中庸的方式，也是 redis 推薦的方式。如果遇到物理服務器故障，有可能導致最近一秒內 aof 記錄丟失(可能為部分丟失)。

no：redis 并不直接調用文件同步，而是交給操作系統來處理，操作系統可以根據 buffer 填充情況 / 通道空閑時間等擇機觸發同步；這是一種普通的文件操作方式。性能較好，在物理服務器故障時，數據丟失量會因 OS 配置有關。

其實，我們可以選擇的太少，everysec 是最佳的選擇。如果你非常在意每個數據都極其可靠，建議你選擇一款“關系性數據庫”吧。
AOF 文件會不斷增大，它的大小直接影響“故障恢復”的時間, 而且 AOF 文件中歷史操作是可以丟棄的。AOF rewrite 操作就是“壓縮”AOF 文件的過程，當然 redis 并沒有采用“基于原 aof 文件”來重寫的方式，而是采取了類似 snapshot 的方式：基于 copy-on-write，全量遍歷內存中數據，然后逐個序列到 aof 文件中。因此 AOF rewrite 能夠正確反應當前內存數據的狀態，這正是我們所需要的；*rewrite 過程中，對于新的變更操作將仍然被寫入到原 AOF 文件中，同時這些新的變更操作也會被 redis 收集起來(buffer，copy-on-write 方式下，最極端的可能是所有的 key 都在此期間被修改，將會耗費 2 倍內存)，當內存數據被全部寫入到新的 aof 文件之后，收集的新的變更操作也將會一并追加到新的 aof 文件中，此后將會重命名新的 aof 文件為 appendonly.aof, 此后所有的操作都將被寫入新的 aof 文件。如果在 rewrite 過程中，出現故障，將不會影響原 AOF 文件的正常工作，只有當 rewrite 完成之后才會切換文件，因為 rewrite 過程是比較可靠的。*

觸發 rewrite 的時機可以通過配置文件來聲明，同時 redis 中可以通過 bgrewriteaof 指令人工干預。

redis-cli -h ip -p port bgrewriteaof

因為 rewrite 操作 /aof 記錄同步 /snapshot 都消耗磁盤 IO，redis 采取了“schedule”策略：無論是“人工干預”還是系統觸發，snapshot 和 rewrite 需要逐個被執行。

AOF rewrite 過程并不阻塞客戶端請求。系統會開啟一個子進程來完成。

AOF與RDB區別

AOF 和 RDB 各有優缺點，這是有它們各自的特點所決定：

RDB

RDB是在某個時間點將數據寫入一個臨時文件，持久化結束后，用這個臨時文件替換上次持久化的文件，達到數據恢復。?
優點：使用單獨子進程來進行持久化，主進程不會進行任何IO操作，保證了redis的高性能?
缺點：RDB是間隔一段時間進行持久化，如果持久化之間redis發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候

AOF

Append-only file，將“操作 + 數據”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已經寫入到文件或者即將寫入)，才進行實際的數據變更，“日志文件”保存了歷史所有的操作過程；當server需要數據恢復時，可以直接replay此日志文件，即可還原所有的操作過程。AOF相對可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log簡直異曲同工。AOF文件內容是字符串，非常容易閱讀和解析。?
優點：可以保持更高的數據完整性，如果設置追加file的時間是1s，如果redis發生故障，最多會丟失1s的數據；且如果日志寫入不完整支持redis-check-aof來進行日志修復；AOF文件沒被rewrite之前（文件過大時會對命令進行合并重寫），可以刪除其中的某些命令（比如誤操作的flushall）。?
缺點：AOF文件比RDB文件大，且恢復速度慢。

總結

以上是生活随笔為你收集整理的RedisRDB持久化机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。