1、 快照的方式持久化到磁盤
自動(dòng)持久化規(guī)則配置
save 900 1
save 300 10
save 60 10000
上面的配置規(guī)則意思如下:
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
redis也可以關(guān)閉自動(dòng)持久化，注釋掉這些save配置，或者save “”
如果后臺(tái)保存到磁盤發(fā)生錯(cuò)誤,將停止寫操作.
stop-writes-on-bgsave-error yes
使用LZF壓縮rdb文件,這會(huì)耗CPU, 但是可以減少磁盤占用.
rdbcompression yes
保存rdb和加載rdb文件的時(shí)候檢驗(yàn)，可以防止錯(cuò)誤，但是要付出約10%的性能，可以關(guān)閉他，提高性能。
rdbchecksum yes
導(dǎo)出的rdb文件名
dbfilename dump.rdb
設(shè)置工作目錄, rdb文件會(huì)寫到該目錄, append only file也會(huì)存儲(chǔ)在該目錄下.
dir ./
Redis自動(dòng)快照保存到磁盤或者調(diào)用bgsave，是后臺(tái)進(jìn)程完成的，其他客戶端仍然和可以讀寫redis服務(wù)器，后臺(tái)保存快照到磁盤會(huì)占用大量?jī)?nèi)存。調(diào)用save保存內(nèi)存中的數(shù)據(jù)到磁盤，將阻塞客戶端請(qǐng)求，直到保存完畢。
調(diào)用shutdown命令，Redis服務(wù)器會(huì)先調(diào)用save，所有數(shù)據(jù)持久化到磁盤之后才會(huì)真正退出。
對(duì)于數(shù)據(jù)丟失的問題：
如果服務(wù)器crash，從上一次快照之后的數(shù)據(jù)將全部丟失。所以在設(shè)置保存規(guī)則的時(shí)候，要根據(jù)實(shí)際業(yè)務(wù)設(shè)置允許的范圍。
如果對(duì)于數(shù)據(jù)敏感的業(yè)務(wù)，在程序中要使用恰當(dāng)?shù)娜罩?，在服?wù)器crash之后，通過日志恢復(fù)數(shù)據(jù)。
2、 Append-only file 的方式持久化

另外一種方式為遞增的方式,將會(huì)引起數(shù)據(jù)變化的操作, 持久化到文件中, 重啟redis的時(shí)候,通過操作命令,恢復(fù)數(shù)據(jù).

每次執(zhí)行寫操作命令之后,都會(huì)將數(shù)據(jù)寫到server.aofbuf中。
# appendfsync always
appendfsync everysec
# appendfsync no

當(dāng)配置為always的時(shí)候，每次server.aofbuf中的數(shù)據(jù)寫入到文件之后,才會(huì)返回給客戶端，這樣可以保證數(shù)據(jù)不丟，但是頻繁的IO操作，會(huì)降低性能。

everysec每秒寫一次，這可能會(huì)丟失一秒內(nèi)的操作。

aof最大的問題就是隨著時(shí)間append file會(huì)變的很大，所以我們需要bgrewriteaof命令重新整理文件，只保留最新的kv數(shù)據(jù)。