不同的場景下如何選擇和使用適用的緩存框架
,講述在不同的場景下如何選擇和使用適用的緩存框架,以達到提升服務質(zhì)量,優(yōu)化系統(tǒng)架構(gòu)的目的。
一般而言,現(xiàn)在互聯(lián)網(wǎng)模式(一個網(wǎng)站或一個應用),整體流程可以概括描述為 瀏覽器→應用服務器→數(shù)據(jù)庫或文件(存儲)→應用服務器→瀏覽器,這是一個標準流程,通過瀏覽器(或App界面)發(fā)起請求,經(jīng)過服務器、數(shù)據(jù)庫計算整合后反饋瀏覽器呈現(xiàn)內(nèi)容。隨著互聯(lián)網(wǎng)的普及,內(nèi)容信息越來越復雜,使用者和訪問量越來越大,我們的應用需要支撐更多的并發(fā)量,同時我們的應用服務器和數(shù)據(jù)庫服務器所做的計算也越來越多。但是往往我們的應用服務器資源是有限的,且技術變革是緩慢的,數(shù)據(jù)庫每秒能接受的請求次數(shù)也是有限的(或者文件的讀寫也是有限的),如何能夠有效利用有限的資源來提供盡可能大的吞吐量?一個有效的辦法就是減少計算量,縮短請求流程——這就是緩存。緩存的出現(xiàn)就是打破上述的標準流程,其中的任何一個環(huán)節(jié)都可以被截斷,請求可以從緩存中直接獲取目標數(shù)據(jù)并返回。通過這種打破常規(guī)的方式,有效減少計算量,縮短請求流程,有效提升響應速度,節(jié)省硬件資源,讓有限的資源服務更多的用戶。
如圖1所示,緩存的使用可以出現(xiàn)在 1-4的各個環(huán)節(jié)中,每個環(huán)節(jié)的緩存方案與使用各有特點。
圖1 網(wǎng)絡應用一般流程
緩存特征
根據(jù)面向?qū)ο蟮能浖季S來看,緩存就是一個對象類型,那么必然有它的屬性:
命中率
命中率=返回正確結(jié)果數(shù)/請求緩存次數(shù),命中率問題是緩存中的一個非常重要的問題,它是衡量緩存有效性的重要指標。命中率越高,表明緩存的使用率越高。
最大元素(或最大空間)
緩存中可以存放的最大元素的數(shù)量,一旦緩存中元素數(shù)量超過這個值(或者緩存數(shù)據(jù)所占空間超過其最大支持空間),那么將會觸發(fā)緩存啟動清空策略根據(jù)不同的場景合理的設置最大元素值往往可以一定程度上提高緩存的命中率,從而更有效的時候緩存。
清空策略
如上描述,緩存的存儲空間有限制,當緩存空間被用滿時,如何保證在穩(wěn)定服務的同時有效提升命中率?這就由緩存清空策略來處理,設計適合自身數(shù)據(jù)特征的情況策略能有效提升命中率。常見的一般策略有:
a. FIFO(first in first out)
先進先出策略,最先進入緩存的數(shù)據(jù)在緩存空間不夠的情況下(超出最大元素限制)會被優(yōu)先被清除掉,以騰出新的空間接受新的數(shù)據(jù)。策略算法主要比較緩存元素的創(chuàng)建時間。
b. LFU(less frequently used)
最少使用策略,無論是否過期,根據(jù)元素的被使用次數(shù)判斷,清除使用次數(shù)較少的元素釋放空間。策略算法主要比較元素的hitCount(命中次數(shù))。
c. LRU(least recently used)
最近最少使用策略,無論是否過期,根據(jù)元素最后一次被使用的時間戳,清除最遠使用時間戳的元素釋放空間。策略算法主要比較元素最近一次被get使用時間。
除此之外,還有一些簡單策略比如:
根據(jù)過期時間判斷,清理過期時間最長的元素;
根據(jù)過期時間判斷,清理最近要過期的元素;
隨機清理;
根據(jù)關鍵字(或元素內(nèi)容)長短清理等。
緩存介質(zhì)
?。◤挠布橘|(zhì)上來看,無非就是內(nèi)存和硬盤兩種)從技術上劃分,可以分成幾種,內(nèi)存、硬盤文件、數(shù)據(jù)庫。
內(nèi)存:將緩存存儲于內(nèi)存中是最快的選擇,無需額外的I/O開銷,但是內(nèi)存的缺點是沒有持久化落地物理磁盤,一旦應用異常break down,重新啟動數(shù)據(jù)很難或者無法復原。
硬盤:一般來說,很多緩存框架會結(jié)合使用內(nèi)存和硬盤,在內(nèi)存分配空間滿了或是在異常的情況下,可以被動或主動的將內(nèi)存空間數(shù)據(jù)持久化到硬盤中,達到釋放空間或備份數(shù)據(jù)的目的。
數(shù)據(jù)庫:前面我們有提到,增加緩存的策略的目的之一就是為了減少數(shù)據(jù)庫的I/O壓力?,F(xiàn)在使用數(shù)據(jù)庫做緩存介質(zhì)是不是又回到了老問題上了?其實,數(shù)據(jù)庫也有很多種類型,像那些不支持SQL,只是簡單的key、value的存儲結(jié)構(gòu)的特殊數(shù)據(jù)庫(如berkleydb),響應速度和吞吐量都遠遠高于我們常用的關系型數(shù)據(jù)庫等。
在目前的應用服務框架中,我們對緩存的分類劃分更常用的是根據(jù)緩存與應用的耦合程度,劃分為local cache(本地緩存)和remote cache(分布式緩存):
Local cache:指的是在應用中的緩存組件,其最大的優(yōu)點是應用和cache是在同一個進程內(nèi)部,請求緩存非??焖?,沒有過多的網(wǎng)絡開銷等,在單應用不需要集群支持或者集群情況下各節(jié)點無需互相通知的場景下使用本地緩存較合適;同時,它的缺點也是應為緩存跟應用程序耦合,多個應用程序無法直接的共享緩存,各應用或集群的各節(jié)點都需要維護自己的單獨緩存,對內(nèi)存是一種浪費。
Remote cache::指的是與應用分離的緩存組件或服務,其最大的優(yōu)點是自身就是一個獨立的應用,與本地應用隔離,多個應用可直接的共享緩存。
目前各種類型的緩存都活躍在成千上萬的應用服務中,還沒有一種緩存方案可以解決一切的業(yè)務場景或數(shù)據(jù)類型,我們需要根據(jù)自身的特殊場景和背景,選擇最適合的緩存方案。緩存的使用是程序員、架構(gòu)師的必備技能,好的程序員能根據(jù)數(shù)據(jù)類型、業(yè)務場景來準確判斷使用何種類型的緩存,如何使用這種緩存,以最小的成本最快的效率達到最優(yōu)的目的。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%