[[312192]]

俗話說，計(jì)算機(jī)編程的任何問題，都可以通過增加一個(gè)抽象層來解決，這句話用在我身上就太合適了。

我是緩存(Cache)，今天我給大家聊聊我這個(gè)抽象層是怎么工作的。

提到我的名字，你可能立刻會(huì)想到到Redis， 因?yàn)樗鼘?shí)在是太普及了，但是如果你只想到Redis，那視野未必有點(diǎn)狹窄，Redis僅僅是我在應(yīng)用層小試牛刀而已。

Wikipedia上說我是一種用來保存數(shù)據(jù)的硬件或者軟件，這樣以后的訪問請(qǐng)求就可以更快地返回。

這個(gè)定義還真是挺抽象的，抽象的東西讓人感覺不好理解，我得給大家舉幾個(gè)例子。

為了突出我的位置， 在下面的圖片中，緩存都用藍(lán)色來表示。

首先來看大家日常使用很多，但是又不太在意的瀏覽器緩存。

瀏覽器緩存

瀏覽器面對(duì)的問題是網(wǎng)絡(luò)訪問的速度遠(yuǎn)遠(yuǎn)低于本地訪問的速度，每次都訪問網(wǎng)絡(luò)開銷太大。

于是它就請(qǐng)我增加了一個(gè)中間層：開辟“緩存”區(qū)域，緩存JS, HTML, CSS，圖片等各種文件。

 

當(dāng)然，瀏覽器這家伙也不能亂來，得遵循一定的規(guī)則來判斷什么時(shí)候用緩存中的文件，什么時(shí)候不辭辛苦地去訪問服務(wù)器的新文件。

這其中的關(guān)鍵點(diǎn)就是HTTP協(xié)議：

 

在服務(wù)器發(fā)給瀏覽器的響應(yīng)中，有expires, max-age, last-modified, Etag等Header， 粗略來說，expires 和 max-age 定義了一個(gè)資源的過期時(shí)間， last-modified和Etag用來檢查一個(gè)資源在服務(wù)器端有沒有變化。

對(duì)于它們的含義和詳細(xì)用法，網(wǎng)上資料多如牛毛，我這里就不再展開了。

我覺得有趣的事情是這些：

1. 當(dāng)你在地址欄中輸入網(wǎng)址，按回車以后 瀏覽器會(huì)使用Expires，max-age來查看本地緩存的內(nèi)容是否失效，如果沒有，就直接使用

2. 當(dāng)你按F5或者按瀏覽器刷新按鈕的時(shí)候 瀏覽器不再考慮Expires，max-age， 而是把Last-Modified / ETag 發(fā)到服務(wù)器去，問問服務(wù)器，這個(gè)文件有更新沒有?如果沒有，那就用本地緩存的文件，如果有更新，用服務(wù)器端最新的。

3. 當(dāng)你用Ctrl + F5強(qiáng)制刷新的時(shí)候 不使用任何緩存，向服務(wù)器發(fā)出全新請(qǐng)求。

CDN

說起CDN，可能很多人都意識(shí)不到它的存在，這也難怪，它對(duì)于大家來說幾乎是透明的，魔法發(fā)生在DNS的域名解析的過程。

但是CDN也是不折不扣的緩存。 由于網(wǎng)絡(luò)情況復(fù)雜，如果客戶端離服務(wù)器比較遠(yuǎn)，網(wǎng)速慢，體驗(yàn)會(huì)很差;海量的用戶給后端服務(wù)器帶來巨大壓力，所以CDN就采用了就近訪問的方案：

 

把后端服務(wù)器的數(shù)據(jù)數(shù)據(jù)復(fù)制多份，挪到離客戶端比較近的“邊緣”服務(wù)器中，就近訪問，不但減少了訪問的時(shí)間，還大大降低了 “中央”服務(wù)器的負(fù)載。

瀏覽器緩存和CDN是配合使用的， 瀏覽器的本地緩存失效以后，就需要向后端服務(wù)器來獲取了，但是如果一個(gè)系統(tǒng)有CDN，那瀏覽器還可以就近訪問CDN。

Linux Page Cache

在操作系統(tǒng)的世界中，時(shí)間是按納秒，微秒為單位的，雖然內(nèi)存和硬盤都在同一臺(tái)機(jī)器中，沒有網(wǎng)絡(luò)開銷，但是硬盤實(shí)在是太慢，比內(nèi)存慢幾萬倍， 內(nèi)存等不及。

所以Linux也增加了一個(gè)抽象層：Page cache ， 把慢如蝸牛的硬盤的文件緩存在其中。

 

 

有了這個(gè)抽象層， 在Linux當(dāng)中，幾乎所有的文件讀寫操作都依賴Page Cache，在向硬盤寫入文件的時(shí)候，并不是直接把文件內(nèi)容寫入硬盤以后才返回的，而是寫入到內(nèi)核的Page Cache就直接返回了。

這個(gè)Page Cache會(huì)被標(biāo)記為“Dirty”，隨后由內(nèi)核線程寫入硬盤(也可以通過手工用sync命令寫入)。

各位看官可以想想，如果Page cache 的數(shù)據(jù)還沒有寫入硬盤，就斷電了，會(huì)發(fā)生什么事情? 該怎么處理?

當(dāng)從硬盤讀取文件時(shí)，也不是直接把數(shù)據(jù)從硬盤復(fù)制到用戶態(tài)的內(nèi)存，而是先復(fù)制到內(nèi)核的Page Cache ，然后再復(fù)制到用戶態(tài)的內(nèi)存。

正是由于這樣復(fù)制來復(fù)制去，在多個(gè)進(jìn)程中間進(jìn)行數(shù)據(jù)傳輸很麻煩，例如(一個(gè)進(jìn)程讀取文件，然后通過Socket發(fā)送) ，所以后來就出現(xiàn)了零復(fù)制技術(shù)。

應(yīng)用程序緩存

終于來到了大家熟悉的應(yīng)用程序緩存， 這個(gè)就不用我多說了， 因?yàn)閿?shù)據(jù)庫訪問速度慢，無法應(yīng)對(duì)大量的并發(fā)訪問，所以增加一個(gè)緩存中間層，把熱點(diǎn)數(shù)據(jù)從數(shù)據(jù)庫中取出，放到可以快速訪問的內(nèi)存當(dāng)中。

 

大名鼎鼎的Redis干的就是這個(gè)活。

可是應(yīng)用程序的緩存也是個(gè)雙刃劍，提升了訪問的效率， 但是帶來了很多復(fù)雜性：

1. 代碼變復(fù)雜

2. 需要處理緩存和數(shù)據(jù)庫之間的數(shù)據(jù)一致性的問題

3. 處理緩存的穿透，雪崩等問題

4. 應(yīng)用程序緩存現(xiàn)在已經(jīng)變成了分布式的集群形式，數(shù)據(jù)的管理越來越麻煩。

CPU緩存

前面剛說到內(nèi)存比硬盤快幾萬倍， 可是在CPU面前，內(nèi)存也只能屈居下風(fēng)，CPU比內(nèi)存快100多倍，數(shù)據(jù)和指令必須從內(nèi)存加載到CPU才能執(zhí)行， 這次輪到CPU等不及了。

那就在CPU內(nèi)增加緩存中間層，不過這次必須用硬件來實(shí)現(xiàn)。

CPU的緩存包括L1，L2, L3這三級(jí)Cache，把最熱點(diǎn)的數(shù)據(jù)和指令放入到其中。

 

 

我猜CPU Cache可能是最“底層”的Cache了。

在L1 Cache 最靠近CPU，速度最快，可以分為指令Cache (CPU要執(zhí)行的指令)和數(shù)據(jù)Cache(指令要操作的數(shù)據(jù))。

CPU Cache 和上面提到的各種Cache比起來，小得可憐，也就是幾百K到幾M。 所以這些Cache要想發(fā)揮真正的作用，必須得依賴上帝的規(guī)矩局部性原理：

(1) 時(shí)間局部性：如果程序中的某條指令一旦執(zhí)行，則不久之后該指令可能再次被執(zhí)行;如果某數(shù)據(jù)被訪問，則不久之后該數(shù)據(jù)可能再次被訪問。

(2) 空間局部性：指一旦程序訪問了某個(gè)存儲(chǔ)單元，則不久之后。其附近的存儲(chǔ)單元也將被訪問。

最后總結(jié)一下放置在我這里的數(shù)據(jù)的特點(diǎn)，大家可以感受下：

(1)對(duì)數(shù)據(jù)的讀操作遠(yuǎn)大于寫操作

(2)數(shù)據(jù)可能是之前的計(jì)算結(jié)果(計(jì)算過程比較耗時(shí))

(3)數(shù)據(jù)是某個(gè)(速度較慢的)數(shù)據(jù)源的數(shù)據(jù)備份。

(4)數(shù)據(jù)訪問遵循上帝的規(guī)矩“局部性原理”

如果你在工作中也遇到了問題，不妨考慮一下，看看能不能用我來解決問題：增加一個(gè)中間層， 用空間來換取時(shí)間。

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過作者微信公眾號(hào)coderising獲取授權(quán)】

 

戳這里，看該作者更多好文