所有程式猿都對那快取并不陌生，好似那風一樣的女子只為你獨自而舞，只見那回眸一笑百媚生，讓你甚是吝惜，惹人憐愛，

但隨著專案規模不斷增大變強，光是單個快取就難以招架，優而顯得力不從心，

這時伴隨著多級快取得化繭成蝶，平臺級快取和分布式快取在應用上就都相輔相成，

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

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

本篇我將已老生常談的態度來為大家一一揭曉，同時掌握方案與場景，設計技術選型的原理，包括一線大廠在本章節可能涉及的常考點，

何為平臺級快取與分布式快取？

平臺級快取是指你所選擇編程語言下的快取技術型別，

它是在語言的前提條件下，來采用的快取技術，也就是你用什么語言，就采用它存在的快取技術，

快取是工具，供編程語言呼叫，前者為后者服務，得有一個主次的關系，
所以有時 你要控制你自己呀，別給自己飆車的速度，不然翻車了你都不知道

比如：
你在淘寶開了個新店鋪，這時你需要對你的店鋪進行裝飾打扮，那就需要使用淘寶這個平臺上提供的功能來進行裝飾，
像上傳商品配圖、店鋪布局風格等，
換句話說平臺級快取是依附于平臺的特性而決定的，

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

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

而且按照應用層的定義來看，平臺級快取可根據行程執行使用的方式劃分為行程內快取和行程外快取，

那什么是行程內、行程外快取呢？

• 行程內快取

就是快取資料存在于所屬應用行程之內，和應用業務代碼、變數、堆疊等型別共同享受應用行程的記憶體資源， 快取就是在行程內中的資料段進行站位，

或者說原來你1人住1房間，現在你和別人一起住，

• 行程外快取

指快取資料存盤的地方不在使用應用內，而是外部的其它行程來存盤，比如像：Redis、memcache之類，

那如果快取以檔案形式保持咋辦呀？ 也算應用行程外？
放心，我乃吒吒輝，而不是渣渣輝，呸，渣男

因大多數快取都是在記憶體里面來進行操作，所以常常會忽視以檔案形式來保存的資料檔案，像這種情況它還是平臺級快取下的行程內快取，不是行程外快取，

因為這個檔案的快取是服務于應用行程，而你像Redis那種角色，它是獨立的行程，行程和行程本身是有隔離的，而且它們還是不同軟體的行程，就更沒得啥關系，

而且檔案快取里面的內容都是提前把邏輯處理的資料存入進取，當使用時，就可以減少重復的讀取、計算資料的動作從而來達到快取的效果，

那如果我把Redis獨立部署到其它服務器里面，也是行程外快取嗎？

這樣的情況它就是了，上面提到行程外快取是相對應用行程而言的，現在它們存在于不同的服務器，如果是在同一臺服務器里面部署，那也算行程外快取，因為行程是隔離的，但一般Redis部署到其它服務器我們不會這樣稱呼

那它這叫啥呢？

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

分布式快取也很好理解，首先看分布式，它表示把不同的軟體分別部署在不同的服務器上或者同一服務器上不同的軟體服務，

注：這里【分布式快取】是個相對概念，如果按分布式概念看，一臺服務器上部署了PHP|JAVA和Redis，它們之間的關系也算分布式，
但我們現在是從行程內外快取的概念劃分，這樣一看，它就不屬于分布式快取了，大家知道統一的說法即可

哎呀，累死個人，吒男能這樣，面面俱到？有點繞，你老慢著點，細細品味

為何使用平臺級與分布式快取？

無論什么型別的快取，使用它們的根本目標就是減少資料的邏輯運算，加快請求回應，進而提高網站的QPS， 只不過體現的地方是不一樣的罷了，

那平臺級和分布式快取都有神馬好處？

平臺級

優點：

• 時延更低，能夠節省內網帶寬

平臺級快取，由于資料不需要跨網路傳輸，直接在本地記憶體中操作，故性能好，時延低，消耗的帶寬也較少，

• 不需要引入第三方類別庫，開箱即用

一般平臺級快取，都會有官方提供的相關操作類別庫，并不需要引入第三方的類別庫，降低了業務開發的關聯，

缺點：

• 存盤容量有限，無法進行大資料存盤

由于記憶體占用了應用行程的記憶體空間，如 Java 行程的 JVM 記憶體空間，故不能進行大資料量的資料存盤，

• 微服務架構中，集群部署資料的更新問題，

平臺快取資料存盤于應用行程內，故無法被其他應用行程訪問，在集群部署中同一快取資料需要部署多份，

如果對應資料庫的資料，存在更新動作，則需要同步更新到不同部署節點的本地快取，這樣才能保證資料一致性，這時復雜度較高并且容易出錯，

可以采用如基于 Redis 的發布訂閱機制來同步更新各個部署節點或者中間件進行異步資料更新，

• 資料隨應用行程的重啟或崩潰而丟失

平臺快取資料是存盤在應用行程的記憶體空間，所以當應用行程重啟時，快取資料也會丟失，所以對于需要持久化的資料，要注意及時保存，否則可能會造成資料丟失，

分布式快取

優點：

• 性能、存盤容量無上限，理論上可做到無限擴充

雖然本地快取快，但終究在單機上，資源性能都有上限，

而分布式快取是獨立部署的行程，自身擁有獨立的記憶體空間，不會受到應用行程重啟的影響，同時硬體資源也是獨享，

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

• 資料集中存盤，保證資料一致性，也做到了業務上的解耦

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

這樣所有的快取資料都維護在快取集群當中，故不存在像本地快取資料更新的問題，也保證了不同節點應用行程的資料一致性問題，

以前快取和業務是在一起使用，現在業務和快取剝離開來，互不影響，從而做到了業務上的拆分，

• 資料從業務上做讀寫分離，保證網站高性能，高可用

分布式快取一般支持資料副本機制，從業務上課實作讀寫分離，故可以解決高并發場景中并發讀寫性能問題，

由于在多個快取節點也冗余了資料，提高了快取資料的可用性，避免某個快取節點宕機導致資料不可用問題，

那什么是讀寫分離？

讀寫分離是指把網站中用戶請求，按照讀、寫請求進行劃分，常常需要配合MySQL主從，主庫針對用戶寫請求，從庫針對用戶讀請求，

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

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

畢竟索引維護也是需要消耗資源的，誰讓咋的心眼兒細呢？不小心看到了

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

這個，其實這里小吒只是拋轉引玉了下，但大致意思都差不多，根本就是把讀寫請求分開，然后進行專治，

又比如：針對網站架構時，也可以采用讀寫分離的機制來部署網站子系統，針對搜索的業務，可以完全獨立部署search_product.com，由它來提供搜索頁面，

再來比如：針對要提高業務的處理能力，咱們快取的主從架構照樣可配合讀寫分離，加速網站的處理，

還來比如：針對訪問量過高，可以通過讀寫佇列來進行流量消費和異步批量寫機制，來提高網站的處理能力和寫負載過高等問題，
等等還有其它的，但大家要明白讀寫分離的作用，而且有時候它還會配合業務進行調整的，

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

缺點：

• 運維和部署上成本高

由于是分布式部署方式，部署、運維起來還是比較有技術難度，因為每臺服務器的運行情況你肯定都要知道，外加線上環境的不確定因素，直接頭大

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

• 技術結構復雜，需要考慮快取雪崩、擊穿等問題

分布式快取中的資料量肯定不少，對業務方來說需要，考慮快取的擊穿、雪崩、穿透等問題，防止意外情況下請求直接打到資料庫造成資料庫崩潰的問題，

• 資料跨網路傳輸，性能低于本地快取

分布式快取部署一般都是與應用行程位于不同的機器，故需要通過外網來進行網路資料傳輸，相對于平臺快取的行程內部資料讀取操作，性能會較低，

平臺級與分布式快取的技術選項？

每個技術都會有自己的立場，在什么情況來選擇用什么樣的技術內容，還是得根據你專案需求情況來進行選擇

• 看速度？選平臺級快取

平臺快取的優勢就是處于應用行程內部，離程式是最近的，如果某部分資料不大，但是訪問量比較高，直接使用它來做處理， 簡直是省心有省力氣，在加上AOP切面編程，簡直舒服的不要不要的，

例如：

如果想首頁、活動頁里面的展示一些統計或推薦的資訊，有了它就不用每次都去呼叫相同API來進行運算操作，只要記得定時更新平臺快取即可，

• 看資料量？選分布式快取

平臺快取受限于應用行程方，存盤有限，在大流量、海量資料的規模情況下，肯定選擇分布式快取，基于水平擴容、讀寫分離來滿足業務場景、資料存盤、性能需求等，

• 綜合來看，有規模選分布式快取，規模一般選擇行程外快取，規模小你老看著辦？

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

那選擇平臺級快取有何問題？

• 如果多機器采用平臺快取，那快取就有多份，一旦資料變更，就需要通知到多個上游服務方來更新資料，
• 微服務模式下，一個頁面模塊的展示資料，在呼叫一個服務時可能需要拿到多個服務的資料聚合之后，才能最后回傳給客戶端展示，

這樣一個服務的資料發生變化就需要通知到剛開始調的服務來更新快取，業務上就耦合起來，而且還加入了很多附加作業，嚴重影響性能，

• 資料的一致性問題，一個服務更新，如果網路有延遲或意外，導致更新的請求失敗，那么資料庫和快取的資料就存在不一致，

總結

• 網站規模建議采用分布式快取，因為業務方和快取就不需要在業務上耦合，后期架構調整和維護都比較輕松，

• 場景上選什么還是得根據業務需求和架構設計來綜合考慮，個人不大推薦平臺快取，業務職責更加清晰些，可能更好些，

思考題

1. 什么是分布式快取？你用什么來做？什么條件下使用它？
2. 平臺級快取你常用哪種？平臺級和分布式快取存在什么優缺點？
3. 平臺級和分布式分別適合什么場景？
4. 什么是讀寫分離？你有那些應用

如果感覺文章有幫助的話，求再看、求關注、求分享、求留言，各位的點贊支持，都是我創作的最大動力，

其實還有很多優化、架構等東西未分享，怕偏提，那咱們下期見，同時為了更好的幫助大家，我也整理了如下內容：

需要的小伙伴可微信搜索【蓮花童子哪吒】，這些其實還需要大家一起與我不斷完善，畢竟我個人是有限的，期待你的留言補充