redis是支援資料持久化的，雖然在生產中經常被當做快取伺服器使用。
redis持久化機制分為兩種：第一種是快照第二種是aof日誌。
快照原理
前面redis基礎篇中提到，redis是單執行緒的，這個執行緒需要同時處理客戶端的請求和記憶體資料結構的邏輯讀寫，顯然難以在保持高效能的前提下完成這些工作。
所以redis使用作業系統的多程序cow（copy on write）寫時複製機制來完成快照持久化。
copy on write原理看這篇linux寫入複製的文章
fork（多執行緒）
redis在持久化的時候會呼叫glibc的函式fork產生乙個子程序，快照持久化工作全部交給子程序處理，父程序則繼續處理客戶端請求。子程序在產生時完全共享父程序共享記憶體裡面的**段和資料段。
子程序做資料持久化時不會修改現有的記憶體資料結構，它只是遍歷記憶體中的資料然後序列化寫入磁碟中。與此同時，父程序還在接受客戶端的資料互動請求，然後對記憶體中的資料進行不斷的修改。
這個時候就會使用作業系統的cow機制來進行資料段頁面的分離。簡單來說就是資料段由多個資料頁組成，當客戶端請求對某個資料進行修改時，找到這個資料所在的資料頁，系統會將這個資料頁複製乙份，在這哥複製頁上進行資料修改。
子程序的資料沒有變化，因此它看到的記憶體裡的資料在晉城產生的一瞬間就凝固了，就像拍照的快照一樣。
aof原理
aof日誌儲存的是redis的指令序列，按照執行順序儲存，aof只記錄對記憶體進行修改的指令記錄。aof寫入流程：
客戶端傳送請求到redis伺服器
redis伺服器進行引數校驗，檢查引數、命令的安全性合理性
校驗通過先將指令寫入aof日誌中，也就是寫入磁碟持久化
寫入aof完畢再執行指令
在redis長期執行的過程中，會接收到很多的指令，這將導致aof日誌越來越大。而aof日誌中很多命令是重複覆蓋的，我們只需保留最新的資料即可，比如某個 key = aaa 的資料初始值value = 1，在redis執行的過程中該資料進行過1000次修改，並且最新value = 111 。此時aof中有1000個關於key=aaa的指令記錄，而實際上我們只需要記錄其最新的 value=111 即可保證資料持久化。
所以我們需要對aof進行**。
aof 重寫
顧名思義就是對aof的命令進行重寫，達到**的目的。
redis中提供bgrewriteaof命令來對aof日誌進行重寫，重寫原理：
fsync
linux系統的glibc提供的fsync()方法可以強制將指定檔案的內容從核心快取刷到磁碟中，只要redis程序實時呼叫fsync()函式，就可以保證aof日誌不丟失。但是fsync是乙個磁碟的io操作，如果頻繁進行fsync()操作redis的效能將極大降低。
持久化小結
所以redis一般是從節點進行資料持久化，而主節點與客戶端互動
redis4.0 混合持久化
rdb + 增量aof日誌的形式：當重啟乙個redis時，先使用rdb恢復再用增量的aof日誌進行指令重放，達到快速啟動恢復資料的效果。
redis持久化 AOF持久化
1.aof持久化原理 aof持久化會將被執行的寫命令寫到aof檔案的末尾。在恢復的時候，redis只要從頭到尾重新執行一次aof檔案包含的所有寫命令 2.配置選項 固態硬碟禁用always選項，在某些情況頻繁讀寫會大大降低固態硬碟的壽命 4.aof檔案的重寫和壓縮 aof檔案裡面記錄了所有的命令而不...
Redis 三 事務與持久化
redis 中的事務 transaction 是一組命令的集合，至少是兩個或兩個以上的命令，redis事務保證這些命令被執行時中間不會被任何其他操作打斷。事務執行 exec 之前，入隊命令錯誤 語法錯誤 嚴重錯誤導 致伺服器不能正常工作 例如記憶體不足 放棄事務。redis 的資料儲存在記憶體中，記...
Redis學習 五 Redis持久化
redis是乙個記憶體資料庫,那麼如果不做持久化的話,當redis伺服器守護程序退出,伺服器宕機,計算機斷電 就會導致記憶體中的資料丟失,如果redis只是作為乙個快取伺服器來用的話,那麼不會有什麼影響,但是如果作為乙個記憶體資料庫的話,當上面的情況發生就會出現丟失所有資料的重大事故 rdb red...