Redis的高性能是由於其將所有數據都存儲在了內存中，爲了使Redis在重啓之後仍能保證數據不丟失，需要將數據從內存中同步到硬盤中，這一過程就是持久化。
Redis支持兩種方式的持久化,可以單獨使用其中一種或將二者結合使用。
RDB持久化（默認支持，無需配置）
該機制是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。
AOF持久化
該機制將以日誌的形式記錄服務器所處理的每一個寫操作，在Redis服務器啓動之初會讀取該文件來重新構建數據庫，以保證啓動後數據庫中的數據是完整的。
無持久化
我們可以通過配置的方式禁用Redis服務器的持久化功能，這樣我們就可以將Redis視爲一個功能加強版的Memcached(一個自由開源的，高性能，分佈式內存對象緩存系統)了。
RDB持久化機制
RDB持久化機制優點
一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這對於文件備份而言是非常完美的。
RDB持久化機制缺點
1.如果想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。因爲系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
2.由於RDB是通過fork子進程來協助完成數據持久化工作的，因此，如果當數據集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘。
快照與備份
快照是數據存儲的某一時刻的狀態記錄。
備份則是數據存儲的某一個時刻的副本。
快照觸發條件
1.客戶端執行命令save和bgsave會生成快照；
2.根據配置文件save m n規則進行自動快照；
3.主從複製時，從庫全量複製同步主庫數據，此時主庫會執行bgsave命令進行快照；
4.客戶端執行數據庫清空命令FLUSHALL時候，觸發快照；
5.客戶端執行shutdown關閉redis時，觸發快照；
RDB持久化機制的配置
①save m n
配置快照(rdb)觸發規則，格式：save <seconds> <changes>
save 900 1 900秒內至少有1個key被改變則做一次快照
save 300 10 300秒內至少有10個key被改變則做一次快照
save 60 10000 60秒內至少有10000個key被改變則做一次快照
#關閉該規則使用save “ ”
②dbfilename dump.rdb
RDB持久化存儲數據庫文件名，默認爲dump.rdb
③stop-write-on-bgsave-error yes
yes代表當使用bgsave命令持久化出錯時候停止寫RDB快照文件,no表明忽略錯誤繼續寫文件。
④rdbchecksum yes
在寫入文件和讀取文件時是否開啓rdb文件檢查，檢查是否有無損壞，如果在啓動是檢查發現損壞，則停止啓動。
⑤dir "./"
數據文件存放目錄，rdb快照文件和aof文件都會存放至該目錄，請確保有寫權限
⑥rdbcompression yes
是否開啓RDB文件壓縮，該功能可以節約磁盤空間。
AOF持久化機制
當redis存儲非臨時數據時，爲了降低redis故障而引起的數據丟失，redis提供了AOF(Append Only File)持久化，從單詞意思講，將命令追加到文件。AOF可以將Redis執行的每一條寫命令追加到磁盤文件(appendonly.aof)中
在redis啓動時候優先選擇從AOF文件恢復數據。由於每一次的寫操作，redis都會記錄到文件中，所以開啓AOF持久化會對性能有一定的影響
AOF持久化數據丟失更少，其消耗內存更少(RDB方式執行bgsave會有內存拷貝)
開啓AOF持久化
默認情況下，redis是關閉了AOF持久化，開啓AOF通過配置appendonly爲yes開啓。將appendonly修改爲yes，開啓aof持久化機制，默認會在目錄下產生一個appendonly.aof文件。修改配置文件或者在命令行直接使用config set修改，再用config rewrite同步到配置文件。通過客戶端修改好處是不用重啓redis，AOF持久化直接生效。
config get appendonly 查詢配置狀態
config set appendonly yes 修改配置，命令生效了，但配置文件裏沒有生效
config rewrite 寫入到redis.conf中，配置文件生效
AOF配置
appendfsync always 每執行一次更新命令，持久化一次
appendfsync everysec 每秒鐘持久化一次
appendfsync no 不持久化
RDB-AOF混合持久化
通過aof-use-rdb-preamble配置參數控制，yes則表示開啓，no表示禁用，默認是禁用的，可通過config set修改。
