高并發(fā)系統(tǒng)三大利器之緩存
引言
隨著互聯(lián)網(wǎng)的高速發(fā)展，市面上也出現(xiàn)了越來越多的網(wǎng)站和app。我們判斷一個(gè)軟件是否好用，用戶體驗(yàn)就是一個(gè)重要的衡量標(biāo)準(zhǔn)。比如說我們經(jīng)常用的微信，打開一個(gè)頁面要十幾秒，發(fā)個(gè)語音要幾分鐘對方才能收到。相信這樣的軟件大家肯定是都不愿意用的。
軟件要做到用戶體驗(yàn)好，響應(yīng)速度快，緩存就是必不可少的一個(gè)神器。緩存又分進(jìn)程內(nèi)緩存和分布式緩存兩種：分布式緩存如redis、memcached等，還有本地（進(jìn)程內(nèi)）緩存如ehcache、GuavaCache、Caffeine等。
?
緩存特征
緩存作為一個(gè)數(shù)據(jù)數(shù)據(jù)模型對象，那么它有一些什么樣的特征呢？下面我們分別來介紹下這些特征。
命中率
命中率=命中數(shù)/（命中數(shù)+沒有命中數(shù)）當(dāng)某個(gè)請求能夠通過訪問緩存而得到響應(yīng)時(shí)，稱為緩存命中。緩存命中率越高，緩存的利用率也就越高。
最大空間
緩存中可以容納最大元素的數(shù)量。當(dāng)緩存存放的數(shù)據(jù)超過最大空間時(shí)，就需要根據(jù)淘汰算法來淘汰部分?jǐn)?shù)據(jù)存放新到達(dá)的數(shù)據(jù)。
淘汰算法
緩存的存儲空間有限制，當(dāng)緩存空間被用滿時(shí)，如何保證在穩(wěn)定服務(wù)的同時(shí)有效提升命中率？這就由緩存淘汰算法來處理，設(shè)計(jì)適合自身數(shù)據(jù)特征的淘汰算法能夠有效提升緩存命中率。常見的淘汰算法有：
FIFO(first in first out)
「先進(jìn)先出」。最先進(jìn)入緩存的數(shù)據(jù)在緩存空間不夠的情況下（超出最大元素限制）會被優(yōu)先被清除掉，以騰出新的空間接受新的數(shù)據(jù)。策略算法主要比較緩存元素的創(chuàng)建時(shí)間。「適用于保證高頻數(shù)據(jù)有效性場景，優(yōu)先保障最新數(shù)據(jù)可用」。
LFU(less frequently used)
「最少使用」，無論是否過期，根據(jù)元素的被使用次數(shù)判斷，清除使用次數(shù)較少的元素釋放空間。策略算法主要比較元素的
hitCount（命中次數(shù)）。「適用于保證高頻數(shù)據(jù)有效性場景」。
LRU(least recently used)
「最近最少使用」，無論是否過期，根據(jù)元素最后一次被使用的時(shí)間戳，清除最遠(yuǎn)使用時(shí)間戳的元素釋放空間。策略算法主要比較元素最近一次被get使用時(shí)間。「比較適用于熱點(diǎn)數(shù)據(jù)場景，優(yōu)先保證熱點(diǎn)數(shù)據(jù)的有效性。」
?
進(jìn)程緩存
為什么需要引入本地緩存，本地緩存的應(yīng)用場景有哪些？
本地緩存的話是我們的應(yīng)用和緩存都在同一個(gè)進(jìn)程里面，獲取緩存數(shù)據(jù)的時(shí)候純內(nèi)存操作，沒有額外的網(wǎng)絡(luò)開銷，速度非常快。它適用于緩存一些應(yīng)用中基本不會變化的數(shù)據(jù)，比如（國家、省份、城市等）。
項(xiàng)目中一般如何使用、怎么樣加載、怎么樣更新？
進(jìn)程緩存的話，一般可以在應(yīng)用啟動的時(shí)候，把需要的數(shù)據(jù)加載到系統(tǒng)中。更新緩存的話可以采取定時(shí)更新（實(shí)時(shí)性不高）。具體實(shí)現(xiàn)的話就是在應(yīng)用中起一個(gè)定時(shí)任務(wù)（「ScheduledExecutorService」、「TimerTask」等），讓它每隔多久去加載變更（數(shù)據(jù)變更之后可以修改數(shù)據(jù)庫最后修改的時(shí)間，每次查詢變更數(shù)據(jù)的時(shí)候都可以根據(jù)這個(gè)最后變更時(shí)間加上半小時(shí)大于當(dāng)前時(shí)間的數(shù)據(jù)）的數(shù)據(jù)重新到緩存里面來。
如果覺得這個(gè)比較麻煩的話，還可以直接全部全量更新（就跟項(xiàng)目啟動加載數(shù)據(jù)一樣）。這種方式的話，對數(shù)據(jù)更新可能會有點(diǎn)延遲。可能這臺機(jī)器看到的是更新后的數(shù)據(jù)，那臺機(jī)器看到的數(shù)據(jù)還是老的（機(jī)器發(fā)布時(shí)間可能不一樣）。
所以這種方式比較適用于對數(shù)據(jù)實(shí)時(shí)性要求不高的數(shù)據(jù)。如果對實(shí)時(shí)性有要求的話可以通過廣播訂閱mq消息。如果有數(shù)據(jù)更新mq會把更新數(shù)據(jù)推送到每一臺機(jī)器，這種方式的話實(shí)時(shí)性會比前一種「定時(shí)更新」的方法會好。但是實(shí)現(xiàn)起來會比較復(fù)雜。
本地緩存有哪些實(shí)現(xiàn)方式？
常見本地緩存有以下幾種實(shí)現(xiàn)方式：
從上述表格我們看出性能最佳的是Caffeine。關(guān)于這個(gè)本地緩存的話我還是強(qiáng)烈推薦的，里面提供了豐富的api，以及各種各樣的淘汰算法。
本地緩存缺點(diǎn)
本地緩存與業(yè)務(wù)系統(tǒng)耦合在一起，應(yīng)用之間無法直接共享緩存的內(nèi)容。需要每個(gè)應(yīng)用節(jié)點(diǎn)單獨(dú)的維護(hù)自己的緩存。每個(gè)節(jié)點(diǎn)都需要一份一樣的緩存，對服務(wù)器內(nèi)存造成一種浪費(fèi)。本地緩存機(jī)器重啟、或者宕機(jī)都會丟失。
?
分布式緩存
分布式緩存是與應(yīng)用分離的緩存組件或服務(wù)，其最大的優(yōu)點(diǎn)是自身就是一個(gè)獨(dú)立的應(yīng)用，與本地應(yīng)用隔離，多個(gè)應(yīng)用可直接的共享緩存。常見的分布式緩存有
redis、MemCache等。
分布式緩存的應(yīng)用
在高并發(fā)的環(huán)境下，比如春節(jié)搶票大戰(zhàn)，一到放票的時(shí)間節(jié)點(diǎn)，分分鐘大量用戶以及黃牛的各種搶票軟件流量進(jìn)入12306，這時(shí)候如果每個(gè)用戶的訪問都去數(shù)據(jù)庫實(shí)時(shí)查詢票的庫存，大量讀的請求涌入到數(shù)據(jù)庫，瞬間Db就會被打爆，cpu直接上升100%，服務(wù)馬上就要宕機(jī)或者假死。
即使進(jìn)行了分庫分表也是無法避免的。為了減輕db的壓力以及提高系統(tǒng)的響應(yīng)速度。一般都會在數(shù)據(jù)庫前面加上一層緩存，甚至可能還會有多級緩存。
?
緩存常見問題
緩存雪崩
指大量緩存同一時(shí)間段集體失效，或者緩存整體不能提供服務(wù)，導(dǎo)致大量的請求全部到達(dá)數(shù)據(jù)庫
對數(shù)據(jù)CPU和內(nèi)存造成巨大壓力，嚴(yán)重的會造成數(shù)據(jù)庫宕機(jī)。因此而形成的一系列連鎖反應(yīng)造成整個(gè)系統(tǒng)奔潰。解決這個(gè)問題可以從以下方面入手：
保證緩存的高可用。使用redis的集群模式，即使個(gè)別
redis節(jié)點(diǎn)下線，緩存還是可以用。一般稍微大點(diǎn)的公司還可能會在多個(gè)機(jī)房部署Redis。這樣即使某個(gè)機(jī)房突然停電，或者光纖又被挖斷了，這時(shí)候緩存還是可以使用。使用多級緩存。不同級別緩存時(shí)間過時(shí)時(shí)間不一樣，即使某個(gè)級別緩存過期了，還有其他緩存級別 兜底。比如我們Redis緩存過期了，我們還有本地緩存。這樣的話即使沒有命中redis，有可能會命中本地緩存。
緩存永不過期。Redis中保存的key永久不失效，這樣的話就不會出現(xiàn)大量緩存同時(shí)失效的問題，但是這種做法會浪費(fèi)更多的存儲空間，一般應(yīng)該也不會推薦這種做法。
使用隨機(jī)過期時(shí)間。為每一個(gè)key都合理的設(shè)計(jì)一個(gè)過期時(shí)間，這樣可以避免大量的key在同一時(shí)刻集體失效。
異步重建緩存。這樣的話需要維護(hù)每個(gè)
key的過期時(shí)間，定時(shí)去輪詢這些key的過期時(shí)間。例如一個(gè)key的value設(shè)置的過期時(shí)間是30min，那我們可以為這個(gè)key設(shè)置它自己的一個(gè)過期時(shí)間為20min。所以當(dāng)這個(gè)key到了20min的時(shí)候我們就可以重新去構(gòu)建這個(gè)key的緩存，同時(shí)也更新這個(gè)key的一個(gè)過期時(shí)間。
緩存穿透
指查詢一個(gè)不存在的數(shù)據(jù)，每次通過接口或者去查詢數(shù)據(jù)庫都查不到這個(gè)數(shù)據(jù)，比如黑客的惡意攻擊，比如知道一個(gè)訂單號后，然后就偽造一些不存在的訂單號，然后并發(fā)來請求你這個(gè)訂單詳情。這些訂單號在緩存中都查詢不到，然后會導(dǎo)致把這些查詢請求全部打到數(shù)據(jù)庫或者SOA接口。這樣的話就會導(dǎo)致數(shù)據(jù)庫宕機(jī)或者你的服務(wù)大量超時(shí)。這種查詢不存在的數(shù)據(jù)就是緩存擊穿。解決這個(gè)問題可以從以下方面入手：
緩存空值，對于這些不存在的請求，仍然給它緩存一個(gè)空的結(jié)果，這種方式簡單粗暴，但是如果后續(xù)這個(gè)請求有新值了需要把原來緩存的空值刪除掉（所以一般過期時(shí)間可以稍微設(shè)置的比較短）。
通過布隆過濾器。查詢緩存之前先去布隆過濾器查詢下這個(gè)數(shù)據(jù)是否存在。如果數(shù)據(jù)不存在，然后直接返回空。這樣的話也會減少底層系統(tǒng)的查詢壓力。
緩存沒有直接返回。這種方式的話要根據(jù)自己的實(shí)際業(yè)務(wù)來進(jìn)行選擇。比如固定的數(shù)據(jù)，一些省份信息或者城市信息，可以全部緩存起來。這樣的話數(shù)據(jù)有變化的情況，緩存也需要跟著變化。實(shí)現(xiàn)起來可能比較復(fù)雜。
緩存擊穿
是指緩存里面的一個(gè)熱點(diǎn)key(拼多多的五菱宏光神車的秒殺)在某個(gè)時(shí)間點(diǎn)過期。針對于這一個(gè)key有大量并發(fā)請求過來然后都會同時(shí)去數(shù)據(jù)庫請求數(shù)據(jù)，瞬間對數(shù)據(jù)庫造成巨大的壓力。這個(gè)的話可以用緩存雪崩的幾種解決方法來避免：
緩存永不過期。Redis中保存的key永久不失效，這樣的話就不會出現(xiàn)大量緩存同時(shí)失效的問題，但是這種做法會浪費(fèi)更多的存儲空間，一般應(yīng)該也不會推薦這種做法。
異步重建緩存。這樣的話需要維護(hù)每個(gè)
key的過期時(shí)間，定時(shí)去輪詢這些key的過期時(shí)間。例如一個(gè)key的value設(shè)置的過期時(shí)間是30min，那我們可以為這個(gè)key設(shè)置它自己的一個(gè)過期時(shí)間為20min。所以當(dāng)這個(gè)key到了20min的時(shí)候我們就可以重新去構(gòu)建這個(gè)key的緩存，同時(shí)也更新這個(gè)key的一個(gè)過期時(shí)間。互斥鎖重建緩存。這種情況的話只能針對于同一個(gè)
key的情況下，比如你有100個(gè)并發(fā)請求都要來取A的緩存，這時(shí)候我們可以借助redis分布式鎖來構(gòu)建緩存，讓只有一個(gè)請求可以去查詢DB其他99個(gè)（沒有獲取到鎖）都在外面等著，等A查詢到數(shù)據(jù)并且把緩存構(gòu)建好之后其他99個(gè)請求都只需要從緩存取就好了。原理就跟我們java的DCL（double checked locking）思想有點(diǎn)類似。
?
緩存更新
我們一般的緩存更新主要有以下幾種更新策略：
先更新緩存，再更新數(shù)據(jù)庫
先更新數(shù)據(jù)庫，再更新緩存
先刪除緩存，再更新數(shù)據(jù)庫
先更新數(shù)據(jù)源庫，再刪除緩存 至于選擇哪種更新策略的話，沒有絕對的選擇，可以根據(jù)自己的業(yè)務(wù)情況來選擇適合自己的不過一般推薦的話是選擇 「先更新數(shù)據(jù)源庫，再刪除緩存」。關(guān)于這幾種更新的介紹可以推薦大家看下博客園大佬孤獨(dú)煙寫的《分布式之?dāng)?shù)據(jù)庫和緩存雙寫一致性方案解析》這一篇文章，看完文章評論也可以去看看，評論跟內(nèi)容一樣精彩。
?
總結(jié)
如果想要真正的設(shè)計(jì)好一個(gè)緩存，我們還是必須要掌握很多的知識，對于不同場景，緩存有各自不同的用法。比如實(shí)際工作中我們對于訂單詳情的一個(gè)緩存。我們可能會根據(jù)訂單的狀態(tài)來來構(gòu)建緩存。
我們就以機(jī)票訂單為例，已出行、或者已經(jīng)取消的訂單我們基本上是不會去管的（訂單狀態(tài)已經(jīng)終止了），這種的話數(shù)據(jù)基本也不會變了，所以對于這種訂單我們設(shè)置的過期時(shí)間是不是就可以久一點(diǎn)，比如7天或者30天。對于未出行即將起飛的訂單，這時(shí)候顧客是不是就會頻繁的去刷新訂單看看，看看有沒有晚點(diǎn)什么的，或者登機(jī)口是在哪。
對于這種實(shí)時(shí)性要求比較高的訂單我們過期時(shí)間還是要設(shè)置的比較短的，如果是需要更改訂單的狀態(tài)查詢的時(shí)候可以直接不走緩存，直接查詢master庫。畢竟這種更改訂單狀態(tài)的操作還是比較有限的。
大多數(shù)情況都是用來展示的。展示的話是可以允許實(shí)時(shí)性要求沒那么高。總的來說需要開具體的業(yè)務(wù)，沒有通用的方案。看你的業(yè)務(wù)需求的容忍度，畢竟脫離了業(yè)務(wù)來談技術(shù)都是耍流氓，是業(yè)務(wù)驅(qū)動技術(shù)。
參考：
https://juejin.im/post/6844903665845665805?
https://tech.meituan.com/2017/03/17/cache-about.html
https://www.cnblogs.com/rjzheng/p/9041659.html#!comments
有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)
歡迎大家關(guān)注Java之道公眾號
好文章，我在看??