【長文】帶你搞明白內存數據庫Redis
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
一、概述Redis,英文全稱是Remote Dictionary Server(遠程字典服務),是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫,并提供多種語言的API。 與MySQL數據庫不同的是,Redis的數據是存在內存中的。它的讀寫速度非常快,每秒可以處理超過10萬次讀寫操作。因此redis被廣泛應用于緩存,另外,Redis也經常用來做分布式鎖。除此之外,Redis支持事務、持久化、LUA 腳本、LRU 驅動事件、多種集群方案。 提及我的誕生,我與關系數據庫MySQL之間有著不解之緣。在我尚未降臨這個世界之前,MySQL歷經艱辛,伴隨著互聯網的飛速發展,它所承載的數據量日益龐大,用戶請求也如潮水般洶涌而至。每一次的用戶請求,都化作了對它無盡的讀寫挑戰,使得MySQL備受煎熬。特別是在“雙11”、“618”這樣的全民購物狂歡節,對MySQL而言,無疑是難熬的考驗時刻。 后來,MySQL向我透露了一個秘密。它告訴我,其實大多數的用戶請求都是讀取操作,而且往往都是對同一數據的反復查詢,這導致它不得不花費大量時間進行磁盤I/O操作,這無疑是一種巨大的資源浪費。 有人開始深思,是否可以借鑒CPU的工作原理,為數據庫也添加一個緩存機制呢?于是,我便應運而生,踏上了這個世界的舞臺。 自誕生之初,我便與MySQL結下了深厚的友誼。我們攜手并肩,共同出現在后端服務器的舞臺上。每當應用程序需要從MySQL查詢數據時,它們會首先在我這里進行登記。當再次需要這些數據時,它們會首先向我發出請求。如果我這里有它們所需的數據,它們便無需再勞煩MySQL;若我這里沒有,它們才會轉向MySQL尋求幫助。 如此,我便成為了MySQL的得力助手,與它共同應對著日益增長的數據挑戰。我們攜手前行,共同書寫著數據庫世界的輝煌篇章。 二、支持的數據結構大多數小伙伴都知道,為了方便使用,我支持以下這五種基本類型:
string 字符串最基礎的數據結構。字符串類型的值實際可以是字符串(簡單的字符串、復雜的字符串(例如JSON、XML))、數字 (整數、浮點數),甚至是二進制(圖片、音頻、視頻),但是值最大不能超過512MB。 字符串主要有以下幾個典型使用場景:
hash 哈希類型是指鍵值本身又是一個鍵值對結構。 哈希主要有以下典型應用場景:
list 列表(list)類型是用來存儲多個有序的字符串。列表是一種比較靈活的數據結構,它可以充當棧和隊列的角色 列表主要有以下幾種使用場景:
set 集合(set)類型也是用來保存多個的字符串元素,但和列表類型不一 樣的是,集合中不允許有重復元素,并且集合中的元素是無序的。 集合主要有如下使用場景:
sorted set 有序集合中的元素可以排序。但是它和列表使用索引下標作為排序依據不同的是,它給每個元素設置一個權重(score)作為排序的依據。 有序集合主要應用場景:
我還有三種特殊的數據結構類型
因為我把登記的數據都記錄在內存中,不用去執行慢如蝸牛的I/O操作,所以找我要比找MySQL要省去了不少的時間呢。 可別小瞧這簡單的一個改變,我可為MySQL減輕了不小的負擔!隨著程序的運行,我緩存的數據越來越多,有相當部分時間我都給它擋住了用戶請求,這一下它可樂得清閑自在了! 有了我的加入,網絡服務的性能提升了不少,這都歸功于我為數據庫擋下了不少的事兒。 三、緩存過期 && 緩存淘汰不過很快我發現事情不妙了,我緩存的數據都是在內存中,可是就算是在服務器上,內存的空間資源還是很有限的,不能無節制的這么存下去,我得想個辦法,不然吃棗藥丸。 不久,我想到了一個辦法:給緩存內容設置一個超時時間,具體設置多長交給應用程序們去設置,我要做的就是把過期了的內容從我里面刪除掉,及時騰出空間就行了。 超時時間有了,我該在什么時候去干這個清理的活呢? 最簡單的就是定期刪除,我決定100ms就做一次,一秒鐘就是10次! 我清理的時候也不能一口氣把所有過期的都給刪除掉,我這里面存了大量的數據,要全面掃一遍的話那不知道要花多久時間,會嚴重影響我接待新的客戶請求的! 時間緊任務重,我只好隨機選擇一部分來清理,能緩解內存壓力就行了。 就這樣過了一段日子,我發現有些個鍵值運氣比較好,每次都沒有被我的隨機算法選中,每次都能幸免于難,這可不行,這些長時間過期的數據一直霸占著不少的內存空間!氣抖冷! 我眼里可揉不得沙子!于是在原來定期刪除的基礎上,又加了一招: 那些原來逃脫我隨機選擇算法的鍵值,一旦遇到查詢請求,被我發現已經超期了,那我就絕不客氣,立即刪除。 這種方式因為是被動式觸發的,不查詢就不會發生,所以也叫惰性刪除! 可是,還是有部分鍵值,既逃脫了我的隨機選擇算法,又一直沒有被查詢,導致它們一直逍遙法外!而于此同時,可以使用的內存空間卻越來越少。 而且就算退一步講,我能夠把過期的數據都刪除掉,那萬一過期時間設置的很長,還沒等到我去清理,內存就吃滿了,一樣要吃棗藥丸,所以我還得想個辦法。 我苦思良久,終于憋出了個大招:內存淘汰策略,這一次我要徹底解決問題! 我提供了8種淘汰策略供應用程序選擇,用于我遇到內存不足時該如何決策:
有了上面幾套組合拳,我再也不用擔心過期數據多了把空間撐滿的問題了~ 我為了避免頻繁的觸發淘汰策略,每次會淘汰掉一批數據,淘汰的數據的大小其實是和置換的大小來確定的,如果置換的數據量大,淘汰的肯定也多。 四、緩存穿透 && 布隆過濾器我的日子過的還挺舒坦,不過MySQL大哥就沒我這么舒坦了,有時候遇到些煩人的請求,查詢的數據不存在,MySQL就要白忙活一場!不僅如此,因為不存在,我也沒法緩存啊,導致同樣的請求來了每次都要去讓MySQL白忙活一場。我作為緩存的價值就沒得到體現啦!這就是人們常說的緩存穿透。 這一來二去,MySQL大哥忍不住了:“唉,兄弟,能不能幫忙想個辦法,把那些明知道不會有結果的查詢請求給我擋一下” 這時我想到了我的另外一個好朋友:布隆過濾器 我這位朋友別的本事沒有,就擅長從超大的數據集中快速告訴你查找的數據存不存在(悄悄告訴你,我的這位朋友有一點不靠譜,它告訴你存在的話不能全信,其實有可能是不存在的,不過它他要是告訴你不存在的話,那就一定不存在,同時他也不支持刪除元素)。它是一個連續的數據結構,每個存儲位存儲都是一個 五、緩存擊穿 && 緩存雪崩這之后過了一段時間太平日子,直到那一天··· 有一次,MySQL那家伙正優哉游哉的摸魚,突然一大堆請求給他懟了過去,給他打了一個措手不及。 一陣忙活之后,MySQL怒氣沖沖的找到了我,“兄弟,咋回事啊,怎么一下子來的這么猛” 我查看了日志,趕緊解釋到:“大哥,實在不好意思,剛剛有一個熱點數據到了過期時間,被我刪掉了,不巧的是隨后就有對這個數據的大量查詢請求來了,我這里已經刪了,所以請求都發到你那里來了” “你這干的叫啥事,下次注意點啊”,MySQL大哥一臉不高興的離開了。 這一件小事我也沒怎么放在心上,隨后就拋之腦后了,卻沒曾想幾天之后竟捅了更大的簍子。 那一天,又出現了大量的網絡請求發到了MySQL那邊,比上一次的規模大得多,MySQL大哥一會兒功夫就給干趴下了好幾次! 等了好半天這一波流量才算過去,MySQL才緩過神來。 “老弟,這一次又是什么原因?”,MySQL大哥累的沒了力氣。 “這一次比上一次更不巧,這一次是一大批數據幾乎同時過了有效期,然后又發生了很多對這些數據的請求,所以比起上一次這規模更大了” MySQL大哥聽了眉頭一皺,“那你倒是想個辦法啊,三天兩頭折磨我,這誰頂得住啊?” “其實我也很無奈,這個時間也不是我設置的,要不我去找應用程序說說,讓他把緩存過期時間設置的均勻一些?至少別讓大量數據集體失效” “走,咱倆一起去” 后來,我倆去找應用程序商量了,不僅把鍵值的過期時間隨機了一下,還設置了熱點數據永不過期,這個問題緩解了不少。哦對了,我們還把這兩次發生的問題分別取了個名字:緩存擊穿和緩存雪崩。 我們終于又過上了舒適的日子··· 六、我可以用來干什么
作者: RDIF 出處: http://www.cnblogs.com/huyong/ 該文章在 2024/7/16 16:35:47 編輯過 |
關鍵字查詢
相關文章
正在查詢... |