我是Redis，一個叫Antirez的男人把我帶到了這個世界上。
“快醒醒！快醒醒！”，隱隱約約，我聽到有人在叫我。
慢慢睜開眼睛，原來旁邊是MySQL大哥。
“我怎麼睡著了？”
“嗨，你剛才是不是出現了錯誤，整個程式都崩潰了！害得一大堆查詢請求都給我懟過來了！”，MySQL說到。
剛剛醒來，腦子還有點懵，MySQL大哥扶我起來繼續工作。
“糟了！我之前快取的資料全都不見了！”
“WTF？你沒有做持久化嗎？”，MySQL大哥一聽臉色都變了。
我尷尬的搖了搖頭，“我都是儲存在記憶體中的，所以才那麼快啊”
“那也可以在硬碟上儲存一下啊，遇到這種情況全部從頭再來建立快取，這不浪費時間嘛！”
我點了點頭，“讓我琢磨一下，看看怎麼做這個持久化”。
RDB持久化
沒幾天，我就拿出了一套方案：RDB
既然我的資料都在記憶體中存放著，最簡單的就是遍歷一遍把它們全都寫入檔案中。
為了節約空間，我定義了一個二進位制的格式，把資料一條一條碼在一起，生成了一個RDB檔案。
不過我的資料量有點大，要是全部備份一次得花不少時間，所以不能太頻繁的去做這事，要不然我不用幹正事了，光花時間去備份了。
還有啊，要是一直沒有寫入操作，都是讀取操作，那我也不用重複備份，浪費時間。
思來想去，我決定提供一個配置引數，既可以支援週期性備份，也可以避免做無用功。
就像這樣：
- save 900 1 # 900秒（15分鐘）內有1個寫入
- save 300 10 # 300秒（5分鐘）內有10個寫入
- save 60 10000 # 60秒（1分鐘）內有10000個寫入
多個條件可以組合使用，只要上面一個條件滿足，我就會去進行備份。
後來我又想了一下，這樣還是不行，我得fork出一個子程式去做這件事，不能浪費我的時間。
有了備份檔案，下次我再遇到崩潰退出，甚至伺服器斷電罷工了，只要我的備份檔案還在，我就能在啟動的時候讀取，快速恢復之前的狀態啦！
MySQL:binlog
我帶著這套方案，興沖沖的拿給了MySQL大哥看了，期待他給我一些鼓勵。
“老弟，你這個方案有點問題啊”，沒想到，他竟給我澆了一盆冷水。
“問題？有什麼問題？”
“你看啊，你這個週期性去備份，週期還是分鐘級別的，你可知道我們們這服務每秒鐘都要響應多少請求，像你這樣不得丟失多少資料？”，MySQL語重心長的說到。
我一下有些氣短了，“可是，這個備份一次要遍歷全部資料，開銷還是挺大的，不適合高頻執行啊”
“誰叫你一次遍歷全部資料了？來來來，我給你看個東西”，MySQL大哥把我帶到了一個檔案目錄下：
- mysql-bin.000001
- mysql-bin.000002
- mysql-bin.000003
- ···
“看，這些是我的二進位制日誌binlog，你猜猜看裡面都裝了些什麼？”，MySQL大哥指著這一堆檔案說到。
我看了一眼，全是一堆二進位制資料，這哪看得懂，我搖了搖頭。
“這裡面呀記錄了我對資料執行更改的所有操作，像是INSERT，UPDATE、DELETE等等動作，等我要進行資料恢復的時候就可以派上大用場了”
聽他這麼一說，我一下來了靈感！告別了MySQL大哥，回去研究起新的方案來了。
AOF持久化
你們也知道，我也是基於命令式的，每天的工作就是響應業務程式發來的命令請求。
回來以後，我決定照葫蘆畫瓢，學著MySQL大哥的樣子，把我執行的所有寫入命令都記錄下來，專門寫入了一個檔案，並給這種持久化方式也取了一個名字：AOF（Append Only File）。
不過我遇到了RDB方案同樣的問題，我該多久寫一次檔案呢？
我肯定不能每執行一條寫入命令就記錄到檔案中，那會嚴重拖垮我的效能！我決定準備一個緩衝區，然後把要記錄的命令先臨時儲存在這裡，然後再擇機寫入檔案，我把這個臨時緩衝區叫做aof_buf。
說幹就幹，我試了一下，竟然發現資料沒有寫入到檔案中去。多方打聽才知道，原來作業系統也有個快取區，我寫的資料被他快取起來了，沒有給我寫入到檔案中去，這不是坑爹呢嘛！
看來，我寫完了還得要去重新整理一下，把資料真正給寫下去，思來想去，我還是提供一個引數，讓業務程式去設定什麼時候重新整理吧。
appendfsync引數，三個取值：
- always: 每個事件週期都同步重新整理一次
- everysec: 每一秒都同步重新整理一次
- no: 我只管寫，讓作業系統自己決定什麼時候真正寫入吧
AOF重寫
這一次我不像之前那麼衝動，我決定先試執行一段時間再去告訴MySQL大哥，免得又被他戳到軟肋。
試用了一段時間，各方面都執行良好，不過我發現隨著時間的推移，我寫的這個AOF備份檔案越來越大，越來越大！不僅非常佔硬碟空間，複製移動，載入分析都非常的麻煩耗時。
我得想個辦法把檔案給壓縮一下，我把這個過程叫做AOF重寫。
一開始，我打算去分析原來的AOF檔案，然後將其中的冗餘指令去掉，來給AOF檔案瘦瘦身，不過我很快放棄了這個想法，這工作量實在太大了，分析起來也頗為麻煩，浪費很多精力跟時間。
原來的一條條記錄這種方式實在是太笨了，資料改來改去，有很多中間狀態都沒用，我何不就把最終都資料狀態記錄下來就好了？
比如：
- RPUSH name_list '程式設計技術宇宙'
- RPUSH name_list '帥地玩程式設計'
- RPUSH name_list '後端技術學堂'
可以合併成一條搞定：
- RPUSH name_list '程式設計技術宇宙' '帥地玩程式設計' '後端技術學堂'
AOF檔案重寫的思路我是有了，不過這件事幹起來還是很耗時間，我決定和RDB方式一樣，fork出一個子程式來做這件事情。
謹慎如我，發現這樣做之後，子程式在重寫期間，我要是修改了資料，就會出現和重寫的內容不一致的情況！MySQL大哥肯定會挑刺兒，我還得把這個漏洞給補上。
於是，我在之前的aof_buf之外，又準備了一個緩衝區：AOF重寫緩衝區。
從建立重寫子程式開始的那一刻起，我把後面來的寫入命令也copy一份寫到這個重寫緩衝區中，等到子程式重寫AOF檔案結束之後，我再把這個緩衝區中的命令寫入到新的AOF檔案中。
最後再重新命名新的AOF檔案，替換掉原來的那個臃腫不堪的大檔案，終於大功告成！
再三確定我的思路沒有問題之後，我帶著新的方案再次找到了MySQL大哥，我都做到這份兒上了，這一次，想必他應該無話可說了吧？
MySQL大哥看了我的方案露出了滿意的笑容，只是問了一個問題：
這AOF方案這麼好了，RDB方案是不是可以不要了呢？
萬萬沒想到，他居然問我這個問題，我竟陷入了沉思，你覺得我該怎麼回答好呢？
彩蛋
“你怎麼又崩潰了？”
“不好意思，又遇到bug了，不過不用擔心，我現在可以快速恢復了！”
“那老崩潰也不是事兒啊，你只有一個例項太不可靠了，去找幾個幫手吧！”
預知詳情，請關注後續精彩···
