喜歡就 關注 我們吧！
簡介：
Hello 各位 ，我是公號「八點半技術站」的創作者 - Bruce.D （姓氏：豆）。
感謝微信給予的個人認證，專注於PHP、數據庫技術領域知識經驗分享。
技術的交流、不僅僅限制於閱讀，在此歡迎各路大神、小白，來「wx技術羣」分享自己的編程經驗心得 與 技術實戰乾貨。
Redis 持久化如何工作？
Q：首先要知道什麼是持久化？
A：持久化就是將數據放到斷電後數據不會丟失的設備中。（通常理解的硬盤）
Q：redis 在進行寫操作，做了哪些事？
A：
（1）客戶端向服務端發送寫操作（數據在客戶端內存中）；
（2）數據庫服務端接收到寫請求數據（數據在服務端內存中）；
（3）服務端調用 write 這個系統調用，將數據往磁盤上寫（數據在系統內存的緩衝區中）；
（4）操作系統將緩存區中的數據轉移到磁盤控制器上（數據在磁盤緩存中）；
（5）磁盤控制器將數據寫入到磁盤物理介質中（數據真正落到磁盤中）。
Redis 持久化 之 RDB
RDB 的這種方式、是將 redis 某一刻的數據持久化到磁盤中，是一種 快照式 的持久化方式。
redis 在進行數據持久化過程中，會將數據寫入到一個臨時的文件中，帶持久化過程結束了，纔會用這個臨時文件替換上次那個持久化好的文件。
因爲這種特性，我們可以隨時備份數據，快照的文件總是完整可用的。
我們可以通過 redis 的 save 指令來配置 RDB快照生成時機，例如：配置當10分鐘以內有100次寫入就生成快照，可以多個規則一起生成 。
（注：這些規則定義在redis 配置文件中，也可通過 redis 的 CONFIG SET 命令在redis 設置規則，無需重啓 redis ）
對於 RDB 方式，redis 會單獨創建（fork）一個子進程進行持久化。
而主進程不會進行任何 IO 操作的，這樣確保了redis 極高的性能。
redis 的 RDB 文件不會壞掉，因爲在寫操作時候是在一個新的進程中的，當生成一個新的RDB 文件時，redis 生成的子進程會將數據寫到另外一個臨時文件中，然後通過原子性 rename 系統調用臨時文件重命名爲 RDB 文件。
這樣在任何時候出現故障，redis 的 RDB文件總是可用的。
RDB 有一個缺陷：
就是數據庫一旦出現問題，RDB文件保存的數據不是全新的。從上次 RDB文件生成到 redis停機這段時間的數據全部丟失了。
在部分業務下，RDB 方式還是可以接受。如果無法忍受數據丟失應用，就可以採用另外一個機制 ：AOF 日誌。
Redis 持久化 之 AOF
AOF 全稱：Append Only File （日誌文件）
AOF 的這種方式、只允許追加不允許改寫的文件。
（注：AOF 文件是可識別純文本，它的內容就是redis的標準命令）
它這種方式，是將執行過的寫指令記錄下來，數據恢復是按照從前到後的順序再將指令全部執行一遍。
我們會通過配置 redis.conf 中的 appendonly yes 可以打開這個 AOF功能。如果有寫操作，redis 就會被追加到 AOF文件的末尾。例如：
./redis-server --appendonly yes
開啓後，查看 cat appendonly.aof 記錄所有寫操作都會生成一條相應命令作爲日誌。
（注：每一條寫入命令生成一條日誌，會導致 AOF文件越來越大，因此redis提供了一個功能— AOF rewrite - 重新生成一份AOF文件）
簡單說一下 AOF rewrite：
重新生成一份 AOF文件，新的 AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了懟同一個值的多次操作。
默認的AOF持久化策略是：每秒鐘 fsync 一次（fsync是指把緩存中的寫指令記錄到磁盤中）。因爲這種情況下，redis 仍然可以保持很好的處理性能。即使 redis 故障，也只會丟失一秒的數據。
在追加日誌時，恰好遇到磁盤空間滿，或者斷電等情況導致日誌文件寫入不完整，也是沒有關係。redis 提供了 redis-check-aof 工具，可以進行日誌修復。
到這裏也就結束了，首先恭喜你又閱讀完一篇文章，如果你認爲有收穫那麼收藏轉發起來，幫助需要的夥伴。
方案方式很多，就看你是否越意去研究、去發現，歡迎評論區留言~~~
往下拉，有乾貨
和我再戰 n+1 天
同時，爲了方便大家學習，我會把一些源碼、技術乾貨存儲到 github 中，隨時可以在微信羣 進行交流，掃下面二維碼 ，備註 “技術進羣” 就可以通過審覈。
進羣的小夥伴請加右側私人微信（備註：技術進羣）
----投稿分隔線----
投稿，關注公衆號回覆“投稿”，專員對接
-----商務合作分隔線----
商務合作，關注公衆號回覆“商務合作”，專員對接