簡單來說，如果沒有持久化的redis，就和memcache一樣了，相當於一個緩存數據庫。

redis是如何解決數據持久化的？

redis有兩種持久化方案：RDB（Redis DataBases）和AOF(AppendOnly File)

RDB持久化（詳細分析：http://blog.51cto.com/13690439/2118462）

RDB是snapshot快照<二進制文件>存儲，是默認的持久化方式。

RDB會按照一定的策略，周期性的將數據保存到磁盤。（下個周期為到來時故障，會丟數據）

借助fork命令的copy on write機制，在快照生成時，將當前進程fork出一個子進程，

然後再子進程中循環所有數據，將數據寫成RDB文件。

AOF持久化（詳細分析：http://blog.51cto.com/13690439/2118465）

AOF<二進制文件>比RDB方式有更好的持久性。

redis會將每一個收到的寫命令都通過write函數追加到文件最後，類似msyql的binlog。

當redis重啟時，會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。

簡單來說:

RDB：是按照策略周期性的進行持久化數據；

AOF：是不斷的去記錄修改操作；

持久化方式的選擇：

RDB和AOF操作都是順序IO操作，性能都很高。

而同時在通過RDB文件或者AOF日誌進行數據庫恢復的時候，也是順序的讀取數據加載到內存中。

所以也不會造成磁盤的隨機讀。

通常，如果你要想提供很高的數據保障性，那麽建議你同時使用兩種持久化方式。

如果你可以接受災難帶來的幾分鐘的數據丟失，那麽你可以僅使用RDB。

在數據恢復方面：

RDB的啟動時間會更短，原因有兩個：

1、RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的多次操作記錄。

所以每條數據只需要寫一次就行了。

2、RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不需要再進行數據編碼工作，

所以在CPU消耗上要遠小於AOF日誌的加載。

市場常見架構：

目前，通常的設計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。

即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，

而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數據的安全性。

Redis持久化方案RDB和AOF（理論）