如果這是第二次看到我的文章，歡迎文末掃碼訂閱我個人的公眾號（跨界架構(gòu)師）喲~  

站在用戶的角度思考問題，與客戶深入溝通，找到鳳凰網(wǎng)站設(shè)計與鳳凰網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋鳳凰地區(qū)。

本文長度為3578字，建議閱讀10分鐘。

堅持原創(chuàng)，每一篇都是用心之作～

此前的「伸縮性」章節(jié)結(jié)束了，此文是「高性能」章節(jié)的第一篇。

只要是位正兒八經(jīng)的程序員自然知道「緩存」是什么，甚至我司的很多做運營的×××姐現(xiàn)在和程序員小哥哥的交流中都時不時冒出「緩存」字眼，讓人壓力山大。（本文討論的「緩存」皆指的是軟件層面運用的緩存）

大家都知道的一點是，緩存可以讓原本打開很慢的頁面，變得能“秒開”。你平時訪問的APP、網(wǎng)站幾乎都有涉及到緩存的運用。

那么，緩存除了能加速數(shù)據(jù)的訪問之外，還有什么作用呢？

另外，任何事物都有兩面性，我們?nèi)绾尾拍軐⒕彺娴膬?yōu)點發(fā)揮得淋淋盡致，同時避免掉到它的弊端中呢？

Z哥今天想分享給你的就是我對緩存的理解和運用的思路，希望對你有所啟發(fā)。

「緩存」能做什么？

正如前面所說，大家最普遍的理解就是當(dāng)我們遇到某個頁面打開很慢的時候，會想到引入緩存，這樣頁面打開就快了。

其實快和慢都是相對的，從技術(shù)角度來說，緩存之所以快是因為緩存是基于內(nèi)存去建立的，而內(nèi)存的讀寫速度比硬盤快X倍，所以用內(nèi)存來代替硬盤作為讀寫的介質(zhì)自然能大大提高訪問數(shù)據(jù)的速度。

這個過程大致是這樣的，通過在內(nèi)存中存儲訪被問過的數(shù)據(jù)供后續(xù)訪問時使用，以此來達到提速的效果。

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

預(yù)讀取

預(yù)讀取就是預(yù)先讀取將要載入的數(shù)據(jù)，也可以稱作「緩存預(yù)熱」。就是在系統(tǒng)對外提供服務(wù)之前，先將硬盤中的一部分?jǐn)?shù)據(jù)加載到內(nèi)存中，然后再對外提供服務(wù)。

為什么要這樣做呢？因為有些系統(tǒng)一旦啟動就要面臨上千上萬的請求進來（在一些toC的項目尤其如此），如果直接讓這些請求打到數(shù)據(jù)庫上，非常大的可能是數(shù)據(jù)庫壓力暴增，直接被干趴，無法正常響應(yīng)。

為了緩解這個問題，需要通過「預(yù)讀取」來解決。

可能你會問，哪怕用了緩存還是扛不住呢？那就是做橫向擴展+負載均衡的時候到了。（可以點擊文末鏈接閱讀之前的《彈性架構(gòu)》系列）

如果說「預(yù)讀取」是在「數(shù)據(jù)出口」加了一道前置的緩沖區(qū)的話，那么顧名思義，下面要說的「延遲寫」就是在「數(shù)據(jù)入口」后面加了一道后置的緩沖區(qū)。

延遲寫

你可能知道，數(shù)據(jù)庫的寫入速度是慢于讀取速度的，因為寫入的時候有一系列的保證數(shù)據(jù)準(zhǔn)確性的機制。

所以，如果想提升寫入速度的話，要么做分庫分表，要么就是通過緩存來進行一道緩沖，再一次性批量寫到磁盤，以此來提速。

題外話：由于分庫分表對跨表操作以及多條件組合查詢的副作用巨大，所以引入它的復(fù)雜度遠大于引入緩存，我們應(yīng)當(dāng)優(yōu)先考慮引入緩存的方案。

那么，通過緩存機制來加速“寫”的過程就可以稱作「延遲寫」。就是預(yù)先將需要寫入到磁盤或者數(shù)據(jù)庫的數(shù)據(jù)，先暫時寫入到內(nèi)存，然后就返回成功。再定時將內(nèi)存中的數(shù)據(jù)批量寫入到磁盤。

可能你會想，寫到內(nèi)存就認(rèn)為成功，萬一中途出現(xiàn)意外、斷電、停機等導(dǎo)致程序異常終止的情況，數(shù)據(jù)不就丟了嗎？

是的。所以，「延遲寫」一般僅用于對數(shù)據(jù)完整性要求不是那么苛刻的場景。比如點贊數(shù)啊、參與用戶數(shù)啊等等，可以大大緩解對數(shù)據(jù)庫頻繁修改所帶來的壓力。

其實在我們熟知的分布式緩存Redis中，其默認(rèn)運用的持久化機制——RDB，也是這樣的思路。

在一個成熟的系統(tǒng)中，能夠運用到緩存的地方其實并不是一處。下面Z哥就來幫你梳理一下我們在哪些地方可以“加緩存”。

哪里可以加「緩存」？

在說哪里可以加緩存之前我們先搞清楚一個事情，我們要緩存什么？也就是符合什么特點的數(shù)據(jù)才需要加緩存？畢竟加緩存是一個額外的成本投入，得物有所值。

一般來說你可以用這兩個標(biāo)準(zhǔn)來判斷：熱點（被高頻訪問，如幾十次/秒以上）數(shù)據(jù)、靜態(tài)（很少變化，讀遠大于寫，如幾天變更一次）數(shù)據(jù)。

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

緩存的本質(zhì)是一個“防御性”的機制，而系統(tǒng)之間的數(shù)據(jù)流轉(zhuǎn)是一個有序的過程。所以，選擇在哪里加緩存就相當(dāng)于選擇在一條馬路的哪個位置設(shè)路障。在這個路障之后的道路都能受到保護，不被車流碾壓。

那么在以終端用戶為起點，系統(tǒng)所用的數(shù)據(jù)庫為終點的這條道路上可以作為緩存設(shè)立點的位置大致有以下這些。

每個設(shè)立點可以擋掉一些流量，最終形成一個漏斗狀的攔截效果，以此保護最后面的系統(tǒng)以及最終的數(shù)據(jù)庫。

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

瀏覽器緩存

這是離用戶最近的可以作為緩存的地方，而且借助的是用戶的“資源”（緩存的數(shù)據(jù)在用戶的終端設(shè)備上），性價比可謂最好，讓用戶幫你分擔(dān)壓力。

當(dāng)你打開瀏覽器的開發(fā)者工具，看到from cache或者from memory cache、from disk cache的時候，就意味著這些數(shù)據(jù)已經(jīng)被緩存在了用戶的終端設(shè)備上了（沒網(wǎng)的時候也能訪問到一部分內(nèi)容就是這個原因）。

這個過程是瀏覽器替我們完成的，一般用于緩存圖片、js、css這些。我們可以通過Http消息頭中的Cache-Control來控制它，具體細節(jié)這里就不展開了。

js里的全局變量、以及cookie等運用也屬于該范疇。

瀏覽器緩存是在于用戶側(cè)的緩存點，所以我們對其的掌控力就差很多，在沒有發(fā)起新請求的情況下，你無法主動去更新數(shù)據(jù)。

CDN緩存

提供CDN服務(wù)的服務(wù)商，在全國甚至是全球部署著大量的服務(wù)器節(jié)點（可以叫做「邊緣服務(wù)器」）。

那么將數(shù)據(jù)分發(fā)到這些遍布各地服務(wù)器上作為緩存，讓用戶訪問就近的服務(wù)器上的緩存數(shù)據(jù)，就可以起到壓力分?jǐn)偤图铀傩Ч?。這在ToC類型的系統(tǒng)上運用，效果格外顯著。

但是需要注意的是，由于節(jié)點眾多，更新緩存數(shù)據(jù)比較緩慢，一般至少是分鐘級別。所以一般僅適用于不經(jīng)常變動的靜態(tài)數(shù)據(jù)。

題外話：解決方式也是有的，就是在url后面帶個自增數(shù)或者唯一標(biāo)示，如?v=1001。因為不同的url會被視作“新”的數(shù)據(jù)和文件，被重新create出來。

網(wǎng)關(guān)（代理）緩存

到這里做緩存就是在你自己的地盤了。很多時候我們會在源站前面架一層網(wǎng)關(guān)（或者說反向代理、正向代理），為的是做一些安全機制或者統(tǒng)一分流策略的入口。

同時這里也是做緩存的一個好場所。畢竟網(wǎng)關(guān)是“業(yè)務(wù)無關(guān)性”的，它能夠攔下來的請求，對背后的源站也是很大的受益，減少了大量的CPU運算。

常用的網(wǎng)關(guān)（代理）緩存有Varnish，Squid，Ngnix。一般情況下，簡單的緩存運用場景，用nginx即可，因為大部分時候我們會用它來做負載均衡，能少引入一個技術(shù)就少一份復(fù)雜度嘛。如果是大量的小文件可以使用Varnish，而Squid則相對大而全，運用成本也更高一些。

進程內(nèi)緩存

一個請求能走到這里說明他是“業(yè)務(wù)相關(guān)”的，需要經(jīng)過業(yè)務(wù)邏輯的運算。

也正因為如此，從這里開始對緩存的引入成本比前面3種大大增加，因為對緩存與數(shù)據(jù)庫之間的「數(shù)據(jù)一致性」要求更高了。

可能我們大多數(shù)程序員第一次刻意使用緩存的場景就是這個時候。進程內(nèi)和進程外的緩存運用中有很多的細節(jié)需要注意，這些也是我們后續(xù)文章的內(nèi)容，所以我們后續(xù)再詳聊。

進程外緩存

這個大家也熟悉，就是redis、memcached之類，甚至也可以自己單獨寫一個程序來專門存放緩存數(shù)據(jù)，供其他程序遠程調(diào)用。

同樣，這里的細節(jié)我們后續(xù)再聊，這里先多說幾句關(guān)于redis和memcached該怎么選擇的建議。

對資源（cpu、內(nèi)存等）利用率格外重視的話可以使用Memcached，但程序在使用的時候需要容忍可能發(fā)生的數(shù)據(jù)丟失，因為是純內(nèi)存的機制。如果無法容忍這點，并且對資源利用率也比較豪放的話可以使用redis。而且redis的數(shù)據(jù)庫結(jié)構(gòu)更多，Memcached只有key value，更像是一個nosql存儲。

數(shù)據(jù)庫緩存

數(shù)據(jù)庫本身自帶緩存模塊的，否則也不會叫它內(nèi)存殺手，基本上你給多少內(nèi)存就能吃多少。

數(shù)據(jù)庫緩存是數(shù)據(jù)庫的內(nèi)部機制，我們這里就不深入下去了。一般都會給出設(shè)置緩存空間大小的配置來讓你進行干預(yù)。

最后，其實磁盤本身也有緩存。所以你會發(fā)現(xiàn)，為了讓數(shù)據(jù)能夠平穩(wěn)的寫到物理磁盤中真的是一波三折，不知道什么時候可以有“快”到不需要程序來考慮緩存的磁盤出現(xiàn)來拯救我們程序員呢。

「緩存」是Silver bullet嗎？

可能你會想緩存那么好，那么應(yīng)該×××，只要慢就上緩存來解決？

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

1. 緩存雪崩

2. 緩存穿透

3. 緩存并發(fā)

4. 緩存無底洞

5. 緩存淘汰

6. ...

等等問題，這些Z哥會在接下去的文章中和你一起深入剖析。

想第一時間了解這些的可以「關(guān)注」Z哥一波～

總結(jié)

好了，我們總結(jié)一下。

這次呢，Z哥先向你介紹了運用緩存的三種思路。

然后梳理了在一個完整的系統(tǒng)中可以設(shè)立緩存的幾個位置，并且分享了關(guān)于瀏覽器緩存、CDN緩存、網(wǎng)關(guān)（代理）緩存的一些使用經(jīng)驗。

希望對你有所啟發(fā)。

后續(xù)的文章我將著重深入「進程內(nèi)緩存」和「進程外緩存」的最佳實踐，等我再次出現(xiàn)。

---

相關(guān)文章：

• 分布式系統(tǒng)關(guān)注點——僅需這一篇，吃透「負載均衡」妥妥的

• 分布式系統(tǒng)關(guān)注點——如何去實施「負載均衡」？

• 分布式系統(tǒng)關(guān)注點——做了「負載均衡」就可以隨便加機器了嗎？

• 分布式系統(tǒng)關(guān)注點——「無狀態(tài)」詳解

• 分布式系統(tǒng)關(guān)注點——「高內(nèi)聚低耦合」詳解

• 分布式系統(tǒng)關(guān)注點——彈性架構(gòu)

---

作者：Zachary

出處：https://www.cnblogs.com/Zachary-Fan/p/cache.html

如果你喜歡這篇文章，可以點一下左下角的「大拇指」。

這樣可以給我一點反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。

定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計丨分布式系統(tǒng)丨產(chǎn)品丨運營丨一些思考。

如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長期收集和整理的思維導(dǎo)圖。

如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「運營」，送你一份我長期收集和整理的思維導(dǎo)圖。

網(wǎng)站題目：分布式系統(tǒng)關(guān)注點——360°全方位解讀「緩存」-創(chuàng)新互聯(lián)
新聞來源：http://aaarwkj.com/article4/dpjgoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、網(wǎng)站改版、網(wǎng)站建設(shè)、云服務(wù)器、網(wǎng)站導(dǎo)航、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)