對於Redis來說是儲存在緩衝之中的,因此快取資料丟失問題一直是程式員們相當關注的話題,因此對緩衝中的資料定時進行持久化的必要性就相當突出了,以下是Redis持久化的相關配置:
1 第一種: RDB持久化方式
1.1概述
預設redis是會以快照的形式將資料持久化到磁碟的(一個二進位檔案,dump.rdb,這個檔案名稱字可以指定),在設定檔中的格式是:save N M表示在N秒之內,redis至少發生M次修改則redis抓快照到磁碟。當然我們也可以手動執行save或者bgsave(非同步)做快照。
1.2實現機制
當redis需要做持久化時,redis會fork一個子進程;子進程將資料寫到磁碟上一個臨時RDB檔案中;當子進程完成寫臨時檔案後,將原來的RDB替換掉,這樣的好處就是可以copy-on-write
1.3 相關配置
redis.conf設定檔:
1)
# save ""
save 900 1
save 300 10
save 60 10000
2)
# The filename where to dump the DB
dbfilename dump.rdb
3)
# Note that you must specify a directoryhere, not a file name.
dir ./
2 第二種:AOF持久化方式
2.1概述
還有一種持久化方法是Append-only:filesnapshotting方法在redis異常死掉時,最近的資料會丟失(遺失資料的多少視你save策略的配置),所以這是它最大的缺點,當業務量很大時,丟失的資料是很多的。Append-only方法可以做到全部資料不丟失,但redis的效能就要差些。AOF就可以做到全程持久化,只需要在設定檔中開啟(預設是no),appendonly yes開啟AOF之後,redis每執行一個修改資料的命令,都會把它添加到aof檔案中,當redis重啟時,將會讀取AOF檔案進行“重放”以恢複到redis關閉前的最後時刻。
LOG Rewriting隨著修改資料的執行AOF檔案會越來越大,其中很多內容記錄某一個key的變化情況。因此redis有了一種比較有意思的特性:在後台重建AOF檔案,而不會影響client端操作。在任何時候執行BGREWRITEAOF命令,都會把當前記憶體中最短序列的命令寫到磁碟,這些命令可以完全構建當前的資料情況,而不會存在多餘的變化情況(比如狀態變化,計數器變化等),縮小的AOF檔案的大小。所以當使用AOF時,redis推薦同時使用BGREWRITEAOF。
AOF檔案重新整理的方式,有三種,參考配置參數appendfsync :appendfsync always每提交一個修改命令都調用fsync重新整理到AOF檔案,非常非常慢,但也非常安全;appendfsynceverysec每秒鐘都調用fsync重新整理到AOF檔案,很快,但可能會丟失一秒以內的資料;appendfsync no依靠OS進行重新整理,redis不主動重新整理AOF,這樣最快,但安全性就差。預設並推薦每秒重新整理,這樣在速度和安全上都做到了兼顧。
可能由於系統原因導致了AOF損壞,redis無法再載入這個AOF,可以按照下面步驟來修複:首先做一個AOF檔案的備份,複製到其他地方;修複原始AOF檔案,執行:$ redis-check-aof –fix ;可以通過diff –u命令來查看修複前後檔案不一致的地方;重啟redis服務。
2.2實現機制
1)Redis將資料庫做個快照,遍曆所有資料庫,將資料庫中的資料還原為跟用戶端發送來的指令的協議格式的字串,
2)然後Redis建立一個臨時檔案將這些快照資料儲存,待快照程式結束後將臨時檔案名稱修改為正常的aof檔案名稱,原有的檔案則自動丟棄。
由於在快照進行的過程中可能存在新增的命令修改了資料庫中的資料,則在快照程式結束後需要將新修改的資料追加到aof檔案中,後續的從用戶端過來的命令都會不斷根據不同的安全層級寫到磁碟裡面去。這樣就支援了即時的持久化,只是可能會有短時間內的資料丟失,對一般系統還是可以容忍的。
2.3 相關配置
redis 127.0.0.1:6380> config get*append*
1) "appendonly"
2) "yes"
3) "no-appendfsync-on-rewrite"
4) "no"
5) "appendfsync"
6) "everysec"
redis 127.0.0.1:6380> config get*aof*
1) "auto-aof-rewrite-percentage"
2) "100"
3) "auto-aof-rewrite-min-size"
4) "67108864"