### Redis持久化策略 Redis一共支持四種持久化方式，主要使用的兩種： * 定時快照方式(snapshot)：該持久化方式實際是在Redis內部一個定時器事件，每隔固定時間去檢查當前數據發生的改變次數與時間是否滿足配置的持久化觸發的條件，如果滿足則通過操作系統fork調用來創建出一個子進程，這個子進程默認會與父進程共享相同的地址空間，這時就可以通過子進程來遍歷整個內存來進行存儲操作，而主進程則仍然可以提供服務，當有寫入時由操作系統按照內存頁（page）為單位來進行copy-on-write保證父子進程之間不會互相影響。它的缺點是快照只是代表一段時間內的內存映像，所以系統重啟會丟失上次快照與重啟之間所有的數據 * 基于語句追加文件的方式(aof)：aof方式實際類似MySQl的基于語句的binlog方式，即每條會使Redis內存數據發生改變的命令都會追加到一個log文件中，也就是說這個log文件就是Redis的持久化數據；aof的方式的主要缺點是追加log文件可能導致體積過大，當系統重啟恢復數據時如果是aof的方式則加載數據會非常慢，幾十G的數據可能需要幾小時才能加載完，當然這個耗時并不是因為磁盤文件讀取速度慢，而是由于讀取的所有命令都要在內存中執行一遍。另外由于每條命令都要寫log，所以使用aof的方式，Redis的讀寫性能也會有所下降 * Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啟時， 它會優先使用 AOF 文件來還原數據集， 因為 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整 * 可以關閉持久化功能，讓數據只在服務器運行時存在 Redis的持久化使用了Buffer I/O，所謂Buffer I/O是指Redis對持久化文件的寫入和讀取操作都會使用物理內存的Page Cache，而大多數數據庫系統會使用Direct I/O來繞過這層Page Cache并自行維護一個數據的Cache。而當Redis的持久化文件過大（尤其是快照文件），并對其進行讀寫時，磁盤文件中的數據都會被加載到物理內存中作為操作系統對該文件的一層Cache，而這層Cache的數據與Redis內存中管理的數據實際是重復存儲的。雖然內核在物理內存緊張時會做Page Cache的剔除工作，但內核很可能認為某塊Page Cache更重要，而讓你的進程開始Swap，這時你的系統就會開始出現不穩定或者崩潰了，因此在持久化配置后，針對內存使用需要實時監控觀察