緩存有那麼多種，分別是幹什麼的？

時間 2020-04-07

標籤緩存那麼多種分別幹什麼简体版

原文原文鏈接

本文做者：oschina_2020css

只要是位正兒八經的程序員應該都知道「緩存」是什麼，甚至我司的不少作運營的小姐姐如今和程序員小哥哥交流中都時不時冒出「緩存」這個詞，讓人壓力山大。程序員

固然，這裏討論的是指軟件層面的緩存。你們都知道的一點是，緩存可讓本來打開很慢的頁面，變得能「秒開」。你平時訪問的 APP 與網站幾乎都有涉及到緩存的運用。數據庫

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

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

本文接下來就給你們分享一下如何理解緩存，以及它的運用思路，但願對你有所啓發。安全

緩存能作什麼？

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

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

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

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

預讀取

預讀取就是預先讀取將要載入的數據，也能夠稱做「緩存預熱」，它是在系統中先將硬盤中的一部分數據加載到內存中，而後再對外提供服務。

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

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

可能你會問，哪怕用了緩存仍是扛不住呢？那就是作橫向擴展+負載均衡的時候到了，這不是本文討論的內容，有機會再專門分享吧。

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

延遲寫

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

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

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

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

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

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

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

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

哪裏能夠加緩存？

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

通常來講你能夠用這兩個標準來判斷：

熱點數據：被高頻訪問，如幾十次/秒以上
靜態數據：不多變化，讀遠大於寫，如幾天變動一次

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

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

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

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

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

瀏覽器緩存

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

當你打開瀏覽器的開發者工具，看到 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 存儲。

數據庫緩存

數據庫自己是自帶緩存模塊的，不然也不會叫它內存殺手，基本上你給多少內存就能吃多少。數據庫緩存是數據庫的內部機制，通常都會給出設置緩存空間大小的配置來讓你進行干預。

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

緩存是銀彈嗎？

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

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

緩存雪崩。在大量的請求併發進入時，因爲某些緣由未起到預期的緩衝效果，哪怕只是很短的一段時間，致使請求所有流轉到數據庫，形成數據庫壓力太重。解決它能夠經過「加鎖排隊」或者「緩存時間增長隨機值」。
緩存穿透。和「緩存雪崩」比較相似，區別是這會持續更長的時間，由於每次「cache miss」後依然沒法從數據源加載數據到緩存，致使持續產生「cache miss」。解決它能夠經過「布隆過濾器」或者「緩存空對象」。
緩存併發。一個緩存 Key 下的數據被同時 set，怎麼保證業務的準確性？再加上數據庫的話呢？進程內緩存、進程外緩存與數據庫三者皆用的狀況下呢？用一句話來歸納建議的方案是：使用「先 DB 再緩存」的方式，而且緩存操做用 delete 而不是 set。
緩存無底洞。雖然分佈式緩存是能夠無限橫向擴展的，可是，集羣下的節點真的是越多越好嗎？固然不是，緩存也是符合「邊際效應遞減」規律的。
緩存淘汰。內存老是有限的，若是數據量很大，那麼根據具體的場景定製合理的淘汰策略是必不可少的，如 LRU、LFU 與 FIFO 等等。

因此緩存不是銀彈，對緩存的使用也須要先考慮各類問題。總結一下，本文先向你介紹了運用緩存的三種思路，而後梳理了在一個完整的系統中能夠設立緩存的幾個位置，而且分享了關於瀏覽器、CDN 與網關（代理）等緩存的一些使用經驗，沒有具體展開來說細節，只是但願你對緩存有一個更加體系化的認識，但願能讓你看得更加全面。