建站
咨詢
售后
建站咨詢
新聞中心
為什么使用緩存
在高并發(fā)請(qǐng)求時(shí)，我們會(huì)頻繁提到使用緩存技術(shù)，最直接的原因是，磁盤IO及網(wǎng)絡(luò)開銷是直接請(qǐng)求內(nèi)存IO的千百上千倍
成都地區(qū)優(yōu)秀IDC服務(wù)器托管提供商(創(chuàng)新互聯(lián)).為客戶提供專業(yè)的川西大數(shù)據(jù)中心,四川各地服務(wù)器托管,川西大數(shù)據(jù)中心、多線服務(wù)器托管.托管咨詢專線：028-86922220
做個(gè)簡(jiǎn)單計(jì)算，如果我們需要某個(gè)數(shù)據(jù)，該數(shù)據(jù)從數(shù)據(jù)庫(kù)磁盤讀出來需要0.0045S，經(jīng)過網(wǎng)絡(luò)請(qǐng)求傳輸需要0.0005S，那么每個(gè)請(qǐng)求完成最少需要0.005S，該數(shù)據(jù)服務(wù)器每秒最多只能響應(yīng)200個(gè)請(qǐng)求，而如果該數(shù)據(jù)存于本機(jī)內(nèi)存里，讀出來只需要100us，那么每秒能夠響應(yīng)10000個(gè)請(qǐng)求。通過將數(shù)據(jù)存儲(chǔ)到離CPU更近的未位置，減少數(shù)據(jù)傳輸時(shí)間，提高處理效率，這就是緩存的意義。
什么場(chǎng)景下適合使用緩存
-
讀密集型的應(yīng)用
-
存在熱數(shù)據(jù)的應(yīng)用
-
對(duì)響應(yīng)時(shí)效要求高的應(yīng)用
-
對(duì)一致性要求不嚴(yán)格的場(chǎng)景
-
需要實(shí)現(xiàn)分布式鎖的時(shí)候
什么場(chǎng)景下不適合使用緩存
-
對(duì)一致性要求嚴(yán)格的場(chǎng)景
-
更新頻繁，更新數(shù)據(jù)頻率過高的場(chǎng)景，頻繁同步緩存中的數(shù)據(jù)所花費(fèi)的代價(jià)可能比不使用緩存的代價(jià)還要高
-
讀少的場(chǎng)景，對(duì)于讀少的系統(tǒng)而言，使用緩存就完全沒有意義了，比較使用緩存是為了讀取數(shù)據(jù)更高效
緩存收益成本對(duì)比
收益
-
加速讀寫。因?yàn)榫彺嫱ǔ６际侨珒?nèi)存的系統(tǒng)，通過緩存的使用可以有效提高用戶的訪問速度同時(shí)優(yōu)化用戶體驗(yàn)。
-
降低后端負(fù)載。通過添加緩存，如果程序沒有什么問題，在命中率還可以的情況下，可以幫助后端減少訪問量和復(fù)雜計(jì)算，很大程度降低了后端的負(fù)載。
成本
-
數(shù)據(jù)不一致性。無論設(shè)計(jì)做的多么好，緩存數(shù)據(jù)與真實(shí)數(shù)據(jù)源一定存在著一定時(shí)間窗口的數(shù)據(jù)不一致性
-
代碼維護(hù)成本。有緩存后，代碼就會(huì)在原數(shù)據(jù)源基礎(chǔ)上加入緩存的相關(guān)代碼，例如原來只是一些sql，現(xiàn)在要加入緩存，必然增加代碼維護(hù)成本。
-
架構(gòu)復(fù)雜度。有緩存后，需要專門的管理人員來維護(hù)主從緩存系統(tǒng)，同時(shí)也增加了架構(gòu)的復(fù)雜度和維護(hù)成本。
高并發(fā)場(chǎng)景下帶來的常見問題
在高并發(fā)場(chǎng)景下，緩存主要會(huì)帶來下面幾個(gè)問題:
1.緩存一致性
2.緩存并發(fā)（緩存擊穿）
3.緩存穿透
4.緩存雪崩（緩存失效）
打個(gè)比方，你是個(gè)很有錢的人，開滿了百度云，騰訊視頻各種雜七雜八的會(huì)員，但是你就是沒有netflix的會(huì)員，然后你把這些賬號(hào)和密碼發(fā)布到一個(gè)你自己做的網(wǎng)站上，然后你有一個(gè)朋友每過十秒鐘就查詢你的網(wǎng)站，發(fā)現(xiàn)你的網(wǎng)站沒有Netflix的會(huì)員后打電話向你要。你就相當(dāng)于是個(gè)數(shù)據(jù)庫(kù)，網(wǎng)站就是Redis。這就是緩存穿透。
大家都喜歡看騰訊視頻上 周星馳的《喜劇之王》 ，但是你的會(huì)員突然到期了，大家在你的網(wǎng)站上看不到騰訊視頻的賬號(hào)，紛紛打電話向你詢問，這就是緩存擊穿
你的各種會(huì)員突然同一時(shí)間都失效了，那這就是緩存雪崩了。
下面一一介紹！
緩存一致性問題
當(dāng)數(shù)據(jù)時(shí)效性要求很高時(shí)，需要保證緩存中的數(shù)據(jù)與數(shù)據(jù)庫(kù)中的保持一致，而且需要保證緩存節(jié)點(diǎn)和副本中的數(shù)據(jù)也保持一致，不能出現(xiàn)差異現(xiàn)象。這就比較依賴緩存的過期和更新策略。一般會(huì)在數(shù)據(jù)發(fā)生更改的時(shí)，主動(dòng)更新緩存中的數(shù)據(jù)或者移除對(duì)應(yīng)的緩存。
下圖情況都會(huì)導(dǎo)致數(shù)據(jù)一致性問題
緩存擊穿問題
對(duì)于一些設(shè)置了過期時(shí)間的key，可能這些key會(huì)在某些時(shí)間點(diǎn)被超高并發(fā)地訪問，是一種非?！盁狳c(diǎn)”的數(shù)據(jù)。這個(gè)時(shí)候，需要考慮緩存被“擊穿”的問題，和緩存雪崩的區(qū)別在于這里針對(duì)某一key緩存，而緩存雪崩則是很多key。
如圖所示：
解決方案:
業(yè)界比較常用的做法，是使用mutex（互斥鎖）。
1.使用互斥鎖(mutex key)
該方案思路比較簡(jiǎn)單，就是只讓一個(gè)線程構(gòu)建緩存，其他線程等待構(gòu)建緩存的線程執(zhí)行完，重新從緩存獲取數(shù)據(jù)就可以
如果是單機(jī)可以用synchronized或者lock來處理，如果是分布式環(huán)境可以用分布式鎖（redis的setnx, zookeeper的添加節(jié)點(diǎn)操作）
redis偽代碼如下:
- public String get(String key) {
- String value = storeClient.get(key);
- StoreKey key_mutex = new MutexStoreKey(key);
- if (value == null) {//代表緩存值過期
- //設(shè)置2min的超時(shí)，防止刪除緩存操作失敗的時(shí)候，下次緩存過期一直不能獲取DB數(shù)據(jù)
- if (storeClient.setnx(key_mutex, 1, 2 * 60)) { //代表設(shè)置成功
- value = db.get(key);
- storeClient.set(key, value, 3 * 3600);
- storeClient.delete(key_mutex);
- } else {
- sleep(1000); //這個(gè)時(shí)候代表同時(shí)候的其他線程已經(jīng)獲取DB數(shù)據(jù)并回設(shè)到緩存了，這時(shí)候重試獲取緩存值即可
- return get(key); //重試
- }
- }
- return value;
- }
2.“提前”使用互斥鎖(mutex key)
即在value內(nèi)部設(shè)置1個(gè)超時(shí)值(timeout1)，timeout1比實(shí)際的redis timeout(timeout2)小。
當(dāng)從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過期時(shí)候，馬上延長(zhǎng)timeout1并重新設(shè)置到cache。然后再?gòu)臄?shù)據(jù)庫(kù)加載數(shù)據(jù)并設(shè)置到cache中。
方案2和方案1的區(qū)別在于，如果緩存有數(shù)據(jù)，但是已經(jīng)過期，會(huì)提前使用互斥鎖，查詢DB最新數(shù)據(jù)再緩存起來
偽代碼如下，注意代碼else里面的邏輯。
- public String get(String key) {
- MutexDTO value = storeClient.get(key);
- StoreKey key_mutex = new MutexStoreKey(key);
- if (value == null) {
- if (storeClient.setnx(key_mutex, 3 * 60 * 1000)) {
- value = db.get(key);
- storeClient.set(key, value);
- storeClient.delete(key_mutex);
- } else {
- sleep(50);
- get(key);
- }
- } else {
- if (value.getTimeout() <= System.currentTimeMillis()) {
- if (storeClient.setnx(key_mutex, 3 * 60 * 1000)) {
- value.setTimeout(value.getTimeout() + 3 * 60 * 1000);
- storeClient.set(key, value, 3 * 3600 * 2);
- value = db.get(key);//獲取最近DB更新數(shù)據(jù)
- value.setTimeout(value.getTimeout() + 3 * 60 * 1000);
- storeClient.set(key, value, 3 * 3600 * 2);
- storeClient.delete(key_mutex);
- } else {
- sleep(50);
- get(key);
- }
- }
- }
- return value.getValue();
- }
3.緩存”永不過期“
這里的“永遠(yuǎn)不過期”包含兩層意思:
-
從redis上看，不設(shè)置過期時(shí)間，這就保證了，不會(huì)出現(xiàn)熱點(diǎn)key過期問題，也就是“物理”不過期。
-
從功能上看，如果不過期，那不就成靜態(tài)的了嗎？所以我們把過期時(shí)間存在key對(duì)應(yīng)的value里，如果發(fā)現(xiàn)要過期了，通過一個(gè)后臺(tái)的異步線程進(jìn)行緩存的構(gòu)建，也就是“邏輯”過期。
- public String get(String key) {
- MutexDTO mutexDTO = storeClient.get(key);
- String value = mutexDTO.getValue();
- if (mutexDTO.getTimeout() <= System.currentTimeMillis()) {
- ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();// 異步更新后臺(tái)異常執(zhí)行
- singleThreadExecutor.execute(new Runnable() {
- public void run() {
- StoreKey mutexKey = new MutexStoreKey(key);
- if (storeClient.setnx(mutexKey, "1")) {
- storeClient.expire(mutexKey, 3 * 60);
- String dbValue = db.get(key);
- storeClient.set(key, dbValue);
- storeClient.delete(mutexKey);
- }
- }
- });
- }
- return value;
- }
三種方法如下比較：
| 解決方案 | 優(yōu)點(diǎn) | 缺點(diǎn) |
|---|---|---|
| 使用互斥鎖 | 1.思路簡(jiǎn)單2.保證一致性 | 1. 代碼復(fù)雜度增大2. 存在死鎖的風(fēng)險(xiǎn) |
| 提前使用互斥鎖 | 1. 保證一致性 | 同上 |
| 緩存永不過期 | 1. 異步構(gòu)建緩存，不會(huì)阻塞線程池 | 1. 不保證一致性。2. 代碼復(fù)雜度增大(每個(gè)value都要維護(hù)一個(gè)timekey)。3. 占用一定的內(nèi)存空間(每個(gè)value都要維護(hù)一個(gè)timekey)。 |
緩存穿透問題
緩存穿透是指查詢一個(gè)一定不存在的數(shù)據(jù)，由于緩存是不命中時(shí)被動(dòng)寫的，并且出于容錯(cuò)考慮，如果從存儲(chǔ)層查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到存儲(chǔ)層去查詢，失去了緩存的意義。
在流量大時(shí)，要是DB無法承受瞬間流量沖擊，DB可能就掛了。
如圖所示：
解決方案：
有多種方法可以有效解決緩存穿透問題，一種比較簡(jiǎn)單粗暴的方法采用緩存空數(shù)據(jù)，如果一個(gè)查詢返回的數(shù)據(jù)為空（數(shù)據(jù)庫(kù)中不存在該數(shù)據(jù)），仍然把這個(gè)空結(jié)果進(jìn)行緩存（過期時(shí)間一般較短）。
另一種方法則是采用常用的布隆過濾器，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠大的bitmap中，一個(gè)一定不存在的數(shù)據(jù)會(huì)被這個(gè)bitmap攔截掉，從而避免了對(duì)底層存儲(chǔ)系統(tǒng)的查詢壓力。
1.緩存空數(shù)據(jù)
當(dāng)Client請(qǐng)求MISS后，仍然將空對(duì)象保留到Cache中（可能是保留一段時(shí)間，具體問題具體分析），下次新的Request（同一個(gè)key）將會(huì)從Cache中獲取到數(shù)據(jù)，保護(hù)了后端的DB。偽代碼如下：
- public class CacheNullService {
- private Cache cache = new Cache();
- private Storage storage = new Storage();
- /**
- * 模擬正常模式
- * @param key
- * @return
- */
- public String getNormal(String key) {
- // 從緩存中獲取數(shù)據(jù)
- String cacheValue = cache.get(key);
- // 緩存為空
- if (StringUtils.isBlank(cacheValue)) {
- // 從存儲(chǔ)中獲取
- String storageValue = storage.get(key);
- // 如果存儲(chǔ)數(shù)據(jù)不為空,將存儲(chǔ)的值設(shè)置到緩存
- if (StringUtils.isNotBlank(storageValue)) {
- cache.set(key, storageValue);
- }
- return storageValue;
- } else {
- // 緩存非空
- return cacheValue;
- }
- }
- /**
- * 模擬防穿透模式
- * @param key
- * @return
- */
- public String getPassThrough(String key) {
- // 從緩存中獲取數(shù)據(jù)
- String cacheValue = cache.get(key);
- // 緩存為空
- if (StringUtils.isBlank(cacheValue)) {
- // 從存儲(chǔ)中獲取
- String storageValue = storage.get(key);
- cache.set(key, storageValue);
- // 如果存儲(chǔ)數(shù)據(jù)為空，需要設(shè)置一個(gè)過期時(shí)間(300秒)
- if (StringUtils.isBlank(storageValue)) {
- cache.expire(key, 60 * 5);
- }
- return storageValue;
- } else {
- // 緩存非空
- return cacheValue;
- }
- }
- }
2.布隆過濾器
BloomFilter 是一個(gè)非常有意思的數(shù)據(jù)結(jié)構(gòu)，不僅僅可以擋住非法 key 攻擊，還可以低成本、高性能地對(duì)海量數(shù)據(jù)進(jìn)行判斷，比如一個(gè)系統(tǒng)有數(shù)億用戶和百億級(jí)新聞 feed，就可以用 BloomFilter 來判斷某個(gè)用戶是否閱讀某條新聞 feed
在訪問所有資源(cache, DB)之前，將存在的key用布隆過濾器提前保存起來，做第一層攔截。算法的簡(jiǎn)單圖解如下:
用布隆過濾器實(shí)際只需要判斷客戶端傳過來的userCode是否存在就可以，圖中的hash1,hash2,hash3分別代表三種hash算法，不同的userCode對(duì)應(yīng)著不同的數(shù)據(jù)位，當(dāng)需要校驗(yàn)的時(shí)候，判斷每一種算法的得出來的byte位是否相同，只要一位不同，那么我們可以認(rèn)為這個(gè)userCode不存在。
一般BloomFilter 要緩存全量的 key，這就要求全量的 key 數(shù)量不大，10 億條數(shù)據(jù)以內(nèi)最佳，因?yàn)?10 億條數(shù)據(jù)大概要占用 1.2 GB 的內(nèi)存。也可以用 BloomFilter 緩存非法 key，每次發(fā)現(xiàn)一個(gè) key 是不存在的非法 key，就記錄到 BloomFilter 中，這種記錄方案，會(huì)導(dǎo)致 BloomFilter 存儲(chǔ)的 key 持續(xù)高速增長(zhǎng)，為了避免記錄 key 太多而導(dǎo)致誤判率增大，需要定期清零處理
布隆使用案例如下:
- import com.google.common.base.Charsets;
- import com.google.common.hash.BloomFilter;
- import com.google.common.hash.Funnels;
- import java.util.*;
- public class BFDemo {
- private static final int insertions = 1000000;//100W
- public static void main(String[] args) {
- BloomFilter bf = BloomFilter.create(Funnels.stringFunnel(Charsets.UTF_8), insertions);
- Set sets = new HashSet(insertions);
- List
lists = new ArrayList(insertions); - for (int i = 0; i < insertions; i++) {
- String uuid = UUID.randomUUID().toString();
- bf.put(uuid);
- sets.add(uuid);
- lists.add(uuid);
- }
- int wrong = 0;
- int right = 0;
- for (int i = 0; i < 10000; i++) {
- String test = i % 100 == 0 ? lists.get(i / 100) : UUID.randomUUID().toString(); //隨機(jī)生成1W字符串
- if (bf.mightContain(test)) {
- if (sets.contains(test)) {
- right++;
- } else {
- wrong++;
- }
- }
- }
- System.out.println("========right=======" + right);
- System.out.println("========wrong=======" + wrong);
- }
- }
上文中提到的兩種方法，比較：
| 解決方案 | 適用場(chǎng)景 | 優(yōu)缺點(diǎn) |
|---|---|---|
| 緩存空數(shù)據(jù) | 1. 數(shù)據(jù)命中不高2. 數(shù)據(jù)頻繁變化實(shí)時(shí)性高 | 1.維護(hù)簡(jiǎn)單2.需要更多的緩存空間3.可能數(shù)據(jù)不一致 |
| 布隆過濾器 | 1. 數(shù)據(jù)命中不高2. 數(shù)據(jù)相對(duì)固定實(shí)時(shí)性低 | 1.代碼維護(hù)復(fù)雜2.緩存空間占用少 |
緩存雪崩問題
緩存雪崩一般是由兩個(gè)原因?qū)е碌?/h4>
第一個(gè)原因是：緩存中有大量數(shù)據(jù)同時(shí)過期，導(dǎo)致大量請(qǐng)求無法得到處理。
如圖所示：
解決方案：
設(shè)計(jì)不同的過期時(shí)間
我們可以避免給大量的數(shù)據(jù)設(shè)置相同的過期時(shí)間。如果業(yè)務(wù)層的確要求有些數(shù)據(jù)同時(shí)失效，你可以在用EXPIRE命令給每個(gè)數(shù)據(jù)設(shè)置過期時(shí)間時(shí)，給這些數(shù)據(jù)的過期時(shí)間增加一個(gè)較小的隨機(jī)數(shù)（例如，隨機(jī)增加1~3分鐘），這樣一來，不同數(shù)據(jù)的過期時(shí)間有所差別，但差別又不會(huì)太大，既避免了大量數(shù)據(jù)同時(shí)過期，同時(shí)也保證了這些數(shù)據(jù)基本在相近的時(shí)間失效，仍然能滿足業(yè)務(wù)需求
服務(wù)降級(jí)處理
發(fā)生緩存雪崩時(shí)，針對(duì)不同的數(shù)據(jù)采取不同的處理方式。
-
當(dāng)業(yè)務(wù)應(yīng)用訪問的是非核心數(shù)據(jù)時(shí)，暫時(shí)停止從緩存中查詢這些數(shù)據(jù)，而是直接返回預(yù)定義信息、空值或是錯(cuò)誤信息；
-
當(dāng)業(yè)務(wù)應(yīng)用訪問的是核心數(shù)據(jù)時(shí)，仍然允許查詢緩存，如果緩存缺失，也可以繼續(xù)通過數(shù)據(jù)庫(kù)讀取。
對(duì)緩存增加多個(gè)副本
緩存異常或請(qǐng)求 miss 后，再讀取其他緩存副本，而且多個(gè)緩存副本盡量部署在不同機(jī)架，從而確保在任何情況下，緩存系統(tǒng)都會(huì)正常對(duì)外提供服務(wù)
對(duì)緩存體系進(jìn)行實(shí)時(shí)監(jiān)控
當(dāng)請(qǐng)求訪問的慢速比超過閥值時(shí)，及時(shí)報(bào)警，通過機(jī)器替換、服務(wù)替換進(jìn)行及時(shí)恢復(fù)；也可以通過各種自動(dòng)故障轉(zhuǎn)移策略，自動(dòng)關(guān)閉異常接口、停止邊緣服務(wù)、停止部分非核心功能措施，確保在極端場(chǎng)景下，核心功能的正常運(yùn)行。
第二個(gè)原因是：
如果Cache層由于某些原因(宕機(jī)、cache服務(wù)掛了或者不響應(yīng)了)整體crash掉了，也就意味著所有的請(qǐng)求都會(huì)達(dá)到DB層，所有DB調(diào)用量會(huì)暴增，所以它有點(diǎn)扛不住了，甚至也會(huì)掛掉。
如圖所示：
雪崩過后緩存已經(jīng)crash，解決方案無非是讓DB能承受更大數(shù)據(jù)壓力，我們可以DB擴(kuò)容解決，但不是長(zhǎng)久之計(jì)，最好解決辦法是如何預(yù)防緩存雪崩。
如何預(yù)防我們可以從以下方面入手:
保證Cache服務(wù)高可用性。
如果我們的cache也是高可用的，即使個(gè)別實(shí)例掛掉了，影響不會(huì)很大（主從切換或者可能會(huì)有部分流量到了后端），實(shí)現(xiàn)自動(dòng)化運(yùn)維。
例如:memcache的一致性hash、redis的sentinel和cluster機(jī)制
依賴隔離組件為后端限流。
其實(shí)無論是cache或者是mysql、hbase、甚至別人的RPC都會(huì)出現(xiàn)問題，我們可以將這些視同為資源，作為并發(fā)量較大的系統(tǒng)，假如有一個(gè)資源不可訪問了，即使設(shè)置了超時(shí)時(shí)間，依然會(huì)hold住所有線程，造成其他資源和接口也不可以訪問。
提前演練預(yù)估。
在項(xiàng)目上線前，通過演練，觀察cache crash后，整體系統(tǒng)和DB的負(fù)載，提前做好預(yù)案。
新聞標(biāo)題：緩存的一些常見的坑，你遇到過哪些，怎么解決的？
網(wǎng)站鏈接：http://www.dlmjj.cn/article/djopdpc.html
