前言
歡迎各位進群973961276一起聊聊技術吹吹牛，而且每週都會有幾次抽獎送書的活動哦，來看看你是非酋還是歐皇。
我是Redis
你好，我是Redis，一個叫Antirez的男人把我帶到了這個世界上。
說起我的誕生，跟關聯式資料庫MySQL還挺有淵源的。
在我還沒來到這個世界上的時候，MySQL過的很辛苦，網際網路發展的越來越快，它容納的資料也越來越多，使用者請求也隨之暴漲，而每一個使用者請求都變成了對它的一個又一個讀寫操作，MySQL是苦不堪言。尤其是到“雙11”、“618“這種全民購物狂歡的日子，都是MySQL受苦受難的日子。
據後來MySQL告訴我說，其實有一大半的使用者請求都是讀操作，而且經常都是重複查詢一個東西，浪費它很多時間去進行磁碟I/O。
後來有人就琢磨，是不是可以學學CPU，給資料庫也加一個快取呢？於是我就誕生了！
出生不久，我就和MySQL成為了好朋友，我們倆常常攜手出現在後端伺服器中。
應用程式們從MySQL查詢到的資料，在我這裡登記一下，後面再需要用到的時候，就先找我要，我這裡沒有再找MySQL要。
為了方便使用，我支援好幾種資料結構的儲存：
- String
- Hash
- List
- Set
- SortedSet
- Bitmap
- ······
因為我把登記的資料都記錄在記憶體中，不用去執行慢如蝸牛的I/O操作，所以找我要比找MySQL要省去了不少的時間呢。
可別小瞧這簡單的一個改變，我可為MySQL減輕了不小的負擔！隨著程式的執行，我快取的資料越來越多，有相當部分時間我都給它擋住了使用者請求，這一下它可樂得清閒自在了！
有了我的加入，網路服務的效能提升了不少，這都歸功於我為資料庫捱了不少槍子兒。
零基礎和大三大四的朋友看這裡>>c/c++ 企業級專案實戰
已經工作了想繼續自我提升跳槽漲薪的工程師看這裡>>c/c++ linux伺服器高階架構師學習
技術問題加我WeChat：lingshengxy免費諮詢，有時間會一一回答
快取過期 && 快取淘汰
不過很快我發現事情不妙了，我快取的資料都是在記憶體中，可是就算是在伺服器上，記憶體的空間資源還是很有限的，不能無節制的這麼存下去，我得想個辦法，不然吃棗藥丸。
不久，我想到了一個辦法：給快取內容設定一個超時時間，具體設定多長交給應用程式們去設定，我要做的就是把過期了的內容從我裡面刪除掉，及時騰出空間就行了。
超時時間有了，我該在什麼時候去幹這個清理的活呢？
最簡單的就是定期刪除，我決定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大哥忍不住了：“唉，兄弟，能不能幫忙想個辦法，把那些明知道不會有結果的查詢請求給我擋一下”
這時我想到了我的另外一個好朋友：布隆過濾器
我這位朋友別的本事沒有，就擅長從超大的資料集中快速告訴你查詢的資料存不存在（悄悄告訴你，我的這位朋友有一點不靠譜，它告訴你存在的話不能全信，其實有可能是不存在的，不過它他要是告訴你不存在的話，那就一定不存在）。
如果你對我這位朋友感興趣的話，可以看看這裡《白話布隆過濾器BloomFilter》。
我把這位朋友介紹給了應用程式，不存在的資料就不必去叨擾MySQL了，輕鬆幫忙解決了快取穿透的問題。
快取擊穿 && 快取雪崩
這之後過了一段時間太平日子，直到那一天···
有一次，MySQL那傢伙正優哉遊哉的摸魚，突然一大堆請求給他懟了過去，給他打了一個措手不及。
一陣忙活之後，MySQL怒氣衝衝的找到了我，“兄弟，咋回事啊，怎麼一下子來的這麼猛”
我檢視了日誌，趕緊解釋到：“大哥，實在不好意思，剛剛有一個熱點資料到了過期時間，被我刪掉了，不巧的是隨後就有對這個資料的大量查詢請求來了，我這裡已經刪了，所以請求都發到你那裡來了”
“你這乾的叫啥事，下次注意點啊”，MySQL大哥一臉不高興的離開了。
這一件小事我也沒怎麼放在心上，隨後就拋之腦後了，卻沒曾想幾天之後竟捅了更大的簍子。
那一天，又出現了大量的網路請求發到了MySQL那邊，比上一次的規模大得多，MySQL大哥一會兒功夫就給幹趴下了好幾次！
等了好半天這一波流量才算過去，MySQL才緩過神來。
“老弟，這一次又是什麼原因？”，MySQL大哥累的沒了力氣。
“這一次比上一次更不巧，這一次是一大批資料幾乎同時過了有效期，然後又發生了很多對這些資料的請求，所以比起上一次這規模更大了”
MySQL大哥聽了眉頭一皺，“那你倒是想個辦法啊，三天兩頭折磨我，這誰頂得住啊？”
“其實我也很無奈，這個時間也不是我設定的，要不我去找應用程式說說，讓他把快取過期時間設定的均勻一些？至少別讓大量資料集體失效”
“走，我們倆一起去”
後來，我倆去找應用程式商量了，不僅把鍵值的過期時間隨機了一下，還設定了熱點資料永不過期，這個問題緩解了不少。哦對了，我們還把這兩次發生的問題分別取了個名字：快取擊穿和快取雪崩。
我們終於又過上了舒適的日子···
彩蛋
那天，我正在努力工作中，不小心出了錯，整個程式都崩潰了。
當我再次啟動後，之前快取的資料全都沒了，暴風雨似的請求再一次全都懟到了MySQL大哥那裡。
唉，要是我能夠記住崩潰前快取的內容就好了···
預知後事如何，請關注後續精彩······
本作品採用《CC 協議》，轉載必須註明作者和本文連結