我是Redis，一個叫Antirez的男人把我?guī)У搅诉@個世界上船逮。
“快醒醒挖胃！快醒醒杂靶！”梆惯，隱隱約約，我聽到有人在叫我吗垮。
慢慢睜開眼睛垛吗，原來旁邊是MySQL大哥。
“我怎么睡著了烁登？”
“嗨怯屉，你剛才是不是出現(xiàn)了錯誤，整個進程都崩潰了饵沧！害得一大堆查詢請求都給我懟過來了锨络！”，MySQL說到狼牺。
剛剛醒來羡儿，腦子還有點懵，MySQL大哥扶我起來繼續(xù)工作是钥。
“糟了掠归！我之前緩存的數(shù)據(jù)全都不見了！”
“WTF咏瑟？你沒有做持久化嗎拂到？”，MySQL大哥一聽臉色都變了码泞。
我尷尬的搖了搖頭兄旬，“我都是保存在內(nèi)存中的，所以才那么快啊”
“那也可以在硬盤上保存一下啊余寥，遇到這種情況全部從頭再來建立緩存领铐，這不浪費時間嘛！”
我點了點頭，“讓我琢磨一下祝蝠，看看怎么做這個持久化”音诈。
RDB持久化
沒幾天，我就拿出了一套方案：RDB
既然我的數(shù)據(jù)都在內(nèi)存中存放著绎狭，最簡單的就是遍歷一遍把它們?nèi)紝懭胛募小?/p>
為了節(jié)約空間细溅，我定義了一個二進制的格式，把數(shù)據(jù)一條一條碼在一起儡嘶，生成了一個RDB文件喇聊。
不過我的數(shù)據(jù)量有點大誓篱，要是全部備份一次得花不少時間朋贬，所以不能太頻繁的去做這事，要不然我不用干正事了窜骄，光花時間去備份了锦募。
還有啊，要是一直沒有寫入操作啊研，都是讀取操作御滩，那我也不用重復(fù)備份，浪費時間党远。
思來想去削解，我決定提供一個配置參數(shù)，既可以支持周期性備份沟娱，也可以避免做無用功氛驮。
就像這樣：
save 900 1 # 900秒（15分鐘）內(nèi)有1個寫入
save 300 10 # 300秒（5分鐘）內(nèi)有10個寫入
save 60 10000 # 60秒（1分鐘）內(nèi)有10000個寫入
多個條件可以組合使用，只要上面一個條件滿足济似，我就會去進行備份矫废。
后來我又想了一下，這樣還是不行砰蠢，我得fork出一個子進程去做這件事蓖扑，不能浪費我的時間。
有了備份文件台舱，下次我再遇到崩潰退出律杠，甚至服務(wù)器斷電罷工了，只要我的備份文件還在竞惋，我就能在啟動的時候讀取柜去，快速恢復(fù)之前的狀態(tài)啦！
MySQL:binlog
我?guī)е@套方案，興沖沖的拿給了MySQL大哥看了浑厚，期待他給我一些鼓勵股耽。
“老弟，你這個方案有點問題啊”钳幅，沒想到豺谈，他竟給我澆了一盆冷水。
“問題贡这？有什么問題？”
“你看啊厂榛，你這個周期性去備份盖矫，周期還是分鐘級別的丽惭，你可知道咱們這服務(wù)每秒鐘都要響應(yīng)多少請求，像你這樣不得丟失多少數(shù)據(jù)辈双？”责掏，MySQL語重心長的說到。
我一下有些氣短了，“可是证芭，這個備份一次要遍歷全部數(shù)據(jù)瞳浦，開銷還是挺大的，不適合高頻執(zhí)行啊”
“誰叫你一次遍歷全部數(shù)據(jù)了废士？來來來叫潦，我給你看個東西”，MySQL大哥把我?guī)У搅艘粋€文件目錄下：
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
···
“看官硝，這些是我的二進制日志binlog矗蕊，你猜猜看里面都裝了些什么？”氢架，MySQL大哥指著這一堆文件說道傻咖。
我看了一眼，全是一堆二進制數(shù)據(jù)岖研，這哪看得懂卿操，我搖了搖頭。
“這里面呀記錄了我對數(shù)據(jù)執(zhí)行更改的所有操作缎玫，像是INSERT硬纤，UPDATE、DELETE等等動作赃磨，等我要進行數(shù)據(jù)恢復(fù)的時候就可以派上大用場了”
聽他這么一說筝家，我一下來了靈感！告別了MySQL大哥邻辉，回去研究起新的方案來了溪王。
AOF持久化
你們也知道，我也是基于命令式的值骇，每天的工作就是響應(yīng)業(yè)務(wù)程序發(fā)來的命令請求莹菱。
回來以后，我決定照葫蘆畫瓢吱瘩，學(xué)著MySQL大哥的樣子道伟，把我執(zhí)行的所有寫入命令都記錄下來，專門寫入了一個文件，并給這種持久化方式也取了一個名字：AOF（Append Only File）蜜徽。
不過我遇到了RDB方案同樣的問題拘鞋，我該多久寫一次文件呢砚蓬？
我肯定不能每執(zhí)行一條寫入命令就記錄到文件中，那會嚴(yán)重拖垮我的性能盆色！我決定準(zhǔn)備一個緩沖區(qū)灰蛙，然后把要記錄的命令先臨時保存在這里，然后再擇機寫入文件隔躲，我把這個臨時緩沖區(qū)叫做aof_buf摩梧。
說干就干障本，我試了一下，竟然發(fā)現(xiàn)數(shù)據(jù)沒有寫入到文件中去响鹃。多方打聽才知道驾霜，原來操作系統(tǒng)也有個緩存區(qū)，我寫的數(shù)據(jù)被他緩存起來了买置，沒有給我寫入到文件中去粪糙，這不是坑爹呢嘛！
看來忿项，我寫完了還得要去刷新一下蓉冈，把數(shù)據(jù)真正給寫下去，思來想去轩触，我還是提供一個參數(shù)寞酿，讓業(yè)務(wù)程序去設(shè)置什么時候刷新吧。
appendfsync參數(shù)脱柱，三個取值：
always: 每個事件周期都同步刷新一次
everysec: 每一秒都同步刷新一次
no: 我只管寫伐弹，讓操作系統(tǒng)自己決定什么時候真正寫入吧
AOF重寫
這一次我不像之前那么沖動，我決定先試運行一段時間再去告訴MySQL大哥榨为，免得又被他戳到軟肋惨好。
試用了一段時間，各方面都運行良好随闺，不過我發(fā)現(xiàn)隨著時間的推移日川，我寫的這個AOF備份文件越來越大，越來越大矩乐！不僅非常占硬盤空間龄句，復(fù)制移動，加載分析都非常的麻煩耗時。
我得想個辦法把文件給壓縮一下撒璧，我把這個過程叫做AOF重寫透葛。
一開始，我打算去分析原來的AOF文件硫椰，然后將其中的冗余指令去掉繁调，來給AOF文件瘦瘦身，不過我很快放棄了這個想法靶草，這工作量實在太大了蹄胰，分析起來也頗為麻煩，浪費很多精力跟時間奕翔。
原來的一條條記錄這種方式實在是太笨了裕寨，數(shù)據(jù)改來改去，有很多中間狀態(tài)都沒用派继，我何不就把最終都數(shù)據(jù)狀態(tài)記錄下來就好了宾袜？
比如：
RPUSH name_list '編程技術(shù)宇宙'
RPUSH name_list '帥地玩編程'
RPUSH name_list '后端技術(shù)學(xué)堂'
可以合并成一條搞定：
RPUSH name_list '編程技術(shù)宇宙' '帥地玩編程' '后端技術(shù)學(xué)堂'
AOF文件重寫的思路我是有了，不過這件事干起來還是很耗時間驾窟，我決定和RDB方式一樣庆猫，fork出一個子進程來做這件事情。
謹(jǐn)慎如我绅络，發(fā)現(xiàn)這樣做之后月培，子進程在重寫期間，我要是修改了數(shù)據(jù)恩急，就會出現(xiàn)和重寫的內(nèi)容不一致的情況杉畜！MySQL大哥肯定會挑刺兒，我還得把這個漏洞給補上衷恭。
于是匾荆，我在之前的aof_buf之外拌蜘，又準(zhǔn)備了一個緩沖區(qū)：AOF重寫緩沖區(qū)。
從創(chuàng)建重寫子進程開始的那一刻起牙丽，我把后面來的寫入命令也copy一份寫到這個重寫緩沖區(qū)中简卧，等到子進程重寫AOF文件結(jié)束之后，我再把這個緩沖區(qū)中的命令寫入到新的AOF文件中烤芦。
最后再重命名新的AOF文件举娩，替換掉原來的那個臃腫不堪的大文件，終于大功告成！
再三確定我的思路沒有問題之后，我?guī)е碌姆桨冈俅握业搅薓ySQL大哥芙代，我都做到這份兒上了吊奢，這一次，想必他應(yīng)該無話可說了吧纹烹？
MySQL大哥看了我的方案露出了滿意的笑容页滚，只是問了一個問題：
這AOF方案這么好了，RDB方案是不是可以不要了呢铺呵？
萬萬沒想到裹驰，他居然問我這個問題，我竟陷入了沉思片挂，你覺得我該怎么回答好呢幻林？
彩蛋
“你怎么又崩潰了？”
“不好意思音念，又遇到bug了沪饺，不過不用擔(dān)心，我現(xiàn)在可以快速恢復(fù)了症昏！”
“那老崩潰也不是事兒啊随闽，你只有一個實例太不可靠了，去找?guī)讉€幫手吧肝谭！”
