文章目錄
1.Redis持久化兩種方式：
- RDB：在指定的時間間隔能對你的數據進行快照存儲。
- AOF：記錄每次對服務器寫的操作,當服務器重啓的時候會重新執行這些命令來恢復原始的數據。
2.redis配置文件
進入redis/bin，打開redis.conf文件，找到如下配置行：
2.1RDB的持久化配置
################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
# save ""
# 時間策略
save 900 1
save 300 10
save 60 10000
# 如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-error yes
# 是否壓縮
rdbcompression yes
# 導入時是否檢查
rdbchecksum yes
# The filename where to dump the DB RDB文件名，默認爲dump.rdb。
dbfilename dump.rdb
# The working directory.文件存放的目錄，AOF文件同樣存放在此目錄下。默認爲當前工作目錄。
dir ./
配置其實非常簡單，這裏說一下持久化的時間策略具體是什麼意思。
save 900 1 表示900s內如果有1條是寫入命令，就觸發產生一次快照，可以理解爲就進行一次備份
save 300 10 表示300s內有10條寫入，就產生快照
stop-writes-on-bgsave-error yes 這個配置也是非常重要的一項配置，這是當備份進程出錯時，主進程就停止接受新的寫入操作，是爲了保護持久化的數據一致性問題。如果自己的業務有完善的監控系統，可以禁止此項配置， 否則請開啓。
當然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最後一行寫上：save “”
2.1.1優點
RDB文件是一個很簡潔的單文件，它保存了某個時間點的Redis數據，很適合用於做備份。你可以設定一個時間點對RDB文件進行歸檔，這樣就能在需要的時候很輕易的把數據恢復到不同的版本。
基於上面所描述的特性，RDB很適合用於災備。單文件很方便就能傳輸到遠程的服務器上。
RDB的性能很好，需要進行持久化時，主進程會fork一個子進程出來，然後把持久化的工作交給子進程，自己不會有相關的I/O操作。
比起AOF，在數據量比較大的情況下，RDB的啓動速度更快。
2.1.2缺點
RDB容易造成數據的丟失。假設每5分鐘保存一次快照，如果Redis因爲某些原因不能正常工作，那麼從上次產生快照到Redis出現問題這段時間的數據就會丟失了。
RDB使用fork()產生子進程進行數據的持久化，如果數據比較大的話可能就會花費點時間，造成Redis停止服務幾毫秒。如果數據量很大且CPU性能不是很好的時候，停止服務的時間甚至會到1秒。
2.2AOF的持久化配置
快照並不是很可靠。如果你的電腦突然宕機了，或者電源斷了，又或者不小心殺掉了進程，那麼最新的數據就會丟失。而AOF文件則提供了一種更爲可靠的持久化方式。每當Redis接受到會修改數據集的命令時，就會把命令追加到AOF文件裏，當你重啓Redis時，AOF裏的命令會被重新執行一次，重建數據。
# 是否開啓aof
appendonly yes
# 文件名稱
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重寫期間是否同步
no-appendfsync-on-rewrite no
# 重寫觸發配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加載aof時如果有錯如何處理
aof-load-truncated yes
# 文件重寫策略
aof-rewrite-incremental-fsync yes
AOF持久化策略(默認每秒)：
appendfsync always (同步持久化，每次發生數據變更會被立即記錄到磁盤，性能差但數據完整性比較好)
appendfsync everysec (異步操作，每秒記錄，如果一秒鐘內宕機，有數據丟失)
appendfsync no （將緩存回寫的策略交給系統，linux 默認是30秒將緩衝區的數據回寫硬盤的）
2.2.1 優點
比RDB可靠。你可以制定不同的fsync策略：不進行fsync、每秒fsync一次和每次查詢進行fsync。默認是每秒fsync一次。這意味着你最多丟失一秒鐘的數據。
AOF日誌文件是一個純追加的文件。就算是遇到突然停電的情況，也不會出現日誌的定位或者損壞問題。甚至如果因爲某些原因（例如磁盤滿了）命令只寫了一半到日誌文件裏，我們也可以用redis-check-aof這個工具很簡單的進行修復。
當AOF文件太大時，Redis會自動在後臺進行重寫。重寫很安全，因爲重寫是在一個新的文件上進行，同時Redis會繼續往舊的文件追加數據。新文件上會寫入能重建當前數據集的最小操作命令的集合。當新文件重寫完，Redis會把新舊文件進行切換，然後開始把數據寫到新文件上。
AOF把操作命令以簡單易懂的格式一條接一條的保存在文件裏，很容易導出來用於恢復數據。例如我們不小心用FLUSHALL命令把所有數據刷掉了，只要文件沒有被重寫，我們可以把服務停掉，把最後那條命令刪掉，然後重啓服務，這樣就能把被刷掉的數據恢復回來。
2.2.2缺點
在相同的數據集下，AOF文件的大小一般會比RDB文件大。
在某些fsync策略下，AOF的速度會比RDB慢。通常fsync設置爲每秒一次就能獲得比較高的性能，而在禁止fsync的情況下速度可以達到RDB的水平。
在過去曾經發現一些很罕見的BUG導致使用AOF重建的數據跟原數據不一致的問題
2.3 RDB與AOF的選擇：
做備份：當數據量大，且對恢復速度有要求，並且數據的一致性要求不高的話，可以只使用RDB
只做緩存：不用開啓任何的持久化方式
兩者都開啓的建議：RDB數據不實時，同時使用兩者時服務器只會找AOF文件，可不可以只使用AOF?建議不要，因爲RDB更適合備份數據庫(AOF在不斷變化，不好備份)，快速重啓，而且不會又AOF可能潛在的BUG,留作萬一的手段。
3.備份
建議的備份方法：
創建一個定時任務，每小時和每天創建一個快照，保存在不同的文件夾裏。
定時任務運行時，把太舊的文件進行刪除。例如只保留48小時的按小時創建的快照和一到兩個月的按天創建的快照。
每天確保一次把快照文件傳輸到數據中心外的地方進行保存，至少不能保存在Redis服務所在的服務器。
項目中有時候會出現項目上線了，發現數據有錯誤，把緩存數據污染了，此時可以選擇備份數據，比如項目上線前某個時間的備份數據進行數據恢復。