深刻剖析Java面試熱門話題：分佈式緩存！

做者：ZacharyZF

來源公衆號：跨界架構師

本文版權歸做者全部

------------------------------------------------

只要是位正兒八經的程序員天然知道「緩存」是什麼，甚至我司的不少作運營的小姐姐如今和程序員小哥哥的交流中都時不時冒出「緩存」字眼，讓人壓力山大（本文討論的「緩存」皆指的是軟件層面運用的緩存）

你們都知道的一點是，緩存可讓本來打開很慢的頁面，變得能「秒開」。你平時訪問的APP、網站幾乎都有涉及到緩存的運用。

那麼，緩存除了能加速數據的訪問以外，還有什麼做用呢？

另外，任何事物都有兩面性，咱們如何才能將緩存的優勢發揮得淋淋盡致，同時避免掉到它的弊端中呢？

Z哥今天想分享給你的就是我對緩存的理解和運用的思路，但願對你有所啓發。

「緩存」能作什麼？

正如前面所說，你們最廣泛的理解就是當咱們遇到某個頁面打開很慢的時候，會想到引入緩存，這樣頁面打開就快了。

其實快和慢都是相對的，從技術角度來講，緩存之因此快是由於緩存是基於內存去創建的，而內存的讀寫速度比硬盤快X倍，因此用內存來代替硬盤做爲讀寫的介質天然能大大提升訪問數據的速度。

這個過程大體是這樣的，經過在內存中存儲被訪問過的數據，供後續訪問時使用，以此來達到提速的效果。

其實除此以外，緩存還有另外2個重要的運用方式，「預讀取」和「延遲寫」

預讀取

預讀取就是預先讀取將要載入的數據，也能夠稱做「緩存預熱」。

就是在系統對外提供服務以前，先將硬盤中的一部分數據加載到內存中，而後再對外提供服務。

爲何要這樣作呢？

由於有些系統一旦啓動就要面臨上千上萬的請求進來（在一些toC的項目尤爲如此），若是直接讓這些請求打到數據庫上，很是大的多是數據庫壓力暴增，直接被幹趴，沒法正常響應。

爲了緩解這個問題，須要經過「預讀取」來解決。

可能你會問，哪怕用了緩存仍是扛不住呢？那就是作橫向擴展+負載均衡的時候到了

若是說「預讀取」是在「數據出口」加了一道前置的緩衝區的話，那麼顧名思義，下面要說的「延遲寫」就是在「數據入口」後面加了一道後置的緩衝區。

延遲寫

你可能知道，數據庫的寫入速度是慢於讀取速度的，由於寫入的時候有一系列的保證數據準確性的機制。

因此，若是想提高寫入速度的話，要麼作分庫分表，要麼就是經過緩存來進行一道緩衝，再一次性批量寫到磁盤，以此來提速。

題外話：因爲分庫分表對跨表操做以及多條件組合查詢的反作用巨大，因此引入它的複雜度遠大於引入緩存，咱們應當優先考慮引入緩存的方案。

那麼，經過緩存機制來加速「寫」的過程就能夠稱做「延遲寫」。就是預先將須要寫入到磁盤或者數據庫的數據，先暫時寫入到內存，而後就返回成功。再定時將內存中的數據批量寫入到磁盤。

可能你會想，寫到內存就認爲成功，萬一中途出現意外、斷電、停機等致使程序異常終止的狀況，數據不就丟了嗎？

是的。因此，「延遲寫」通常僅用於對數據完整性要求不是那麼苛刻的場景。好比點贊數啊、參與用戶數啊等等，能夠大大緩解對數據庫頻繁修改所帶來的壓力。

其實在咱們熟知的分佈式緩存Redis中，其默認運用的持久化機制——RDB，也是這樣的思路。

在一個成熟的系統中，可以運用到緩存的地方其實並非一處。下面Z哥就來幫你梳理一下咱們在哪些地方能夠「加緩存」。

哪裏能夠加「緩存」？

在說哪裏能夠加緩存以前咱們先搞清楚一個事情，咱們要緩存什麼？也就是符合什麼特色的數據才須要加緩存？畢竟加緩存是一個額外的成本投入，得物有所值。

通常來講你能夠用這兩個標準來判斷：熱點（被高頻訪問，如幾十次/秒以上）數據、靜態（不多變化，讀遠大於寫，如幾天變動一次）數據。

接下去就能夠替它們找到合適的地方加緩存了。

緩存的本質是一個「防護性」的機制，而系統之間的數據流轉是一個有序的過程。因此，選擇在哪裏加緩存就至關於選擇在一條馬路的哪一個位置設路障。在這個路障以後的道路都能受到保護，不被車流碾壓。

那麼在以終端用戶爲起點，系統所用的數據庫爲終點的這條道路上能夠做爲緩存設立點的位置大體有如下這些。

每一個設立點能夠擋掉一些流量，最終造成一個漏斗狀的攔截效果，以此保護最後面的系統以及最終的數據庫。

下面Z哥來簡要描述下每個的運用場景以及須要注意的點。

瀏覽器緩存

這是離用戶最近的能夠做爲緩存的地方，並且藉助的是用戶的「資源」（緩存的數據在用戶的終端設備上），性價比可謂最好，讓用戶幫你分擔壓力。

當你打開瀏覽器的開發者工具，看到from cache或者from memory cache、from disk cache的時候，就意味着這些數據已經被緩存在了用戶的終端設備上了（沒網的時候也能訪問到一部份內容就是這個緣由）。

這個過程是瀏覽器替咱們完成的，通常用於緩存圖片、js、css這些。咱們能夠經過Http消息頭中的Cache-Control來控制它，具體細節這裏就不展開了。

js裏的全局變量、以及cookie等運用也屬於該範疇。

瀏覽器緩存是在於用戶側的緩存點，因此咱們對其的掌控力就差不少，在沒有發起新請求的狀況下，你沒法主動去更新數據。

CDN緩存

提供CDN服務的服務商，在全國甚至是全球部署着大量的服務器節點（能夠叫作「邊緣服務器」）。

那麼將數據分發到這些遍及各地服務器上做爲緩存，讓用戶訪問就近的服務器上的緩存數據，就能夠起到壓力分攤和加速效果。這在ToC類型的系統上運用，效果格外顯著。

可是須要注意的是，因爲節點衆多，更新緩存數據比較緩慢，通常至少是分鐘級別。因此通常僅適用於不常常變更的靜態數據。

題外話：解決方式也是有的，就是在url後面帶個自增數或者惟一標示，如?v=1001。由於不一樣的url會被視做「新」的數據和文件，被從新create出來。

網關（代理）緩存

到這裏作緩存就是在你本身的地盤了。不少時候咱們會在源站前面架一層網關（或者說反向代理、正向代理），爲的是作一些安全機制或者統一分流策略的入口。

同時這裏也是作緩存的一個好場所。畢竟網關是「業務無關性」的，它可以攔下來的請求，對背後的源站也是很大的受益，減小了大量的CPU運算。

經常使用的網關（代理）緩存有Varnish，Squid，Ngnix。通常狀況下，簡單的緩存運用場景，用nginx便可，由於大部分時候咱們會用它來作負載均衡，能少引入一個技術就少一份複雜度嘛。

若是是大量的小文件可使用Varnish，而Squid則相對大而全，運用成本也更高一些。

進程內緩存

一個請求能走到這裏說明他是「業務相關」的，須要通過業務邏輯的運算。

也正由於如此，從這裏開始對緩存的引入成本比前面3種大大增長，由於對緩存與數據庫之間的「數據一致性」要求更高了。

可能咱們大多數程序員第一次刻意使用緩存的場景就是這個時候。進程內和進程外的緩存運用中有不少的細節須要注意，這些也是咱們後續文章的內容，因此咱們後續再詳聊。

進程外緩存

這個你們也熟悉，就是redis、memcached之類，甚至也能夠本身單獨寫一個程序來專門存放緩存數據，供其餘程序遠程調用。

一樣，這裏的細節咱們後續再聊，這裏先多說幾句關於redis和memcached該怎麼選擇的建議。

對資源（cpu、內存等）利用率格外重視的話可使用Memcached，但程序在使用的時候須要容忍可能發生的數據丟失，由於是純內存的機制。

若是沒法容忍這點，而且對資源利用率也比較豪放的話可使用redis。並且redis的數據庫結構更多，Memcached只有key value，更像是一個nosql存儲。

數據庫緩存

數據庫自己自帶緩存模塊的，不然也不會叫它內存殺手，基本上你給多少內存就能吃多少。

數據庫緩存是數據庫的內部機制，咱們這裏就不深刻下去了。通常都會給出設置緩存空間大小的配置來讓你進行干預。

最後，其實磁盤自己也有緩存。因此你會發現，爲了讓數據可以平穩的寫到物理磁盤中真的是一波三折，不知道何時能夠有「快」到不須要程序來考慮緩存的磁盤出現來拯救咱們程序員呢。

「緩存」是Silver bullet嗎？

可能你會想緩存那麼好，那麼應該多多益善，只要慢就上緩存來解決？

一個事物看上去再好，也有它負面的一面。緩存也有一系列的反作用須要考慮。除了上面提到的「緩存更新」和「緩存與數據的一致性」問題，還有諸如：

1. 緩存雪崩

2. 緩存穿透

3. 緩存併發

4. 緩存無底洞

5. 緩存淘汰

6. ...

總結

好了，咱們總結一下。此次呢，Z哥先向你介紹了運用緩存的三種思路。

而後梳理了在一個完整的系統中能夠設立緩存的幾個位置，而且分享了關於瀏覽器緩存、CDN緩存、網關（代理）緩存的一些使用經驗。

但願對你有所啓發。

End

掃描下方二維碼試讀

《從零開始帶你成爲JVM實戰高手》詳細目錄：