所有程序猿都對那緩存并不陌生，好似那風(fēng)一樣的女子只為你獨(dú)自而舞。只見那回眸一笑百媚生，讓你甚是吝惜，惹人憐愛。

但隨著項(xiàng)目規(guī)模不斷增大變強(qiáng)，光是單個(gè)緩存就難以招架，優(yōu)而顯得力不從心。

這時(shí)伴隨著多級緩存得化繭成蝶，平臺級緩存和分布式緩存在應(yīng)用上就都相輔相成。

但一山難容二虎，往往存有3大問題——①概念難以區(qū)分②我到底應(yīng)該選擇誰③各自適用于什么場景。

如果這個(gè)沒弄明白，我怕是覺得你還不大行額。

本篇我將已老生常談的態(tài)度來為大家一一揭曉，同時(shí)掌握方案與場景，設(shè)計(jì)技術(shù)選型的原理。包括一線大廠在本章節(jié)可能涉及的?？键c(diǎn)。

何為平臺級緩存與分布式緩存？

平臺級緩存是指你所選擇編程語言下的緩存技術(shù)類型。

它是在語言的前提條件下，來采用的緩存技術(shù)，也就是你用什么語言，就采用它存在的緩存技術(shù)。

緩存是工具，供編程語言調(diào)用。前者為后者服務(wù)，得有一個(gè)主次的關(guān)系。
所以有時(shí) 你要控制你自己呀，別給自己飆車的速度，不然翻車了你都不知道

比如：
你在淘寶開了個(gè)新店鋪，這時(shí)你需要對你的店鋪進(jìn)行裝飾打扮，那就需要使用淘寶這個(gè)平臺上提供的功能來進(jìn)行裝飾。
像上傳商品配圖、店鋪布局風(fēng)格等。
換句話說平臺級緩存是依附于平臺的特性而決定的。

上篇也提到在不同的編程語言下，平臺級緩存也不相同，比如：

• PHP里面Smarty模板庫
• Java中如Ehcache，Cacheonix，Voldemort，JBoss Cache，OSCache等等。

而且按照應(yīng)用層的定義來看，平臺級緩存可根據(jù)進(jìn)程執(zhí)行使用的方式劃分為進(jìn)程內(nèi)緩存和進(jìn)程外緩存。

那什么是進(jìn)程內(nèi)、進(jìn)程外緩存呢？

• 進(jìn)程內(nèi)緩存

就是緩存數(shù)據(jù)存在于所屬應(yīng)用進(jìn)程之內(nèi)，和應(yīng)用業(yè)務(wù)代碼、變量、堆棧等類型共同享受應(yīng)用進(jìn)程的內(nèi)存資源。 緩存就是在進(jìn)程內(nèi)中的數(shù)據(jù)段進(jìn)行站位。

或者說原來你1人住1房間，現(xiàn)在你和別人一起住。

• 進(jìn)程外緩存

指緩存數(shù)據(jù)存儲的地方不在使用應(yīng)用內(nèi)，而是外部的其它進(jìn)程來存儲。比如像：Redis、memcache之類。

那如果緩存以文件形式保持咋辦呀？也算應(yīng)用進(jìn)程外？
放心，我乃吒吒輝，而不是渣渣輝。呸，渣男

因大多數(shù)緩存都是在內(nèi)存里面來進(jìn)行操作，所以常常會忽視以文件形式來保存的數(shù)據(jù)文件。像這種情況它還是平臺級緩存下的進(jìn)程內(nèi)緩存，不是進(jìn)程外緩存。

因?yàn)檫@個(gè)文件的緩存是服務(wù)于應(yīng)用進(jìn)程，而你像Redis那種角色，它是獨(dú)立的進(jìn)程，進(jìn)程和進(jìn)程本身是有隔離的，而且它們還是不同軟件的進(jìn)程，就更沒得啥關(guān)系。

而且文件緩存里面的內(nèi)容都是提前把邏輯處理的數(shù)據(jù)存入進(jìn)取。當(dāng)使用時(shí)，就可以減少重復(fù)的讀取、計(jì)算數(shù)據(jù)的動作從而來達(dá)到緩存的效果。

那如果我把Redis獨(dú)立部署到其它服務(wù)器里面，也是進(jìn)程外緩存嗎？

這樣的情況它就是了，上面提到進(jìn)程外緩存是相對應(yīng)用進(jìn)程而言的，現(xiàn)在它們存在于不同的服務(wù)器。如果是在同一臺服務(wù)器里面部署。那也算進(jìn)程外緩存，因?yàn)檫M(jìn)程是隔離的，但一般Redis部署到其它服務(wù)器我們不會這樣稱呼

那它這叫啥呢？

這種情況稱分布式緩存，常說的分布式緩存就是這種形式存在于世。

分布式緩存也很好理解，首先看分布式，它表示把不同的軟件分別部署在不同的服務(wù)器上或者同一服務(wù)器上不同的軟件服務(wù)。

注：這里【分布式緩存】是個(gè)相對概念，如果按分布式概念看，一臺服務(wù)器上部署了PHP|JAVA和Redis。它們之間的關(guān)系也算分布式。
但我們現(xiàn)在是從進(jìn)程內(nèi)外緩存的概念劃分。這樣一看，它就不屬于分布式緩存了。大家知道統(tǒng)一的說法即可

哎呀，累死個(gè)人，吒男能這樣，面面俱到？有點(diǎn)繞，你老慢著點(diǎn)，細(xì)細(xì)品味

為何使用平臺級與分布式緩存？

無論什么類型的緩存，使用它們的根本目標(biāo)就是減少數(shù)據(jù)的邏輯運(yùn)算，加快請求響應(yīng)，進(jìn)而提高網(wǎng)站的QPS。只不過體現(xiàn)的地方是不一樣的罷了。

那平臺級和分布式緩存都有神馬好處？

平臺級

優(yōu)點(diǎn)：

1. 時(shí)延更低，能夠節(jié)省內(nèi)網(wǎng)帶寬

平臺級緩存，由于數(shù)據(jù)不需要跨網(wǎng)絡(luò)傳輸，直接在本地內(nèi)存中操作。故性能好，時(shí)延低，消耗的帶寬也較少。

1. 不需要引入第三方類庫，開箱即用

一般平臺級緩存，都會有官方提供的相關(guān)操作類庫，并不需要引入第三方的類庫，降低了業(yè)務(wù)開發(fā)的關(guān)聯(lián)。

缺點(diǎn)：

1. 存儲容量有限，無法進(jìn)行大數(shù)據(jù)存儲

由于內(nèi)存占用了應(yīng)用進(jìn)程的內(nèi)存空間，如 Java 進(jìn)程的 JVM 內(nèi)存空間，故不能進(jìn)行大數(shù)據(jù)量的數(shù)據(jù)存儲。

1. 微服務(wù)架構(gòu)中，集群部署數(shù)據(jù)的更新問題。

平臺緩存數(shù)據(jù)存儲于應(yīng)用進(jìn)程內(nèi)，故無法被其他應(yīng)用進(jìn)程訪問，在集群部署中同一緩存數(shù)據(jù)需要部署多份。

如果對應(yīng)數(shù)據(jù)庫的數(shù)據(jù)，存在更新動作，則需要同步更新到不同部署節(jié)點(diǎn)的本地緩存，這樣才能保證數(shù)據(jù)一致性。這時(shí)復(fù)雜度較高并且容易出錯(cuò)。

可以采用如基于 Redis 的發(fā)布訂閱機(jī)制來同步更新各個(gè)部署節(jié)點(diǎn)或者中間件進(jìn)行異步數(shù)據(jù)更新。

1. 數(shù)據(jù)隨應(yīng)用進(jìn)程的重啟或崩潰而丟失

平臺緩存數(shù)據(jù)是存儲在應(yīng)用進(jìn)程的內(nèi)存空間，所以當(dāng)應(yīng)用進(jìn)程重啟時(shí)，緩存數(shù)據(jù)也會丟失。所以對于需要持久化的數(shù)據(jù)，要注意及時(shí)保存，否則可能會造成數(shù)據(jù)丟失。

分布式緩存

優(yōu)點(diǎn)：

1. 性能、存儲容量無上限，理論上可做到無限擴(kuò)充

雖然本地緩存快，但終究在單機(jī)上，資源性能都有上限。

而分布式緩存是獨(dú)立部署的進(jìn)程，自身擁有獨(dú)立的內(nèi)存空間，不會受到應(yīng)用進(jìn)程重啟的影響，同時(shí)硬件資源也是獨(dú)享。

如果一臺機(jī)器性能不夠，就可以采用集群的方式拓展，做到線性的擴(kuò)容。在配合docker容器，瞬間 beautiful

1. 數(shù)據(jù)集中存儲，保證數(shù)據(jù)一致性，也做到了業(yè)務(wù)上的解耦

雖然緩存是以分布式的方式存儲，但部署模式會采用集群來保證高可用。

這樣所有的緩存數(shù)據(jù)都維護(hù)在緩存集群當(dāng)中，故不存在像本地緩存數(shù)據(jù)更新的問題，也保證了不同節(jié)點(diǎn)應(yīng)用進(jìn)程的數(shù)據(jù)一致性問題。

以前緩存和業(yè)務(wù)是在一起使用，現(xiàn)在業(yè)務(wù)和緩存剝離開來，互不影響，從而做到了業(yè)務(wù)上的拆分。

1. 數(shù)據(jù)從業(yè)務(wù)上做讀寫分離，保證網(wǎng)站高性能，高可用

分布式緩存一般支持?jǐn)?shù)據(jù)副本機(jī)制，從業(yè)務(wù)上課實(shí)現(xiàn)讀寫分離，故可以解決高并發(fā)場景中并發(fā)讀寫性能問題。

由于在多個(gè)緩存節(jié)點(diǎn)也冗余了數(shù)據(jù)，提高了緩存數(shù)據(jù)的可用性，避免某個(gè)緩存節(jié)點(diǎn)宕機(jī)導(dǎo)致數(shù)據(jù)不可用問題。

那什么是讀寫分離？

讀寫分離是指把網(wǎng)站中用戶請求，按照讀、寫請求進(jìn)行劃分。常常需要配合MySQL主從，主庫針對用戶寫請求，從庫針對用戶讀請求。

如果不做讀寫分離那么請求都會走一臺機(jī)器。所以讀寫分離在一定程度上也做到了負(fù)載均衡，還可以針對單一類型的請求來做到專治。

比如：主庫針對寫請求，那可以省去索引的創(chuàng)建，而從庫針對讀請求，需要索引來處理。這樣就可以根據(jù)請求類型來選擇是否使用索引。

畢竟索引維護(hù)也是需要消耗資源的。誰讓咋的心眼兒細(xì)呢？不小心看到了

原來讀寫分離就是這樣的啊，那我知道了

這個(gè)，其實(shí)這里小吒只是拋轉(zhuǎn)引玉了下，但大致意思都差不多，根本就是把讀寫請求分開，然后進(jìn)行專治。

又比如：針對網(wǎng)站架構(gòu)時(shí)，也可以采用讀寫分離的機(jī)制來部署網(wǎng)站子系統(tǒng)，針對搜索的業(yè)務(wù)，可以完全獨(dú)立部署search_product.com。由它來提供搜索頁面。

再來比如：針對要提高業(yè)務(wù)的處理能力，咱們緩存的主從架構(gòu)照樣可配合讀寫分離，加速網(wǎng)站的處理。

還來比如：針對訪問量過高，可以通過讀寫隊(duì)列來進(jìn)行流量消費(fèi)和異步批量寫機(jī)制，來提高網(wǎng)站的處理能力和寫負(fù)載過高等問題。
等等還有其它的，但大家要明白讀寫分離的作用，而且有時(shí)候它還會配合業(yè)務(wù)進(jìn)行調(diào)整的。

你TM吒吒輝有完沒完了，一口氣說完不行了，我這個(gè)暴脾氣給你慣得。

缺點(diǎn)：

1. 運(yùn)維和部署上成本高

由于是分布式部署方式，部署、運(yùn)維起來還是比較有技術(shù)難度，因?yàn)槊颗_服務(wù)器的運(yùn)行情況你肯定都要知道，外加線上環(huán)境的不確定因素。直接頭大

但方案能抗住大流量，方案還是可取，同時(shí)基于Docker在部署上也會減輕很多壓力。 橫豎你都占一樣嘛，不然咋個(gè)辦呢？

1. 技術(shù)結(jié)構(gòu)復(fù)雜，需要考慮緩存雪崩、擊穿等問題

分布式緩存中的數(shù)據(jù)量肯定不少，對業(yè)務(wù)方來說需要，考慮緩存的擊穿、雪崩、穿透等問題，防止意外情況下請求直接打到數(shù)據(jù)庫造成數(shù)據(jù)庫崩潰的問題。

1. 數(shù)據(jù)跨網(wǎng)絡(luò)傳輸，性能低于本地緩存

分布式緩存部署一般都是與應(yīng)用進(jìn)程位于不同的機(jī)器，故需要通過外網(wǎng)來進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸，相對于平臺緩存的進(jìn)程內(nèi)部數(shù)據(jù)讀取操作，性能會較低。

平臺級與分布式緩存的技術(shù)選項(xiàng)？

每個(gè)技術(shù)都會有自己的立場，在什么情況來選擇用什么樣的技術(shù)內(nèi)容。還是得根據(jù)你項(xiàng)目需求情況來進(jìn)行選擇

1. 看速度？選平臺級緩存

平臺緩存的優(yōu)勢就是處于應(yīng)用進(jìn)程內(nèi)部，離程序是最近的。如果某部分?jǐn)?shù)據(jù)不大，但是訪問量比較高，直接使用它來做處理。簡直是省心有省力氣，在加上AOP切面編程，簡直舒服的不要不要的。

例如：

如果想首頁、活動頁里面的展示一些統(tǒng)計(jì)或推薦的信息。有了它就不用每次都去調(diào)用相同API來進(jìn)行運(yùn)算操作，只要記得定時(shí)更新平臺緩存即可。

1. 看數(shù)據(jù)量？選分布式緩存

平臺緩存受限于應(yīng)用進(jìn)程方，存儲有限，在大流量、海量數(shù)據(jù)的規(guī)模情況下，肯定選擇分布式緩存，基于水平擴(kuò)容、讀寫分離來滿足業(yè)務(wù)場景、數(shù)據(jù)存儲、性能需求等。

1. 綜合來看，有規(guī)模選分布式緩存，規(guī)模一般選擇進(jìn)程外緩存。規(guī)模小你老看著辦？

網(wǎng)站上到大規(guī)模，你分布式那都跑不脫。
為了滿足高可用、高可靠機(jī)制，一般都會采用分布式集群的方式部署，這樣一個(gè)業(yè)務(wù)，會有多臺機(jī)器來提供服務(wù)，就算掛了一個(gè)主機(jī)，還有其它的頂上來。

那選擇平臺級緩存有何問題？

• 如果多機(jī)器采用平臺緩存，那緩存就有多份，一旦數(shù)據(jù)變更，就需要通知到多個(gè)上游服務(wù)方來更新數(shù)據(jù)。
• 微服務(wù)模式下，一個(gè)頁面模塊的展示數(shù)據(jù)，在調(diào)用一個(gè)服務(wù)時(shí)可能需要拿到多個(gè)服務(wù)的數(shù)據(jù)聚合之后，才能最后返回給客戶端展示。

這樣一個(gè)服務(wù)的數(shù)據(jù)發(fā)生變化就需要通知到剛開始調(diào)的服務(wù)來更新緩存，業(yè)務(wù)上就耦合起來，而且還加入了很多附加工作，嚴(yán)重影響性能。

• 數(shù)據(jù)的一致性問題，一個(gè)服務(wù)更新，如果網(wǎng)絡(luò)有延遲或意外，導(dǎo)致更新的請求失敗，那么數(shù)據(jù)庫和緩存的數(shù)據(jù)就存在不一致。

總結(jié)

• 網(wǎng)站規(guī)模建議采用分布式緩存，因?yàn)闃I(yè)務(wù)方和緩存就不需要在業(yè)務(wù)上耦合，后期架構(gòu)調(diào)整和維護(hù)都比較輕松。

• 場景上選什么還是得根據(jù)業(yè)務(wù)需求和架構(gòu)設(shè)計(jì)來綜合考慮，個(gè)人不大推薦平臺緩存，業(yè)務(wù)職責(zé)更加清晰些，可能更好些。