這篇文章主要介紹“如何理解redis的使用和原理”，在日常操作中，相信很多人在如何理解Redis的使用和原理問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”如何理解Redis的使用和原理”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

成都創(chuàng)新互聯(lián)公司主營(yíng)鹽湖網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,app軟件開發(fā),鹽湖h5小程序開發(fā)搭建,鹽湖網(wǎng)站營(yíng)銷推廣歡迎鹽湖等地區(qū)企業(yè)咨詢

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

我刻意看了下我做過(guò)的項(xiàng)目感覺(jué)再吊的都不允許這么大的QPS直接打DB去，不過(guò)沒(méi)慢SQL加上分庫(kù)，大表分表可能還還算能頂，但是跟用了Redis的差距還是很大

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

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

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

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

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

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

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

嗯，了解，我先說(shuō)一下緩存穿透吧，緩存穿透是指緩存和數(shù)據(jù)庫(kù)中都沒(méi)有的數(shù)據(jù)，而用戶不斷發(fā)起請(qǐng)求，我們數(shù)據(jù)庫(kù)的 id 都是1開始自增上去的，如發(fā)起為id值為 -1 的數(shù)據(jù)或 id 為特別大不存在的數(shù)據(jù)。這時(shí)的用戶很可能是攻擊者，攻擊會(huì)導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大，嚴(yán)重會(huì)擊垮數(shù)據(jù)庫(kù)。

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

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

至于緩存擊穿嘛，這個(gè)跟緩存雪崩有點(diǎn)像，但是又有一點(diǎn)不一樣，緩存雪崩是因?yàn)榇竺娣e的緩存失效，打崩了DB，而緩存擊穿不同的是緩存擊穿是指一個(gè)Key非常熱點(diǎn)，在不停的扛著大并發(fā)，大并發(fā)集中對(duì)這一個(gè)點(diǎn)進(jìn)行訪問(wèn)，當(dāng)這個(gè)Key在失效的瞬間，持續(xù)的大并發(fā)就穿破緩存，直接請(qǐng)求數(shù)據(jù)庫(kù)，就像在一個(gè)完好無(wú)損的桶上鑿開了一個(gè)洞。

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

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

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

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

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

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

好處：

數(shù)據(jù)庫(kù)絕對(duì)不會(huì)死，限流組件確保了每秒只有多少個(gè)請(qǐng)求能通過(guò)。 只要數(shù)據(jù)庫(kù)不死，就是說(shuō)，對(duì)用戶來(lái)說(shuō)，3/5 的請(qǐng)求都是可以被處理的。 只要有 3/5 的請(qǐng)求可以被處理，就意味著你的系統(tǒng)沒(méi)死，對(duì)用戶來(lái)說(shuō)，可能就是點(diǎn)擊幾次刷不出來(lái)頁(yè)面，但是多點(diǎn)幾次，就可以刷出來(lái)一次。

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

到此，關(guān)于“如何理解Redis的使用和原理”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

網(wǎng)頁(yè)標(biāo)題：如何理解Redis的使用和原理
URL分享：http://sd-ha.com/article0/gdegoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、域名注冊(cè)、微信小程序、網(wǎng)站排名、Google、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)