關於redis緩存數據庫的一些思考

今晚無聊,躺在牀上,在刷技術文章時,看見了一篇關於redis緩存的文章 寫的蠻好,這也就引發了我對於redis思考!

不如往深了說 引發了我對於追求探索技術本質的一些思考 平時在網上刷到不少關於redis的文章,我也在項目中常常用到redis這個緩存數據庫 記得本身初學redis時 老是糾結技術若是去學 可是隨着閱歷以及學習能力和經驗的提升 本身也對技術也有一些悟出來的道理 或者說是如何學好技術 日後有時間或者哪天心血來潮了寫一篇關於本身對於技術的認知

仍是進入主題,在網上常常刷到關於redis的文章,本身也常常在項目中用到redis,可是本身歷來沒有太過深究redis,內心老以爲不得勁 因而今晚就心血來潮了寫一篇關於本身對redis的一些思考

這裏我就不說redis是幹什麼的了,若是不知道看下我以前寫的redis文章,這些文章中也有官網的內容 由於我也是從官網學的)

1.聊聊redis緩存穿透問題

如何理解緩存穿透呢?就是當請求訪問過來時 先去查詢redis緩存,若是緩存中沒有, 再去查詢mysql數據庫, 而後mysql數據庫返回數據到redis緩存中, redis接收數據並把數據存儲起來, 這樣當下次請求過來時,服務端就直接查詢redis緩存了並返回給客戶端,沒必要再去查詢mysql,緩解了數據庫壓力,並提升了效率
這是咱們的正常狀況對不對!

但但但但但但可是......有沒有想過一個問題,若是是黑客惡意攻擊,客戶端發起的請求中的數據,咱們緩存中不只沒有,就連咱們的mysql中也沒有! 這下完犢子了 這下客戶端只要重複的發送這個請求,全部的請求會通過redis後而後再來請求咱們的mysql,由於咱們數據庫中沒有呀,因此查詢不到,也沒有數據往redis中存),這就是緩存穿透

那麼若是是一個黑客惡意發起請求,mysql就有可能在長時間內持續承受大量的請求,mysql這時候內心很苦,很快就會撂挑子不幹了,直接宕機,(接下來,整個系統宕機,而後你就抓緊刪庫跑路吧,(逃,

若是是大型項目的話,這個損失是很大的

那咱們就要像羔羊同樣任人宰割嗎?NONONO,redis還有一個好兄弟,這個好兄弟叫做布隆過濾器

這個好兄弟能夠存放大數據量,(偷偷告訴你,存放大數據量是他的優勢,可是他也有缺點,就是查詢到的結果不必定準確,0表明必定沒有,1表明不必定有,布隆過濾器這位redis的好兄弟我這裏就不介紹了,只介紹這位好兄弟如何仗義行俠幫助咱們的redis

在中間加了這位好兄弟,那麼當請求進來後,會首先通過咱們的布隆過濾器,這個好兄弟先判斷這個數據存不存在,若判斷不存在直接丟棄請求,若這個數據存在再去進行redis查詢,而後執行下一步,最後響應,有了這位好兄弟,咱們就能夠講數據庫中全部的查詢條件，放入布隆過濾器中,全部的請求先交給這位好兄弟來處理(這位好兄弟是有那麼一點不靠譜,可是大致上並不影響

其實還有一種解決方案是把查詢到的空值的key緩存起來並設置過時時間,可是會有一種弊端,就是如何發起大量的請求,那豈不是要接收多少空值的key,都要存在redis中,redis是內存數據庫,內存不要錢嗎?並且遭到惡意攻擊,能有多大內存和黑客剛呢?

具體場景具體用法:

1. 若是空值的key少能夠考慮緩存起來
2. 若是空值的key多而且不重複,仍是讓布隆過濾器這位好兄弟來拔刀相助比較好

2.聊聊redis緩存雪崩問題

緩存雪崩能夠這樣理解,雪崩雪崩嘛!這些緩存就像雪同樣發生了崩塌,緩存是存在於咱們的redis這位好兄弟這裏的,這位好兄弟日常管理着這些緩存,加入哪一天這兄弟不高興了,撒手不幹了,宕機),那豈不是這些緩存數據又沒了,當請求來臨時又要mysql兄弟處理了,mysql兄弟看到這麼些請求過來淦它,內心直髮怵啊!簡直是瑟瑟發抖,形成告終果就是數據庫崩潰,系統崩潰 這就是咱們緩存雪崩,簡單來講redis宕機了

解決方案也很簡單,簡單粗暴,一個不行來倆甚至更多,一節更比六節強,搭建redis集羣而後交給hystrix來監控

3.聊聊緩存擊穿問題

緩存擊穿這個和緩存穿透字面上有點像,可是區別在於緩存穿透是數據中沒有這個key,可是緩存擊穿是數據中有這個key,而且咱們要把這個key緩存到redis中,

好比淘寶雙11,並非全部的商品都要搞活動,只是一部分搞活動,那麼這一部分商品在活動開始時,必然會有大量的用戶去搶購,大量的請求),這時候若是咱們的數據在mysql中,mysql必然不幹了,mysql這位兄弟內存又要罵娘了,那麼咱們就須要redis來救場,提早把這些熱點的key(須要搞活動的商品)緩存到redis中,當活動開始時直接去淦redis,沒事redis扛得住,這樣就解決了這個問題

但但但但但可是.......若是這個key忽然在用戶還沒搶購完的時候,很媽離譜就過時了!那麼完犢子,mysql又要罵娘了

這就是緩存擊穿(熱點key過時問題)

解決方案:

1. 熱點key居然要媽離譜過時,咱們在設置熱點key時讓這個bi永不過時就完事了,簡單粗暴
2. 互斥鎖,當第一個查詢數據庫的請求發起時,給緩存中這個數據上鎖,其餘請求這個key等待,當第一個查詢數據庫打請求完成後解鎖,其餘請求直接從緩存中查