億級系統(tǒng)的Redis緩存怎么設(shè)計

這篇文章主要介紹億級系統(tǒng)的Redis緩存怎么設(shè)計，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

首先，先了解緩存知識圖譜

早期的緩存用于加速CPU數(shù)據(jù)交換的RAM。隨著互聯(lián)網(wǎng)的快速發(fā)展，緩存的應(yīng)用更加寬泛，用于數(shù)據(jù)高速交換的存儲介質(zhì)都稱之為緩存。

使用緩存時，我們要關(guān)注哪些指標(biāo)？緩存有哪些應(yīng)用模式？以及緩存設(shè)計時有哪些Tip技巧？一圖勝千言，如下：

七大經(jīng)典問題

緩存在使用過程不可避免會遇到一些問題，對于高頻的問題我們大概歸為了7類。具體內(nèi)容下面我們一一道來

1、緩存集中失效

當(dāng)業(yè)務(wù)系統(tǒng)查詢數(shù)據(jù)時，首先會查詢緩存，如果緩存中數(shù)據(jù)不存在，然后查詢DB再將數(shù)據(jù)預(yù)熱到Cache中，并返回。緩存的性能比 DB 高 50~100 倍以上。

很多業(yè)務(wù)場景，如：秒殺商品、微博熱搜排行、或者一些活動數(shù)據(jù)，都是通過跑任務(wù)方式，將DB數(shù)據(jù)批量、集中預(yù)熱到緩存中，緩存數(shù)據(jù)有著近乎相同的過期時間。

當(dāng)過這批數(shù)據(jù)過期時，會一起過期，此時，對這批數(shù)據(jù)的所有請求，都會出現(xiàn)緩存失效，從而將壓力轉(zhuǎn)嫁到DB，DB的請求量激增，壓力變大，響應(yīng)開始變慢。

那么有沒有解呢？

當(dāng)然有了。

我們可以從緩存的過期時間入口，將原來的固定過期時間，調(diào)整為過期時間=基礎(chǔ)時間+隨機(jī)時間，讓緩存慢慢過期，避免瞬間全部過期，對DB產(chǎn)生過大壓力。

2、緩存穿透

不是所有的請求都能查到數(shù)據(jù)，不論是從緩存中還是DB中。

假如黑客攻擊了一個論壇，用了一堆肉雞訪問一個不存的帖子id。按照常規(guī)思路，每次都會先查緩存，緩存中沒有，接著又查DB，同樣也沒有，此時不會預(yù)熱到Cache中，導(dǎo)致每次查詢，都會cache miss。

由于DB的吞吐性能較差，會嚴(yán)重影響系統(tǒng)的性能，甚至影響正常用戶的訪問。

解決方案：

• 方案一：查存DB 時，如果數(shù)據(jù)不存在，預(yù)熱一個特殊空值到緩存中。這樣，后續(xù)查詢都會命中緩存，但是要對特殊值，解析處理。

• 方案二：構(gòu)造一個BloomFilter過濾器，初始化全量數(shù)據(jù)，當(dāng)接到請求時，在BloomFilter中判斷這個key是否存在，如果不存在，直接返回即可，無需再查詢緩存和DB

3、緩存雪崩

緩存雪崩是指部分緩存節(jié)點不可用，進(jìn)而導(dǎo)致整個緩存體系甚至服務(wù)系統(tǒng)不可用的情況。

分布式緩存設(shè)計一般選擇一致性Hash，當(dāng)有部分節(jié)點異常時，采用 rehash 策略，即把異常節(jié)點請求平均分散到其他緩存節(jié)點。但是，當(dāng)較大的流量洪峰到來時，如果大流量 key 比較集中，正好在某 1～2 個緩存節(jié)點，很容易將這些緩存節(jié)點的內(nèi)存、網(wǎng)卡過載，緩存節(jié)點異常 Crash，然后這些異常節(jié)點下線，這些大流量 key 請求又被 rehash 到其他緩存節(jié)點，進(jìn)而導(dǎo)致其他緩存節(jié)點也被過載 Crash，緩存異常持續(xù)擴(kuò)散，最終導(dǎo)致整個緩存體系異常，無法對外提供服務(wù)。

解決方案：

• 方案一：增加實時監(jiān)控，及時預(yù)警。通過機(jī)器替換、各種故障自動轉(zhuǎn)移策略，快速恢復(fù)緩存對外的服務(wù)能力

• 方案二：緩存增加多個副本，當(dāng)緩存異常時，再讀取其他緩存副本。為了保證副本的可用性，盡量將多個緩存副本部署在不同機(jī)架上，降低風(fēng)險。

4、緩存熱點

對于突發(fā)事件，大量用戶同時去訪問熱點信息，這個突發(fā)熱點信息所在的緩存節(jié)點就很容易出現(xiàn)過載和卡頓現(xiàn)象，甚至 Crash，我們稱之為緩存熱點。

這個在新浪微博經(jīng)常遇到，某大V明星出軌、結(jié)婚、離婚，瞬間引發(fā)數(shù)百千萬的吃瓜群眾圍觀，訪問同一個key，流量集中打在一個緩存節(jié)點機(jī)器，很容易打爆網(wǎng)卡、帶寬、CPU的上限，最終導(dǎo)致緩存不可用。

解決方案：

• 首先能先找到這個熱key來，比如通過Spark實時流分析，及時發(fā)現(xiàn)新的熱點key。

• 將集中化流量打散，避免一個緩存節(jié)點過載。由于只有一個key，我們可以在key的后面拼上有序編號，比如key#01、key#02。。。key#10多個副本，這些加工后的key位于多個緩存節(jié)點上。

• 每次請求時，客戶端隨機(jī)訪問一個即可

可以設(shè)計一個緩存服務(wù)治理管理后臺，實時監(jiān)控緩存的SLA，并打通分布式配置中心，對于一些hot key可以快速、動態(tài)擴(kuò)容。

5、緩存大Key

當(dāng)訪問緩存時，如果key對應(yīng)的value過大，讀寫、加載很容易超時，容易引發(fā)網(wǎng)絡(luò)擁堵。另外緩存的字段較多時，每個字段的變更都會引發(fā)緩存數(shù)據(jù)的變更，頻繁的讀寫，導(dǎo)致慢查詢。如果大key過期被緩存淘汰失效，預(yù)熱數(shù)據(jù)要花費較多的時間，也會導(dǎo)致慢查詢。

所以我們在設(shè)計緩存的時候，要注意緩存的粒度，既不能過大，如果過大很容易導(dǎo)致網(wǎng)絡(luò)擁堵；也不能過小，如果太小，查詢頻率會很高，每次請求都要查詢多次。

解決方案：

• 方案一：設(shè)置一個閾值，當(dāng)value的長度超過閾值時，對內(nèi)容啟動壓縮，降低kv的大小

• 方案二：評估大key所占的比例，由于很多框架采用池化技術(shù)，如：Memcache，可以預(yù)先分配大對象空間。真正業(yè)務(wù)請求時，直接拿來即用。

• 方案三：顆粒劃分，將大key拆分為多個小key，獨立維護(hù)，成本會降低不少

• 方案四：大key要設(shè)置合理的過期時間，盡量不淘汰那些大key

6、緩存數(shù)據(jù)一致性

緩存是用來加速的，一般不會持久化儲存。所以，一份數(shù)據(jù)通常會存在DB和緩存中，由此會帶來一個問題，如何保證這兩者的數(shù)據(jù)一致性。另外，緩存熱點問題會引入多個副本備份，也可能會發(fā)生不一致現(xiàn)象。

解決方案：

• 方案一：當(dāng)緩存更新失敗后，進(jìn)行重試，如果重試失敗，將失敗的key寫入MQ消息隊列，通過異步任務(wù)補償緩存，保證數(shù)據(jù)的一致性。

• 方案二：設(shè)置一個較短的過期時間，通過自修復(fù)的方式，在緩存過期后，緩存重新加載最新的數(shù)據(jù)

7、數(shù)據(jù)并發(fā)競爭預(yù)熱

互聯(lián)網(wǎng)系統(tǒng)典型的特點就是流量大，一旦緩存中的數(shù)據(jù)過期、或因某些原因被刪除等，導(dǎo)致緩存中的數(shù)據(jù)為空，大量的并發(fā)線程請求（查詢同一個key）就會一起并發(fā)查詢數(shù)據(jù)庫，數(shù)據(jù)庫的壓力陡然增加。

如果請求量非常大，全部壓在數(shù)據(jù)庫，可能把數(shù)據(jù)庫壓垮，進(jìn)而導(dǎo)致整個系統(tǒng)的服務(wù)不可用。

解決方案：

• 方案一：引入一把全局鎖，當(dāng)緩存未命中時，先嘗試獲取全局鎖，如果拿到鎖，才有資格去查詢DB，并將數(shù)據(jù)預(yù)熱到緩存中。雖然，client端發(fā)起的請求非常多，但是由于拿不到鎖，只能處于等待狀態(tài)，當(dāng)緩存中的數(shù)據(jù)預(yù)熱成功后，再從緩存中獲取

為了便于理解，簡單畫了個流程圖。這里面特別注意一個點，由于有一個并發(fā)時間差，所以會有一個二次check緩存是否有值的校驗，防止緩存預(yù)熱重復(fù)覆蓋。

• 方案二：緩存數(shù)據(jù)創(chuàng)建多個備份，當(dāng)一個過期失效后，可以訪問其他備份。

緩存設(shè)計時，有很多技巧，優(yōu)化手段也是千變?nèi)f化，但是我們要抓住核心要素。那就是，讓訪問盡量命中緩存，同時保持?jǐn)?shù)據(jù)的一致性。

粉絲提問，分割線-----------

4年Java開發(fā)經(jīng)驗，面試經(jīng)常被問到高并發(fā)、性能調(diào)優(yōu)方面的問題，該怎么辦？

無論是618、雙十一以及雙十二都是離不開高并發(fā)的。  當(dāng)然不同量級的系統(tǒng)也會有不同的問題，畢竟誰都不是淘寶，對吧，同樣的，針對不同的需求以及業(yè)務(wù)場景，也就會有對架構(gòu)設(shè)計的不同需求。同樣的，  高并發(fā)系統(tǒng)的演進(jìn)也不是一步到位的，它是循序漸進(jìn)，不斷改進(jìn)的，像幾年前，雙十一卡崩，無法付款無法選擇地址的事情每年都會發(fā)生，但是今年的情況是不是好一些呢？就是在這些不斷地改進(jìn)過程中，以解決系統(tǒng)中存在的問題為目的和驅(qū)動力的系統(tǒng)設(shè)計得以進(jìn)行，而阿里，正是在這方面的最佳實踐者。  有人可能會說，他們有服務(wù)器?。ㄒ话涯愠绦蚍旁谒麄兎?wù)器上抵抗億級并發(fā)的沖擊試試？）

阿里作為國內(nèi)互聯(lián)網(wǎng)行業(yè)的老大哥，也正是考慮到這一點，不是所有人都能投入那么多的資金，所以對于系統(tǒng)優(yōu)化部分，也是不遺余力  。經(jīng)過多年的歷練，阿里也慢慢總結(jié)形成一套他們內(nèi)部的開發(fā)筆記——《阿里P9純手打億級高并發(fā)系統(tǒng)設(shè)計手冊》

這份筆記分為基礎(chǔ)篇、數(shù)據(jù)庫篇、緩存篇、消息隊列篇、分布式服務(wù)篇、維護(hù)篇、實戰(zhàn)篇，下面小編就以截圖的方式帶大家看看， 如果有需要完整版本的朋友們，可以  點擊此處   憑截圖免費獲取

基礎(chǔ)篇

• 如何讓系統(tǒng)易于擴(kuò)展

數(shù)據(jù)庫篇

• 在高并發(fā)場景下，數(shù)據(jù)庫和NoSQL如何做到互補

緩存篇

• 緩存穿透了怎么辦

消息隊列篇

• 如何降低消息隊列系統(tǒng)中的消息延遲

分布式服務(wù)篇

分布式系統(tǒng)如何尋址

維護(hù)篇

• 如何屏蔽非核心系統(tǒng)故障操縱流量

實戰(zhàn)篇

• 50萬QPS下如何設(shè)計未讀數(shù)系統(tǒng)

最后

在這個電商的時代，如何運用自如的使用高并發(fā)秒殺系統(tǒng)，提升秒殺的性能，只有系統(tǒng)穩(wěn)定了，無論是低峰、高峰的流量都是可以控制住的。

以上是“億級系統(tǒng)的Redis緩存怎么設(shè)計”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！