【Redis】redis備份機制

忽然掛了！Redis緩存都在內存中，這下完了！

我是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方案是否是能夠不要了呢？

萬萬沒想到，他竟然問我這個問題，我竟陷入了沉思，你以爲我該怎麼回答好呢？