如何理解Redis的使用和原理

這篇文章主要介紹“如何理解Redis的使用和原理”，在日常操作中，相信很多人在如何理解Redis的使用和原理問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解Redis的使用和原理”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

舉個簡單的例子：如果所有首頁的Key失效時間都是12小時，中午12點刷新的，我零點有個秒殺活動大量用戶涌入，假設(shè)當時每秒 6000 個請求，本來緩存在可以扛住每秒 5000 個請求，但是緩存當時所有的Key都失效了。此時 1 秒 6000 個請求全部落數(shù)據(jù)庫，數(shù)據(jù)庫必然扛不住，它會報一下警，真實情況可能DBA都沒反應(yīng)過來就直接掛了。此時，如果沒用什么特別的方案來處理這個故障，DBA 很著急，重啟數(shù)據(jù)庫，但是數(shù)據(jù)庫立馬又被新的流量給打死了。這就是我理解的緩存雪崩。

我刻意看了下我做過的項目感覺再吊的都不允許這么大的QPS直接打DB去，不過沒慢SQL加上分庫，大表分表可能還還算能頂，但是跟用了Redis的差距還是很大

同一時間大面積失效，那一瞬間Redis跟沒有一樣，那這個數(shù)量級別的請求直接打到數(shù)據(jù)庫幾乎是災(zāi)難性的，你想想如果打掛的是一個用戶服務(wù)的庫，那其他依賴他的庫所有的接口幾乎都會報錯，如果沒做熔斷等策略基本上就是瞬間掛一片的節(jié)奏，你怎么重啟用戶都會把你打掛，等你能重啟的時候，用戶早就睡覺去了，并且對你的產(chǎn)品失去了信心，什么垃圾產(chǎn)品。

面試官摸了摸自己的頭發(fā)，嗯還不錯，那這種情況咋整？你都是怎么去應(yīng)對的？

處理緩存雪崩簡單，在批量往Redis存數(shù)據(jù)的時候，把每個Key的失效時間都加個隨機值就好了，這樣可以保證數(shù)據(jù)不會在同一時間大面積失效，我相信，Redis這點流量還是頂?shù)米〉摹?/p>

setRedis（Key，value，time + Math.random() * 10000）；

如果Redis是集群部署，將熱點數(shù)據(jù)均勻分布在不同的Redis庫中也能避免全部失效的問題，不過本渣我在生產(chǎn)環(huán)境中操作集群的時候，單個服務(wù)都是對應(yīng)的單個Redis分片，是為了方便數(shù)據(jù)的管理，但是也同樣有了可能會失效這樣的弊端，失效時間隨機是個好策略。

或者設(shè)置熱點數(shù)據(jù)永遠不過期，有更新操作就更新緩存就好了（比如運維更新了首頁商品，那你刷下緩存就完事了，不要設(shè)置過期時間），電商首頁的數(shù)據(jù)也可以用這個操作，保險。

那你了解緩存穿透和擊穿么，可以說說他們跟雪崩的區(qū)別么？

嗯，了解，我先說一下緩存穿透吧，緩存穿透是指緩存和數(shù)據(jù)庫中都沒有的數(shù)據(jù)，而用戶不斷發(fā)起請求，我們數(shù)據(jù)庫的 id 都是1開始自增上去的，如發(fā)起為id值為 -1 的數(shù)據(jù)或 id 為特別大不存在的數(shù)據(jù)。這時的用戶很可能是攻擊者，攻擊會導致數(shù)據(jù)庫壓力過大，嚴重會擊垮數(shù)據(jù)庫。

小點的單機系統(tǒng)，基本上用postman就能搞死，比如我自己買的阿里云服務(wù)

像這種你如果不對參數(shù)做校驗，數(shù)據(jù)庫id都是大于0的，我一直用小于0的參數(shù)去請求你，每次都能繞開Redis直接打到數(shù)據(jù)庫，數(shù)據(jù)庫也查不到，每次都這樣，并發(fā)高點就容易崩掉了。

至于緩存擊穿嘛，這個跟緩存雪崩有點像，但是又有一點不一樣，緩存雪崩是因為大面積的緩存失效，打崩了DB，而緩存擊穿不同的是緩存擊穿是指一個Key非常熱點，在不停的扛著大并發(fā)，大并發(fā)集中對這一個點進行訪問，當這個Key在失效的瞬間，持續(xù)的大并發(fā)就穿破緩存，直接請求數(shù)據(jù)庫，就像在一個完好無損的桶上鑿開了一個洞。

技術(shù)總結(jié)：

一般避免以上情況發(fā)生我們從三個時間段去分析下：

• 事前：Redis 高可用，主從+哨兵，Redis cluster，避免全盤崩潰。

• 事中：本地 ehcache 緩存 + Hystrix 限流+降級，避免** MySQL** 被打死。

• 事后：Redis 持久化 RDB+AOF，一旦重啟，自動從磁盤上加載數(shù)據(jù)，快速恢復緩存數(shù)據(jù)。

上面的幾點我會在吊打系列Redis篇全部講一下這個月應(yīng)該可以吧Redis更完，限流組件，可以設(shè)置每秒的請求，有多少能通過組件，剩余的未通過的請求，怎么辦？走降級！可以返回一些默認的值，或者友情提示，或者空白的值。

好處：

數(shù)據(jù)庫絕對不會死，限流組件確保了每秒只有多少個請求能通過。 只要數(shù)據(jù)庫不死，就是說，對用戶來說，3/5 的請求都是可以被處理的。 只要有 3/5 的請求可以被處理，就意味著你的系統(tǒng)沒死，對用戶來說，可能就是點擊幾次刷不出來頁面，但是多點幾次，就可以刷出來一次。

這個在目前主流的互聯(lián)網(wǎng)大廠里面是最常見的，你是不是好奇，某明星爆出什么事情，你發(fā)現(xiàn)你去微博怎么刷都空白界面，但是有的人又直接進了，你多刷幾次也出來了，現(xiàn)在知道了吧，那是做了降級，犧牲部分用戶的體驗換來服務(wù)器的安全，可還行？

到此，關(guān)于“如何理解Redis的使用和原理”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>