大家好，我是 Redis，一個叫 Antirez 的男人把我?guī)У搅诉@個世界上......

[[350947]]

圖片來自 Pexels 

我是 Redis，MySQL 大哥被我害慘了

說起我的誕生，跟關(guān)系數(shù)據(jù)庫 MySQL 還挺有淵源的。

在我還沒來到這個世界上的時候，MySQL 過的很辛苦，互聯(lián)網(wǎng)發(fā)展的越來越快，它容納的數(shù)據(jù)也越來越多，用戶請求也隨之暴漲，而每一個用戶請求都變成了對它的一個又一個讀寫操作，MySQL 是苦不堪言。

 

尤其是到“雙 11”、“618“這種全民購物狂歡的日子，都是 MySQL 受苦受難的日子。

據(jù)后來 MySQL 告訴我說，其實有一大半的用戶請求都是讀操作，而且經(jīng)常都是重復(fù)查詢一個東西，浪費它很多時間去進(jìn)行磁盤 I/O。

后來有人就琢磨，是不是可以學(xué)學(xué) CPU，給數(shù)據(jù)庫也加一個緩存呢?于是我就誕生了!

出生不久，我就和 MySQL 成為了好朋友，我們倆常常攜手出現(xiàn)在后端服務(wù)器中。

應(yīng)用程序們從 MySQL 查詢到的數(shù)據(jù)，在我這里登記一下，后面再需要用到的時候，就先找我要，我這里沒有再找 MySQL 要。

 

為了方便使用，我支持好幾種數(shù)據(jù)結(jié)構(gòu)的存儲：

• String
• Hash
• List
• Set
• SortedSet
• Bitmap
• ······

因為我把登記的數(shù)據(jù)都記錄在內(nèi)存中，不用去執(zhí)行慢如蝸牛的 I/O 操作，所以找我要比找 MySQL 要省去了不少的時間呢。

可別小瞧這簡單的一個改變，我可為 MySQL 減輕了不小的負(fù)擔(dān)!隨著程序的運行，我緩存的數(shù)據(jù)越來越多，有相當(dāng)部分時間我都給它擋住了用戶請求，這一下它可樂得清閑自在了!

有了我的加入，網(wǎng)絡(luò)服務(wù)的性能提升了不少，這都?xì)w功于我為數(shù)據(jù)庫挨了不少槍子兒。

緩存過期&緩存淘汰

不過很快我發(fā)現(xiàn)事情不妙了，我緩存的數(shù)據(jù)都是在內(nèi)存中，可是就算是在服務(wù)器上，內(nèi)存的空間資源還是很有限的，不能無節(jié)制的這么存下去，我得想個辦法，不然吃棗藥丸。

不久，我想到了一個辦法：給緩存內(nèi)容設(shè)置一個超時時間，具體設(shè)置多長交給應(yīng)用程序們?nèi)ピO(shè)置，我要做的就是把過期了的內(nèi)容從我里面刪除掉，及時騰出空間就行了。

 

超時時間有了，我該在什么時候去干這個清理的活呢?最簡單的就是定期刪除，我決定 100ms 就做一次，一秒鐘就是 10 次!

我清理的時候也不能一口氣把所有過期的都給刪除掉，我這里面存了大量的數(shù)據(jù)，要全面掃一遍的話那不知道要花多久時間，會嚴(yán)重影響我接待新的客戶請求的!

時間緊任務(wù)重，我只好隨機選擇一部分來清理，能緩解內(nèi)存壓力就行了。

 

就這樣過了一段日子，我發(fā)現(xiàn)有些個鍵值運氣比較好，每次都沒有被我的隨機算法選中，每次都能幸免于難，這可不行，這些長時間過期的數(shù)據(jù)一直霸占著不少的內(nèi)存空間!氣抖冷!

我眼里可揉不得沙子!于是在原來定期刪除的基礎(chǔ)上，又加了一招：那些原來逃脫我隨機選擇算法的鍵值，一旦遇到查詢請求，被我發(fā)現(xiàn)已經(jīng)超期了，那我就絕不客氣，立即刪除。

這種方式因為是被動式觸發(fā)的，不查詢就不會發(fā)生，所以也叫惰性刪除!

可是，還是有部分鍵值，既逃脫了我的隨機選擇算法，又一直沒有被查詢，導(dǎo)致它們一直逍遙法外!而于此同時，可以使用的內(nèi)存空間卻越來越少。

 

而且就算退一步講，我能夠把過期的數(shù)據(jù)都刪除掉，那萬一過期時間設(shè)置的很長，還沒等到我去清理，內(nèi)存就吃滿了，一樣要吃棗藥丸，所以我還得想個辦法。

我苦思良久，終于憋出了個大招：內(nèi)存淘汰策略，這一次我要徹底解決問題!

我提供了 8 種策略供應(yīng)用程序選擇，用于我遇到內(nèi)存不足時該如何決策：

• noeviction：返回錯誤，不會刪除任何鍵值。
• allkeys-lru：使用 LRU 算法刪除最近最少使用的鍵值。
• volatile-lru：使用 LRU 算法從設(shè)置了過期時間的鍵集合中刪除最近最少使用的鍵值。
• allkeys-random：從所有 key 隨機刪除。
• volatile-random：從設(shè)置了過期時間的鍵的集合中隨機刪除。
• volatile-ttl：從設(shè)置了過期時間的鍵中刪除剩余時間最短的鍵。
• volatile-lfu：從配置了過期時間的鍵中刪除使用頻率最少的鍵。
• allkeys-lfu：從所有鍵中刪除使用頻率最少的鍵。

有了上面幾套組合拳，我再也不用擔(dān)心過期數(shù)據(jù)多了把空間撐滿的問題了~

緩存穿透&布隆過濾器

我的日子過的還挺舒坦，不過 MySQL 大哥就沒我這么舒坦了，有時候遇到些煩人的請求，查詢的數(shù)據(jù)不存在，MySQL 就要白忙活一場!

不僅如此，因為不存在，我也沒法緩存啊，導(dǎo)致同樣的請求來了每次都要去讓 MySQL 白忙活一場。

我作為緩存的價值就沒得到體現(xiàn)啦!這就是人們常說的緩存穿透。

 

這一來二去，MySQL 大哥忍不住了：“唉，兄弟，能不能幫忙想個辦法，把那些明知道不會有結(jié)果的查詢請求給我擋一下”。

這時我想到了我的另外一個好朋友：布隆過濾器。

 

我這位朋友別的本事沒有，就擅長從超大的數(shù)據(jù)集中快速告訴你查找的數(shù)據(jù)存不存在(悄悄告訴你，我的這位朋友有一點不靠譜，它告訴你存在的話不能全信，其實有可能是不存在的，不過它他要是告訴你不存在的話，那就一定不存在)。

 

我把這位朋友介紹給了應(yīng)用程序，不存在的數(shù)據(jù)就不必去叨擾 MySQL 了，輕松幫忙解決了緩存穿透的問題。

緩存擊穿&緩存雪崩

這之后過了一段時間太平日子，直到那一天···

有一次，MySQL 那家伙正優(yōu)哉游哉的摸魚，突然一大堆請求給他懟了過去，給他打了一個措手不及。

一陣忙活之后，MySQL 怒氣沖沖的找到了我，“兄弟，咋回事啊，怎么一下子來的這么猛”。

 

我查看了日志，趕緊解釋到：“大哥，實在不好意思，剛剛有一個熱點數(shù)據(jù)到了過期時間，被我刪掉了，不巧的是隨后就有對這個數(shù)據(jù)的大量查詢請求來了，我這里已經(jīng)刪了，所以請求都發(fā)到你那里來了”。

“你這干的叫啥事，下次注意點啊”，MySQL 大哥一臉不高興的離開了。

這一件小事我也沒怎么放在心上，隨后就拋之腦后了，卻沒曾想幾天之后竟捅了更大的簍子。

那一天，又出現(xiàn)了大量的網(wǎng)絡(luò)請求發(fā)到了 MySQL 那邊，比上一次的規(guī)模大得多，MySQL 大哥一會兒功夫就給干趴下了好幾次!

等了好半天這一波流量才算過去，MySQL 才緩過神來。

“老弟，這一次又是什么原因?”，MySQL 大哥累的沒了力氣。

“這一次比上一次更不巧，這一次是一大批數(shù)據(jù)幾乎同時過了有效期，然后又發(fā)生了很多對這些數(shù)據(jù)的請求，所以比起上一次這規(guī)模更大了”。

 

MySQL 大哥聽了眉頭一皺，“那你倒是想個辦法啊，三天兩頭折磨我，這誰頂?shù)米“?”

“其實我也很無奈，這個時間也不是我設(shè)置的，要不我去找應(yīng)用程序說說，讓他把緩存過期時間設(shè)置的均勻一些?至少別讓大量數(shù)據(jù)集體失效”。

“走，咱倆一起去”。

后來，我倆去找應(yīng)用程序商量了，不僅把鍵值的過期時間隨機了一下，還設(shè)置了熱點數(shù)據(jù)永不過期，這個問題緩解了不少。哦對了，我們還把這兩次發(fā)生的問題分別取了個名字：緩存擊穿和緩存雪崩。

我們終于又過上了舒適的日子···

彩蛋：那天，我正在努力工作中，不小心出了錯，整個進(jìn)程都崩潰了。當(dāng)我再次啟動后，之前緩存的數(shù)據(jù)全都沒了，暴風(fēng)雨似的請求再一次全都懟到了 MySQL 大哥那里。唉，要是我能夠記住崩潰前緩存的內(nèi)容就好了...

突然掛了!Redis 緩存都在內(nèi)存中，這下完了!

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

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

“我怎么睡著了?”

“嗨，你剛才是不是出現(xiàn)了錯誤，整個進(jìn)程都崩潰了!害得一大堆查詢請求都給我懟過來了!”，MySQL 說到。

剛剛醒來，腦子還有點懵，MySQL 大哥扶我起來繼續(xù)工作。

“糟了!我之前緩存的數(shù)據(jù)全都不見了!”

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

我尷尬的搖了搖頭，“我都是保存在內(nèi)存中的，所以才那么快啊”。

“那也可以在硬盤上保存一下啊，遇到這種情況全部從頭再來建立緩存，這不浪費時間嘛!”

 

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

RDB 持久化

沒幾天，我就拿出了一套方案：RDB。

既然我的數(shù)據(jù)都在內(nèi)存中存放著，最簡單的就是遍歷一遍把它們?nèi)紝懭胛募小?/p>

為了節(jié)約空間，我定義了一個二進(jìn)制的格式，把數(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個寫入 

多個條件可以組合使用，只要上面一個條件滿足，我就會去進(jìn)行備份。

后來我又想了一下，這樣還是不行，我得 fork 出一個子進(jìn)程去做這件事，不能浪費我的時間。

有了備份文件，下次我再遇到崩潰退出，甚至服務(wù)器斷電罷工了，只要我的備份文件還在，我就能在啟動的時候讀取，快速恢復(fù)之前的狀態(tài)啦!

[[350958]] 

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 
··· 

“看，這些是我的二進(jìn)制日志 binlog，你猜猜看里面都裝了些什么?”，MySQL 大哥指著這一堆文件說到。

我看了一眼，全是一堆二進(jìn)制數(shù)據(jù)，這哪看得懂，我搖了搖頭。

“這里面呀記錄了我對數(shù)據(jù)執(zhí)行更改的所有操作，像是 INSERT，UPDATE、DELETE 等等動作，等我要進(jìn)行數(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 'A'
• RPUSH name_list 'B'
• RPUSH name_list 'C'

可以合并成一條搞定：RPUSH name_list 'A' 'B' 'C'.

AOF 文件重寫的思路我是有了，不過這件事干起來還是很耗時間，我決定和 RDB 方式一樣，fork 出一個子進(jìn)程來做這件事情。

謹(jǐn)慎如我，發(fā)現(xiàn)這樣做之后，子進(jìn)程在重寫期間，我要是修改了數(shù)據(jù)，就會出現(xiàn)和重寫的內(nèi)容不一致的情況!MySQL 大哥肯定會挑刺兒，我還得把這個漏洞給補上。

 

于是，我在之前的 aof_buf 之外，又準(zhǔn)備了一個緩沖區(qū)：AOF 重寫緩沖區(qū)。

從創(chuàng)建重寫子進(jìn)程開始的那一刻起，我把后面來的寫入命令也 copy 一份寫到這個重寫緩沖區(qū)中，等到子進(jìn)程重寫 AOF 文件結(jié)束之后，我再把這個緩沖區(qū)中的命令寫入到新的 AOF 文件中。

最后再重命名新的 AOF 文件，替換掉原來的那個臃腫不堪的大文件，終于大功告成!

 

再三確定我的思路沒有問題之后，我?guī)е碌姆桨冈俅握业搅?MySQL 大哥，我都做到這份兒上了，這一次，想必他應(yīng)該無話可說了吧?

MySQL 大哥看了我的方案露出了滿意的笑容，只是問了一個問題：這 AOF 方案這么好了，RDB 方案是不是可以不要了呢?

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

彩蛋：“你怎么又崩潰了?”，“不好意思，又遇到 Bug 了，不過不用擔(dān)心，我現(xiàn)在可以快速恢復(fù)了!”。“那老崩潰也不是事兒啊，你只有一個實例太不可靠了，去找?guī)讉€幫手吧!”

那天，我被拉入一個 Redis 群聊...

那天，Redis 基友群里，許久未見的大白發(fā)來了一條消息···

 

于是，大白拉了一個新的群：

 

以后的日子中，咱們哥仨相互配合，日常工作中最多的就是數(shù)據(jù)同步了。

 

如果主節(jié)點有數(shù)據(jù)寫入、刪除、修改命令，也會把這些命令挨個通知到從節(jié)點，我們把這叫做命令傳播。

 

通過這樣的方式，我們主節(jié)點與從節(jié)點之間數(shù)據(jù)就能保持同步了!有一次，我不小心掉線了～

 

我們用上了新的數(shù)據(jù)同步策略，效率高了不少，就算偶爾掉個線，也能很快把缺失的數(shù)據(jù)給補上。

就這樣過了一段時間···

 

新添了人手，我們準(zhǔn)備大干一場!

為了及時獲得和更新主從節(jié)點的信息，咱們哨兵每隔十秒鐘就要用 INFO 命令去問候一下主節(jié)點，主節(jié)點會告訴我他有哪些從節(jié)點!

 

為了更加及時知道大家是否掉線，咱們哨兵每隔一秒都要用 PING 命令問候一下群里的各個小伙伴：

 

 

如果在設(shè)置的時間里沒有收到回復(fù)，我就知道這家伙多半是跪了，就該啟動故障轉(zhuǎn)移了。

不過這只是我的主觀意見，光我一個人說了不算，為了防止誤判，我還得去管理員小群里征求一下大家的意見：

 

接下來，咱們就開始了第一次選舉。

 

經(jīng)過一番努力，我終于完成了故障轉(zhuǎn)移，現(xiàn)在 R2 是主節(jié)點了。

不過沒過多久，R1 又回來了：

 

以上就是我們的日常工作了，通過咱們幾個小伙伴的齊心協(xié)力，構(gòu)成了一個高可用的緩存服務(wù)，MySQL 大哥再也不敢小瞧我們了。

 

作者：軒轅之風(fēng)

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號編程技術(shù)宇宙(ID：xuanyuancoding)