大家好，我是 Redis，一個叫 Antirez 的男人把我帶到了這個世界上......

[[350947]]

圖片來自 Pexels 

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

說起我的誕生，跟關系數據庫 MySQL 還挺有淵源的。

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

 

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

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

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

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

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

 

為了方便使用，我支持好幾種數據結構的存儲：

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

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

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

有了我的加入，網絡服務的性能提升了不少，這都歸功于我為數據庫挨了不少槍子兒。

緩存過期&緩存淘汰

不過很快我發現事情不妙了，我緩存的數據都是在內存中，可是就算是在服務器上，內存的空間資源還是很有限的，不能無節制的這么存下去，我得想個辦法，不然吃棗藥丸。

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

 

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

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

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

 

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

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

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

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

 

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

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

我提供了 8 種策略供應用程序選擇，用于我遇到內存不足時該如何決策：

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

有了上面幾套組合拳，我再也不用擔心過期數據多了把空間撐滿的問題了~

緩存穿透&布隆過濾器

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

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

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

 

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

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

 

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

 

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

緩存擊穿&緩存雪崩

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

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

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

 

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

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

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

那一天，又出現了大量的網絡請求發到了 MySQL 那邊，比上一次的規模大得多，MySQL 大哥一會兒功夫就給干趴下了好幾次!

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

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

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

 

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

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

“走，咱倆一起去”。

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

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

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

突然掛了!Redis 緩存都在內存中，這下完了!

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

慢慢睜開眼睛，原來旁邊是 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 出一個子進程去做這件事，不能浪費我的時間。

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

[[350958]] 

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 'A'
• RPUSH name_list 'B'
• RPUSH name_list 'C'

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

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

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

 

于是，我在之前的 aof_buf 之外，又準備了一個緩沖區：AOF 重寫緩沖區。

從創建重寫子進程開始的那一刻起，我把后面來的寫入命令也 copy 一份寫到這個重寫緩沖區中，等到子進程重寫 AOF 文件結束之后，我再把這個緩沖區中的命令寫入到新的 AOF 文件中。

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

 

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

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

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

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

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

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

 

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

 

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

 

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

 

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

 

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

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

 

新添了人手，我們準備大干一場!

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

 

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

 

 

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

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

 

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

 

經過一番努力，我終于完成了故障轉移，現在 R2 是主節點了。

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

 

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

 

作者：軒轅之風

編輯：陶家龍

出處：轉載自公眾號編程技術宇宙(ID：xuanyuancoding)