快取的種類

這是離使用者最近的可以作為快取的地方，而且借助的是使用者的「資源」（快取的資料在使用者的終端裝置上），價效比可謂最好，讓使用者幫你分擔壓力!

當你開啟瀏覽器的開發者工具，看到from cache或者from memory cache、from disk cache的時候，就意味著這些資料已經被快取在了使用者的終端裝置上了（沒網的時候也能訪問到一部分內容就是這個原因）。

這個過程是瀏覽器替我們完成的，一般用於快取、js、css這些。我們可以通過http訊息頭中的cache-control來控制它，具體細節這裡就不展開了。

js裡的全域性變數、以及cookie等運用也屬於該範疇。

瀏覽器快取是在於使用者側的快取點，所以我們對其的掌控力就差很多，在沒有發起新請求的情況下，你無法主動去更新資料。

提供cdn服務的服務商，在全國甚至是全球部署著大量的伺服器節點（可以叫做「邊緣伺服器」）。

那麼將資料分發到這些遍布各地伺服器上作為快取，讓使用者訪問就近的伺服器上的快取資料，就可以起到分攤和假宿效果。

但是需要注意，由於節點眾多，更新快取資料比較緩慢，一般至少是分鐘級別。所以一般僅適用於不經常變動的靜態資料。

解決方式也是有的，就是在url後面帶個自增數或者唯一標示，如?v=1001。因為不同的url會被視作「新」的資料和檔案，被重新create出來。

到這裡做快取就是在你自己的地盤.很多時候我們會在源站前面架一層閘道器(或者說反向**,正向**),為的是做一些安全機制或者統一分流策略的入口.

同時這裡也是做快取的乙個好場所。畢竟閘道器是「業務無關性」的，它能夠攔下來的請求，對背後的源站也是很大的受益，減少了大量的cpu運算。

常用的閘道器（**）快取有varnish，squid，ngnix。一般情況下，簡單的快取運用場景，用nginx即可，因為大部分時候我們會用它來做負載均衡，能少引入乙個技術就少乙份複雜度嘛。如果是大量的小檔案可以使用varnish，而squid則相對大而全，運用成本也更高一些。

乙個請求能走到這裡說明他是和"業務相關"的,需要經過業務邏輯運算.

也正因為如此,從這裡開始對快取的引入成本比前面三種大大增加.因為對快取與資料庫之間的"資料一致性"要求更高.

技術redis之類的,甚至也可以自己單獨寫乙個程式來專門存放快取資料,供其他程式遠端呼叫.

資料庫本身自帶快取模組的,基本上你給多少記憶體它就吃多少記憶體.