在前一篇文章中，已經介紹了Redis的基礎數據結構，這篇文章將繼續介紹Redis的持久化原理。
簡介
眾所周知Redis的所有數據都存在於內存之中，這就會存在因內存問題而導致的數據丟失，為了避免這一問題，可采取Redis的持久化機制來解決這一問題。
詳解
Redis持久化有兩種方式，分別是RDB（又稱快照）與AOF。對於兩種方式各有優缺點，具體如下：
RDB：全量一次同步內存中所有序列化的二進制數據，同步慢，數據較小。
AOF：增量同步操作指令，同步較快，數據量隨時間增加而增多，需定期進行AOF文件重寫，以便減小日志文件。
RDB原理
SAVE：該命令會阻塞當前Redis服務，導致Redis服務不可用，直至RDB持久化進程完畢，所以一般都不采取該方式進行RDB持久化。
BGSAVE：當使用該命令進行RDB持久化時，Redis會fork產生一個子進程，由子進程進行RDB持久化操作，父進程接受客戶端的操作請求。子進程只會遍歷讀取內存中的數據，寫入磁盤，並不會修改數據，若父進程在子進程讀取數據過后進行了數據修改，子進程就會與父進程存在數據不一致的問題。
Copy on Write：眾所周知Redis是單線程程序，文件IO操作不能進行多路復用，於是在BGSAVE進行RDB持久化時Redis采用操作系統的Copy on Write機制進行RDB持久化。
單獨使用RDB持久化，存在數據丟失風險
AOF原理
AOF日志存儲的是，Redis執行的順序寫指令。當開啟AOF持久化時，Redis會先執行數據的寫指令，再將指令寫入AOF日志中。
fsync：實際情況中，AOF機制會先將Redis寫指令寫入內存緩沖區中，再根據配置情況，定時調用fsync將緩沖區文件寫入AOF日志中。我們可以根據實際情況設置fsync頻率：
-
always：每次修改，立即提交磁盤。該方式數據完整性良好，但是IO開銷大，影響效率.
-
everysec： 每秒同步一次到磁盤。該方式只會丟失一秒內的數據，
-
no： 從不同步到磁盤。
思考
從上述的原理中，可以看出無論是RDB還是AOF，都存在一定的缺點。
在日常操作中，一般都是從AOF日志中來恢復數據，因為RDB會丟失大量數據。但是AOF恢復數據又會花費較長時間。
於是從Redis4.0開始，Redis開始支持混合持久化。即將RDB與AOF結合使用，RDB負責定時全量持久化數據，AOF負責記錄最后一次RDB后的增量日志。使得Redis的數據恢復在恢復效率與數據完整性之間取得一個完美的平衡點。