redis持久化包括rdb和aof兩種方案
1、rdb持久化方案
- 持久化過程：按照redis.conf文件配置，如
save 900 1
save 300 10
save 60 10000
，在指定時間間隔內滿足數據落盤策略時候，redis會fork一個和原進程一模一樣的子進程，該進程先將數據存到一個臨時文件裡，待持久化結束後，用臨時文件替換上次的持久化文件。
- 觸發落盤：滿足配置的策略、使用flushdb、使用flushall（效果是所用數據都刪除了，落盤後dump.rdb（默認文件名，可配置）文件內容為空）
- 恢復數據：將dump.rdb複製到安裝redis目錄，並啟動redis的服務。（連上redis後可以使用config get dir 獲取redis的安裝目錄）
劣勢：
a、在一定間隔時間落盤一次，如果redis意外down，會弔事最後一次的redis中所有修改
b、fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮
優勢：適合對數據完整性和一致性要求不高的場景；適合大規模的數據恢復
2、aof持久化方案
- 持久化過程：按照redis.conf文件配置，如
#appendfsync always
appendfsync everysec
#appendfsync no
，根據同步策略為everysec，則每秒將寫操作追加（讀操作不會追加）到appendonly.aof文件。
- 恢復數據：將appendonly.aof文件複製到config get dir對應的目錄，並重啟redis
- 重寫機制：appendonly.aof的內容是以追加的方式添加的，如果沒有特殊機制，該文件會越來越大，為避免這個情況，redis針對aof持久化方式有重寫機制
重寫過程：當aof文件超過配置的閾值（滿足配置文件的配置的策略），redis會fork出一個進程，該進程遍歷內存中的數據，每條記錄都對應一條set語句，寫入臨時的aof文件，重寫完成後，用臨時文件替換上次的持久化文件。
劣勢：
a、aof文件遠大於rdb文件
b、數據恢復速度慢於rdb
優勢：同步策略always->每次修改同步，性能差但完整性好；同步策略everysec->每秒同步，異步操作，如果一秒內down機會丟失數據；no->從不同步
3、疑問
如果兩種持久化方式都配置了，那麼redis重啟時候，從哪裡恢復數據呢？
從appendonly.aof文件恢復，因為aof持久化的數據更精確
是不是隻使用aof持久化方式呢？
分享到:
閱讀更多 Java高併發框架 的文章
