突然掛了!Redis快取都在記憶體中,這下完了!

ITPUB社群 發表於 2022-11-29
Redis

我是Redis,一個叫Antirez的男人把我帶到了這個世界上。

突然掛了!Redis快取都在記憶體中,這下完了!

“快醒醒!快醒醒!”,隱隱約約,我聽到有人在叫我。

慢慢睜開眼睛,原來旁邊是MySQL大哥。

“我怎麼睡著了?”

“嗨,你剛才是不是出現了錯誤,整個程式都崩潰了!害得一大堆查詢請求都給我懟過來了!”,MySQL說到。

剛剛醒來,腦子還有點懵,MySQL大哥扶我起來繼續工作。

“糟了!我之前快取的資料全都不見了!”

“WTF?你沒有做持久化嗎?”,MySQL大哥一聽臉色都變了。

我尷尬的搖了搖頭,“我都是儲存在記憶體中的,所以才那麼快啊”

“那也可以在硬碟上儲存一下啊,遇到這種情況全部從頭再來建立快取,這不浪費時間嘛!”

突然掛了!Redis快取都在記憶體中,這下完了!

我點了點頭,“讓我琢磨一下,看看怎麼做這個持久化”。

RDB持久化

沒幾天,我就拿出了一套方案:RDB

既然我的資料都在記憶體中存放著,最簡單的就是遍歷一遍把它們全都寫入檔案中。

為了節約空間,我定義了一個二進位制的格式,把資料一條一條碼在一起,生成了一個RDB檔案。

突然掛了!Redis快取都在記憶體中,這下完了!

不過我的資料量有點大,要是全部備份一次得花不少時間,所以不能太頻繁的去做這事,要不然我不用幹正事了,光花時間去備份了。

還有啊,要是一直沒有寫入操作,都是讀取操作,那我也不用重複備份,浪費時間。

思來想去,我決定提供一個配置引數,既可以支援週期性備份,也可以避免做無用功。

就像這樣:

  • save 900 1     # 900秒(15分鐘)內有1個寫入
  • save 300 10    # 300秒(5分鐘)內有10個寫入
  • save 60 10000  # 60秒(1分鐘)內有10000個寫入

多個條件可以組合使用,只要上面一個條件滿足,我就會去進行備份。

後來我又想了一下,這樣還是不行,我得fork出一個子程式去做這件事,不能浪費我的時間。

有了備份檔案,下次我再遇到崩潰退出,甚至伺服器斷電罷工了,只要我的備份檔案還在,我就能在啟動的時候讀取,快速恢復之前的狀態啦!

突然掛了!Redis快取都在記憶體中,這下完了!

MySQL:binlog

我帶著這套方案,興沖沖的拿給了MySQL大哥看了,期待他給我一些鼓勵。

“老弟,你這個方案有點問題啊”,沒想到,他竟給我澆了一盆冷水。

“問題?有什麼問題?”

“你看啊,你這個週期性去備份,週期還是分鐘級別的,你可知道我們們這服務每秒鐘都要響應多少請求,像你這樣不得丟失多少資料?”,MySQL語重心長的說到。

突然掛了!Redis快取都在記憶體中,這下完了!

我一下有些氣短了,“可是,這個備份一次要遍歷全部資料,開銷還是挺大的,不適合高頻執行啊”

“誰叫你一次遍歷全部資料了?來來來,我給你看個東西”,MySQL大哥把我帶到了一個檔案目錄下:

  • mysql-bin.000001
  • mysql-bin.000002
  • mysql-bin.000003
  • ···

“看,這些是我的二進位制日誌binlog,你猜猜看裡面都裝了些什麼?”,MySQL大哥指著這一堆檔案說到。

我看了一眼,全是一堆二進位制資料,這哪看得懂,我搖了搖頭。

“這裡面呀記錄了我對資料執行更改的所有操作,像是INSERTUPDATEDELETE等等動作,等我要進行資料恢復的時候就可以派上大用場了”

聽他這麼一說,我一下來了靈感!告別了MySQL大哥,回去研究起新的方案來了。

AOF持久化

你們也知道,我也是基於命令式的,每天的工作就是響應業務程式發來的命令請求。

回來以後,我決定照葫蘆畫瓢,學著MySQL大哥的樣子,把我執行的所有寫入命令都記錄下來,專門寫入了一個檔案,並給這種持久化方式也取了一個名字:AOF(Append Only File)

突然掛了!Redis快取都在記憶體中,這下完了!

不過我遇到了RDB方案同樣的問題,我該多久寫一次檔案呢?

我肯定不能每執行一條寫入命令就記錄到檔案中,那會嚴重拖垮我的效能!我決定準備一個緩衝區,然後把要記錄的命令先臨時儲存在這裡,然後再擇機寫入檔案,我把這個臨時緩衝區叫做aof_buf

突然掛了!Redis快取都在記憶體中,這下完了!

說幹就幹,我試了一下,竟然發現資料沒有寫入到檔案中去。多方打聽才知道,原來作業系統也有個快取區,我寫的資料被他快取起來了,沒有給我寫入到檔案中去,這不是坑爹呢嘛!

看來,我寫完了還得要去重新整理一下,把資料真正給寫下去,思來想去,我還是提供一個引數,讓業務程式去設定什麼時候重新整理吧。

appendfsync引數,三個取值:

  • always: 每個事件週期都同步重新整理一次
  • everysec: 每一秒都同步重新整理一次
  • no: 我只管寫,讓作業系統自己決定什麼時候真正寫入吧

AOF重寫

這一次我不像之前那麼衝動,我決定先試執行一段時間再去告訴MySQL大哥,免得又被他戳到軟肋。

試用了一段時間,各方面都執行良好,不過我發現隨著時間的推移,我寫的這個AOF備份檔案越來越大,越來越大!不僅非常佔硬碟空間,複製移動,載入分析都非常的麻煩耗時。

我得想個辦法把檔案給壓縮一下,我把這個過程叫做AOF重寫

突然掛了!Redis快取都在記憶體中,這下完了!

一開始,我打算去分析原來的AOF檔案,然後將其中的冗餘指令去掉,來給AOF檔案瘦瘦身,不過我很快放棄了這個想法,這工作量實在太大了,分析起來也頗為麻煩,浪費很多精力跟時間。

原來的一條條記錄這種方式實在是太笨了,資料改來改去,有很多中間狀態都沒用,我何不就把最終都資料狀態記錄下來就好了?

比如:

  • RPUSH name_list '程式設計技術宇宙'
  • RPUSH name_list '帥地玩程式設計'
  • RPUSH name_list '後端技術學堂'

可以合併成一條搞定:

  • RPUSH name_list '程式設計技術宇宙' '帥地玩程式設計' '後端技術學堂'

AOF檔案重寫的思路我是有了,不過這件事幹起來還是很耗時間,我決定和RDB方式一樣,fork出一個子程式來做這件事情。

謹慎如我,發現這樣做之後,子程式在重寫期間,我要是修改了資料,就會出現和重寫的內容不一致的情況!MySQL大哥肯定會挑刺兒,我還得把這個漏洞給補上。

突然掛了!Redis快取都在記憶體中,這下完了!

於是,我在之前的aof_buf之外,又準備了一個緩衝區:AOF重寫緩衝區

從建立重寫子程式開始的那一刻起,我把後面來的寫入命令也copy一份寫到這個重寫緩衝區中,等到子程式重寫AOF檔案結束之後,我再把這個緩衝區中的命令寫入到新的AOF檔案中。

最後再重新命名新的AOF檔案,替換掉原來的那個臃腫不堪的大檔案,終於大功告成!

突然掛了!Redis快取都在記憶體中,這下完了!

再三確定我的思路沒有問題之後,我帶著新的方案再次找到了MySQL大哥,我都做到這份兒上了,這一次,想必他應該無話可說了吧?

MySQL大哥看了我的方案露出了滿意的笑容,只是問了一個問題:

這AOF方案這麼好了,RDB方案是不是可以不要了呢?

萬萬沒想到,他居然問我這個問題,我竟陷入了沉思,你覺得我該怎麼回答好呢?

彩蛋

“你怎麼又崩潰了?”

“不好意思,又遇到bug了,不過不用擔心,我現在可以快速恢復了!”

“那老崩潰也不是事兒啊,你只有一個例項太不可靠了,去找幾個幫手吧!”

預知詳情,請關注後續精彩···

 

突然掛了!Redis快取都在記憶體中,這下完了!