Redis 作為資料庫持久化替代方案的問題分析

目前Redis支援兩種持久化模式，一種是 Snapshotting（快照），另一種是Append-only file（aof）。 

Snapshotting（快照）：預設的持久化方式，這種模式就是將記憶體中資料以快照的方式寫入到二進位檔案中（預設檔案為dump.rdb）。
Append-only file（aof）：這種模式Redis會將每一個收到的寫命令都通過寫方法追加到檔案中（預設檔案為 appendonly.aof）。當Redis重啟時會通過重新執行檔案中儲存的寫命令在記憶體中重建整個資料庫的內容。
aof模式下有三種方式強制寫磁碟：
（1）appendfsync always：每次收到寫命令就立即強制寫入磁碟，效能最慢，但是保證完全的持久化（不推薦使用）
（2）appendfsync everysec：每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中
（3）appendfsync no：完全依賴OS，效能最好，持久化沒保證

快照優點是二進位，大小比aof記錄檔小，但會丟失最後一次成功備份時間到宕機時間的資料；aof記錄檔較大，但相對快照來講，不容易丟失檔案。目前Redis檢查資料檔案是否有錯對於快照及aof都能夠支援，但修複則只對aof檔案有效。

因此為了保證資料資料完整性，我們就要使用aof模式，並且採用appendfsync always方式，但是這樣效能比使用MySQL還要低；如果我們選擇appendfsync everysec方式，Redis定期把記憶體中的資料Flush到持久化儲存當中，這樣一旦Redis伺服器Crash掉，可能會造成一部分資料無法Flush到持久化儲存中。

另外Redis沒有官方提供的叢集方案，對叢集化支援不是很好，對於主從同步也是一主多從。

其他方面的問題：

應用開發問題
（1）需要將應用程式層關係型資料結構全部轉換為 key/value 形式
（2）支援的資料類型較少
（3）對大的資料結構list,sorted set,hash set的批量處理意為著其他請求的等待，故使用Redis的複雜資料結構需要控制其單key-struct的大小。

資料查詢問題
（1）查詢功能較弱
（2）查詢的效率問題

緩衝使用的規劃設計問題。
在使用前要有詳細的規劃。比如有多少資料以及哪些資料需要儲存在記憶體中，將直接影響系統相關設計。
再比如曆史資料或使用者訪問量較少的資料不應該放到記憶體中，以減輕記憶體壓力。

資料恢複問題
資料量較大後故障恢複會帶來比較大的系統壓力，並佔用額外記憶體，可能導致系統記憶體不足等線上故障。

因此能否將Redis作為資料庫的替代方案，取決於我們能否較好的處理持久化等相關問題。