前面已經總結了Redis 的安裝和使用，大家可以這這里查看Redis 系列文章：https://www.cnblogs.com/zhangweizhong/category/771056.html
今天講下Redis 的持久化。
redis跟memcached類似，都是內存數據庫，不過redis支持數據持久化，也就是說redis可以將內存中的數據同步到磁盤來持久化，以確保redis 的數據安全。
redis持久化的兩種方式
redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。
RDB，簡而言之，就是將存儲的數據快照的方式存儲到磁盤上，
AOF，則是將redis執行過的所有寫指令記錄下來，通過write函數追加到AOF文件的末尾。在下次redis重新啟動時，只要把這些寫指令從前到后再重復執行一遍，就可以實現數據恢復了。
其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優先采用AOF方式來進行數據恢復，這是因為AOF方式的數據恢復完整度更高。
如果你沒有數據持久化的需求，也完全可以關閉RDB和AOF方式，這樣的話，redis將變成一個純內存數據庫，就像memcache一樣。
RDB
RDB（Redis DataBase），是將redis某一時刻的數據持久化到磁盤中，是一種快照式的持久化方法。默認的文件名為dump.rdb。
redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，才會用這個臨時文件替換上次持久化好的文件，以確保數據完整可用。
RDB的持久化配置
# 時間策略 save 900 1 save 300 10 save 60 10000 # 文件名稱 dbfilename dump.rdb # 文件保存路徑 dir /home/work/app/redis/data/ # 如果持久化出錯，主進程是否停止寫入 stop-writes-on-bgsave-error yes # 是否壓縮 rdbcompression yes # 導入時是否檢查 rdbchecksum yes
配置其實非常簡單，這里說一下持久化的時間策略具體是什么意思。
save 900 1表示900s內如果有1條是寫入命令，就觸發產生一次快照，可以理解為就進行一次備份save 300 10表示300s內有10條寫入，就產生快照
下面的類似，那么為什么需要配置這么多條規則呢？因為Redis每個時段的讀寫請求肯定不是均衡的，為了平衡性能與數據安全，我們可以自由定制什么情況下觸發備份。所以這里就是根據自身Redis寫入情況來進行合理配置。
stop-writes-on-bgsave-error yes 這個配置也是非常重要的一項配置，這是當備份進程出錯時，主進程就停止接受新的寫入操作，是為了保護持久化的數據一致性問題。如果自己的業務有完善的監控系統，可以禁止此項配置， 否則請開啟。
關於壓縮的配置 rdbcompression yes ，建議沒有必要開啟，畢竟Redis本身就屬於CPU密集型服務器，再開啟壓縮會帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。
當然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行寫上：save ""
AOF
AOF（Append Only File），即只允許追加不允許改寫的文件。
Redis會將收到的每一個寫操作（如SET等）通過write函數追加到AOF文件的末尾。默認的AOF持久化策略是每秒鍾fsync一次（把緩存中的寫指令記錄到磁盤中）。當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
還是重點解釋一些關鍵的配置：
appendfsync everysec 它其實有三種模式:
- always：把每個寫命令都立即同步到aof，很慢，但是很安全
- everysec：每秒同步一次，是折中方案
- no：redis不處理交給OS來處理，非常快，但是也最不安全
一般情況下都采用 everysec 配置，這樣可以兼顧速度與安全，最多損失1s的數據。
aof-load-truncated yes 如果該配置啟用，在加載時發現aof尾部不正確是，會向客戶端寫入一個log，但是會繼續執行，如果設置為 no ，發現錯誤就會停止，必須修復后才能重新加載。
但AOF方式是將所有的命令記錄下來，所以AOF文件要比RDB文件的體積大。而且，恢復速度也要慢於RDB方式。
redis提供了bgrewriteaof命令，會重新生成一個全新的AOF文件，其中便包括了可以恢復現有數據的最少的命令集。
需要注意到是重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。
如何選擇RDB和AOF
對於我們應該選擇RDB還是AOF，取決於具體的應用場景，官方的建議是兩個同時使用。這樣可以提供更可靠的持久化方案。