摘要：Redis 對比 Memcache，還有一個最大的區別，就是 Redis 的數據持久化機制。Redis 數據持久化有兩種方式，AOF和RDB，本文將用簡單的文字和流程圖完成持久化這個知識點的講解。
1、Redis 的持久化機制
高效：Redis 是一個內存數據庫，所有的數據都以Key - Value 的方式存儲在內存中，當處理客戶端請求時，所有的操作都發生在內存當中，這也就是Reids處理速度高的原因之一。
風險：數據存在內存中會有一個很大的風險，如果Redis-Server 的守護進程掛掉或服務器出現重啟或關機，內存中的數據也回隨之消失。
持久化機制：為了避免出現數據丟失的風險，Redis 採用了持久化機制，有效的將內存中的數據保存在硬盤上，實現數據持久化。
2、RDB 和 AOF
Redis 在持久化機制上提供了兩種解決辦法，放別是 RDB 和 AOF。
RDB 方式
可以理解為“快照方式”，類似VM或雲服務器的快照功能。就是在某一時間內，將Redis在內存中的全部數據導出，存儲到硬盤上的一個叫dump.rdb（默認文件名）的文件中。當服務器重啟時，會從dump.rdb文件中加載數據到內存中，完成數據的恢復，實現數據持久化機制。
如何觸發RDB？
自動觸發和手動觸發，我們先說一下自動觸發。
自動觸發通過修改redis.conf 文件中的 save 部分的配置信息實現，找到這個部分，配置信息和註釋如下：
<code>save 900 1 #表示900 秒內如果至少有 1 個 key 的值變化，則保存save 300 10 #表示300 秒內如果至少有 10 個 key 的值變化，則保存save 60 10000 #表示60 秒內如果至少有 10000 個 key 的值變化，則保存############### 修改redis.conf 文件後，需要重新加載配置文件##############redis-server redis.conf#################其他RDB 配置 ###########是否壓縮 dump.rdb文件rdbcompression yes#修改默認的 dump.rdb 文件名稱，如：多個 redis ，可以使用端口號區分dbfilename redis_6379.rdb# dump.rdb 文件保存位置dir /usr/local/redis_rdb_back/#####################################/<code>
通過配置save ，當觸發條件滿足後觸發RDB持久化，如：當900s內至少有一個key發生變化，就執行RDB持久化來快照數據。
手動觸發RDB，需要執行 save 命令 或 bgsave 命令，這樣 Redis 就在服務器的硬盤上產生一個dump.rdb文件，用來持久化數據了。
<code>#同步操作/<code>
save 命令為同步操作，這是一個阻塞方式，在服務器執行RDB時會阻塞所有其他請求，直至RDB執行完畢，可以試想一下，如果數據量巨大，執行時間就會變長，其他的請求就出現等待，超時等一系列狀況。所以這個命令和 “keys *” 一樣，儘量不要在生產環境中使用。
<code>#異步操作bgsave/<code>
bgsave命令執行時採用子進程程完成資源操作，當客戶端發出bgsave 命令後，服務端forks一個子進程處理數據持久化操作，當數據完全寫入 dump.rdb 文件中後，子進程自動回收。
這樣的好處是，主進程依舊存在，可以處理其他客戶端請求，持久化請求交給forks 的一個子進程完成，主進程和子進程是同步的。
總結：
1、實現RDB方式有兩種方式，手動方式：執行命令，save 和 bgsave ，一個是同步，一個是異步。
配置方式：配置redis.conf 文件 save 部分實現，配置文件方式相當於執行了 bgsave 命令。
2、RDB 生成 dump.rdb 文件
生成RDB臨時文件後，開始寫入數據。
所有數據寫入完成後，用臨時文件代替正式RDB文件。
刪除原來 RDB 文件。
-----------------------------漂亮的分割線-----------------------------
AOF方式
append only file 會記錄客戶端對服務端的每次請求命令，將記錄追加到後綴為aof的文件尾部。
在Redis服務重啟後，運行AOF文件中的命令，恢復數據。
aof 文件中的數據為二進制格式，aof 的方式類似mysql 的binlog。
AOF 持久化機制是採用修改 redis.conf 配置文件實現的，具體配置如下：
<code># 開啟aof機制 appendonly yes # 定義 aof 文件名 appendfilename "appendonly.aof" # 寫入策略,always表示每個寫操作都保存到aof文件中,也可以是everysec或no appendfsync always # appendfsync everysec # appendfsync 的默認寫入策略，每秒寫入一次 AOF 文件，如發生異常，最多可能會丟失 1s 的數據。# appendfsync no # Redis 服務器不負責寫入 AOF，而是交由操作系統來處理什麼時候寫入 AOF 文件。更快，但也是最不安全的選擇，不推薦使用。 # 默認不重寫aof文件 no-appendfsync-on-rewrite no # 保存目錄 dir ~/redis/ /<code>
AOF 還有一個需要注意的問題，如果在寫入aof 文件的時候，服務器因異常宕機，那麼這個aof 文件就會出現格式錯誤，重啟服務器後，redis加載 aof 文件就會報錯，這時候需要修復 aof 文件，具體命令如下：
<code>#修復 aof 文件redis-check-aof -fix appendonly.aof#重啟redis server/<code>
總結：
aof 類似mysql binlog ，採用追加日誌方式，對服務器性能影響小，速度較rdb快。但是生成的文件較大，恢復數據比rdb 要慢。
最後到底是用 rdb 還是 aof 那，這個要結合生產環境靈活應用，下面給出一個 rdb 和 aof 對比圖，同學們自行選擇合適的持久化方式吧。
閱讀更多 疾風Team 的文章
