redis持久化RDB（資料可能不夠完整）和AOF
官方推薦兩個都啟用。
如果對資料不敏感，可以選單獨用RDB。
不建議單獨用 AOF，因為可能會出現Bug。
如果只是做純記憶體快取，可以都不用。
同時開啟RDB和AOF，系統預設取AOF儲存下來的資料（資料不會丟失）
RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢？
建議不要，因為RDB更適合用於備份資料庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
RDB:修改/etc下的redis.conf
save 30 5
AOF:將/etc/redis.conf中的appendonly改為yes
appendonly yes
效能建議：
RDB：因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則
AOF：只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值。
修改/etc/redis.conf（auto-aof-rewrite-percentage：檔案達到100%時開始重寫 auto-aof-rewrite-min-size：最開始達到最小檔案64MB值開始重寫。）
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
RDB：在指定的時間間隔中將記憶體中的資料集快照（關於指定資料集合的一個完全可用拷貝，該拷貝包括相應資料在某個時間點（拷貝開始的時間點）的映像）寫入磁碟中。
恢復是將快照檔案讀取到記憶體中。
優勢：
適合大規模的資料恢復
對資料完整性和一致性要求不高更適合使用
節省磁碟空間
恢復速度快
劣勢：
Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮
雖然Redis在fork時使用了寫時拷貝技術,但是如果資料龐大時還是比較消耗效能。
在備份週期在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最後一次快照後的所有修改。
修改/etc下的redis.conf（30秒中如果有5個key改變就進行持久化操作，將資料集存入redis目錄中的dump.rdb檔案中（也可以修改路徑和檔名））
達到閾值才會將閾值之內的數持久化（例如修改8個key，只有5個key會持久化）
# save 3600 1
# save 300 100
# save 60 10000
save 30 5
備份資料集為dump.rdb.bak
cp dump.rdb dump.rdb.bak
刪除了原本資料集
rm -rf dump.rdb
在資料集丟失情況將備份作為主資料集（改名）
mv dump.rdb.bak dump.rdb
Redis 會單獨建立( fork )一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。
整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能如果需要進行大規模資料的恢復，
且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。（在redis掛掉後資料會丟失，存入不了）
AOF：以日誌的形式來記錄每個寫操作（增量儲存），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案，
redis啟動之初會讀取該檔案重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作
優勢
備份機制更穩健，丟失資料概率更低。
可讀的日誌文字，通過操作AOF穩健，可以處理誤操作。
劣勢
比起RDB佔用更多的磁碟空間。
恢復備份速度要慢。
每次讀寫都同步的話，有一定的效能壓力。
存在個別Bug，造成恢復不能。
將/etc/redis.conf中的appendonly改為yes
appendonly yes
esc :wq
可以通過命令ll（LL）檢視檔案詳情發現aof新建立了一個儲存檔案appendonly.aof
ll
當appendonly.aof其中的內容出錯時，啟動不了redis，會顯示連線失敗，可以修復appendonly.aof檔案
redis-check-aof --fix appendonly.aof
Rewrite壓縮（重寫）
AOF採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制, 當AOF檔案的大小超過所設定的閾值時，
Redis就會啟動AOF檔案的內容壓縮， 只保留可以恢復資料的最小指令集.可以使用命令bgrewriteaof
例如：檔案達到70MB開始重寫，降到50MB，下次什麼時候開始重寫？100MB
重寫流程與RDB中fork的操作一致
AOF同步頻率設定
appendfsync always
始終同步，每次Redis的寫入都會立刻記入日誌；效能較差但資料完整性比較好
appendfsync everysec
每秒同步，每秒記入日誌一次，如果宕機，本秒的資料可能丟失。
appendfsync no
redis不主動進行同步，把同步時機交給作業系統。