1. 前言

在高訪問量的web系統(tǒng)中，緩存幾乎是離不開的；但是一個(gè)適當(dāng)、高效的緩存方案設(shè)計(jì)卻并不容易；所以接下來將討論一下應(yīng)用系統(tǒng)緩存的設(shè)計(jì)方面應(yīng)該注意哪些東西，包括緩存的選型、常見緩存系統(tǒng)的特點(diǎn)和數(shù)據(jù)指標(biāo)、緩存對(duì)象結(jié)構(gòu)設(shè)計(jì)和失效策略以及緩存對(duì)象的壓縮等等，以期讓有需求的同學(xué)尤其是初學(xué)者能夠快速、系統(tǒng)的了解相關(guān)知識(shí)。

2. 數(shù)據(jù)庫的瓶頸

2.1 數(shù)據(jù)量

關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)量是比較小的，以我們常用的MySQL為例，單表數(shù)據(jù)條數(shù)一般應(yīng)該控制在2000w以內(nèi)，如果業(yè)務(wù)很復(fù)雜的話，可能還要低一些。即便是對(duì)于Oracle這些大型商業(yè)數(shù)據(jù)庫來講，其能存儲(chǔ)的數(shù)據(jù)量也很難滿足一個(gè)擁有幾千萬甚至數(shù)億用戶的大型互聯(lián)網(wǎng)系統(tǒng)。

2.2 TPS

在實(shí)際開發(fā)中我們經(jīng)常會(huì)發(fā)現(xiàn)，關(guān)系型數(shù)據(jù)庫在TPS上的瓶頸往往會(huì)比其他瓶頸更容易暴露出來，尤其對(duì)于大型web系統(tǒng)，由于每天大量的并發(fā)訪問，對(duì)數(shù)據(jù)庫的讀寫性能要求非常高；而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的處理能力確實(shí)捉襟見肘；以我們常用的MySQL數(shù)據(jù)庫為例，常規(guī)情況下的TPS大概只有1500左右（各種極端場(chǎng)景下另當(dāng)別論）；下圖是MySQL官方所給出的一份測(cè)試數(shù)據(jù)：

而對(duì)于一個(gè)日均PV千萬的大型網(wǎng)站來講，每個(gè)PV所產(chǎn)生的數(shù)據(jù)庫讀寫量可能要超出幾倍，這種情況下，每天所有的數(shù)據(jù)讀寫請(qǐng)求量可能遠(yuǎn)超出關(guān)系型數(shù)據(jù)的處理能力，更別說在流量峰值的情況下了；所以我們必須要有高效的緩存手段來抵擋住大部分的數(shù)據(jù)請(qǐng)求！

2.3 響應(yīng)時(shí)間

正常情況下，關(guān)系型數(shù)據(jù)的響應(yīng)時(shí)間是相當(dāng)不錯(cuò)的，一般在10ms以內(nèi)甚至更短，尤其是在配置得當(dāng)?shù)那闆r下。但是就如前面所言，我們的需求是不一般的：當(dāng)擁有幾億條數(shù)據(jù)，1wTPS的時(shí)候，響應(yīng)時(shí)間也要在10ms以內(nèi)，這幾乎是任何一款關(guān)系型數(shù)據(jù)都無法做到的。

那么這個(gè)問題如何解決呢？最簡(jiǎn)單有效的辦法當(dāng)然是緩存！

3. 緩存系統(tǒng)選型

3.1 緩存的類型

3.1.1 本地緩存

本地緩存可能是大家用的最多的一種緩存方式了，不管是本地內(nèi)存還是磁盤，其速度快，成本低，在有些場(chǎng)合非常有效；

但是對(duì)于web系統(tǒng)的集群負(fù)載均衡結(jié)構(gòu)來說，本地緩存使用起來就比較受限制，因?yàn)楫?dāng)數(shù)據(jù)庫數(shù)據(jù)發(fā)生變化時(shí)，你沒有一個(gè)簡(jiǎn)單有效的方法去更新本地緩存；然而，你如果在不同的服務(wù)器之間去同步本地緩存信息，由于緩存的低時(shí)效性和高訪問量的影響，其成本和性能恐怕都是難以接受的。

3.1.2 分布式緩存

前面提到過，本地緩存的使用很容易讓你的應(yīng)用服務(wù)器帶上“狀態(tài)”，這種情況下，數(shù)據(jù)同步的開銷會(huì)比較大；尤其是在集群環(huán)境中更是如此！

分布式緩存這種東西存在的目的就是為了提供比RDB更高的TPS和擴(kuò)展性，同時(shí)有幫你承擔(dān)了數(shù)據(jù)同步的痛苦；優(yōu)秀的分布式緩存系統(tǒng)有大家所熟知的Memcached、Redis（當(dāng)然也許你把它看成是NoSQL，但是我個(gè)人更愿意把分布式緩存也看成是NoSQL），還有國(guó)內(nèi)阿里自主開發(fā)的Tair等；

對(duì)比關(guān)系型數(shù)據(jù)庫和緩存存儲(chǔ)，其在讀和寫性能上的差距可謂天壤之別；memcached單節(jié)點(diǎn)已經(jīng)可以做到15w以上的tps、Redis、google的levelDB也有不菲的性能，而實(shí)現(xiàn)大規(guī)模集群后，性能可能會(huì)更高！

所以，在技術(shù)和業(yè)務(wù)都可以接受的情況下，我們可以盡量把讀寫壓力從數(shù)據(jù)庫轉(zhuǎn)移到緩存上，以保護(hù)看似強(qiáng)大，其實(shí)卻很脆弱的關(guān)系型數(shù)據(jù)庫。

3.1.3 客戶端緩存

這塊很容易被人忽略，客戶端緩存主要是指基于客戶端瀏覽器的緩存方式；由于瀏覽器本身的安全限制，web系統(tǒng)能在客戶端所做的緩存方式非常有限，主要由以下幾種：

a、 瀏覽器cookie；這是使用最多的在客戶端保存數(shù)據(jù)的方法，大家也都比較熟悉；

b、 瀏覽器本地緩存；很多瀏覽器都提供了本地緩存的接口，但是由于各個(gè)瀏覽器的實(shí)現(xiàn)有差異，所以這種方式很少被使用；此類方案有chrome的Google Gear，IE的userData、火狐的sessionStorage和globalStorage等；

c、 flash本地存儲(chǔ)；這個(gè)也是平時(shí)比較常用的緩存方式；相較于cookie，flash緩存基本沒有數(shù)量和體積的限制，而且由于基于flash插件，所以也不存在兼容性問題；不過在沒有安裝flash插件的瀏覽器上則無法使用；

d、 html5的本地存儲(chǔ)；鑒于html5越來越普及，再加上其本地存儲(chǔ)功能比較強(qiáng)大，所以在將來的使用場(chǎng)景應(yīng)該會(huì)越來越多。

由于大部分的web應(yīng)用都會(huì)盡量做到無狀態(tài)，以方便線性擴(kuò)容，所以我們能使用的除了后端存儲(chǔ)（DB、NoSQL、分布式文件系統(tǒng)、CDN等）外，就只剩前端的客戶端緩存了。

對(duì)客戶端存儲(chǔ)的合理使用，原本每天幾千萬甚至上億的接口調(diào)用，一下就可能降到了每天幾百萬甚至更少，而且即便是用戶更換瀏覽器，或者緩存丟失需要重新訪問服務(wù)器，由于隨機(jī)性比較強(qiáng)，請(qǐng)求分散，給服務(wù)器的壓力也很??！在此基礎(chǔ)上，再加上合理的緩存過期時(shí)間，就可以在數(shù)據(jù)準(zhǔn)確和性能上做一個(gè)很好的折衷。

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

這里主要是指數(shù)據(jù)庫的查詢緩存，大部分?jǐn)?shù)據(jù)庫都是會(huì)提供，每種數(shù)據(jù)庫的具體實(shí)現(xiàn)細(xì)節(jié)也會(huì)有所差異，不過基本的原理就是用查詢語句的hash值做key，對(duì)結(jié)果集進(jìn)行緩存；如果利用的好，可以很大的提高數(shù)據(jù)庫的查詢效率！數(shù)據(jù)庫的其他一些緩存將在后邊介紹。

3.2 選型指標(biāo)

現(xiàn)在可供我們選擇使用的（偽）分布式緩存系統(tǒng)不要太多，比如使用廣泛的Memcached、最近炒得火熱的Redis等；這里前面加個(gè)偽字，意思是想說，有些所謂的分布式緩存其實(shí)仍是以單機(jī)的思維去做的，不能算是真正的分布式緩存（你覺得只實(shí)現(xiàn)個(gè)主從復(fù)制能算分布式么？）。

既然有這么多的系統(tǒng)可用，那么我們?cè)谶x擇的時(shí)候，就要有一定的標(biāo)準(zhǔn)和方法。只有有了標(biāo)準(zhǔn)，才能衡量一個(gè)系統(tǒng)時(shí)好時(shí)壞，或者適不適合，選擇就基本有了方向。

下邊幾點(diǎn)是我個(gè)人覺的應(yīng)該考慮的幾個(gè)點(diǎn)（其實(shí)大部分系統(tǒng)選型都是這么考慮的，并非只有緩存系統(tǒng)）：

3.2.1 容量

廢話，容量當(dāng)然是越大越好了，這還用說么，有100G我干嘛還要用10G？其實(shí)這么說總要考慮一下成本啦，目前一臺(tái)普通的PC Server內(nèi)存128G已經(jīng)算是大的了，再大的話不管是從硬件還是從軟件方面，管理的成本都會(huì)增加。單機(jī)來講，比如說主板的插槽數(shù)量，服務(wù)器散熱、操作系統(tǒng)的內(nèi)存分配、回收、碎片管理等等都會(huì)限制內(nèi)存卡的容量；即便使用多機(jī)的話，大量?jī)?nèi)存的采購(gòu)也是很費(fèi)money的！

有詩云：山不在高，有仙則名；所以內(nèi)存也不在多，夠用就好！每個(gè)系統(tǒng)在初期規(guī)劃的時(shí)候，都會(huì)大致計(jì)算一下所要消耗的緩存空間，這主要取決于你要緩存的對(duì)象數(shù)量和單個(gè)對(duì)象的大小。一般來說，你可以采用對(duì)象屬性在內(nèi)存中的存儲(chǔ)長(zhǎng)度簡(jiǎn)單加和的方法來計(jì)算單個(gè)對(duì)象的體積，再乘以緩存對(duì)象的數(shù)量和預(yù)期增長(zhǎng)（當(dāng)然，這里邊有一個(gè)熱點(diǎn)數(shù)據(jù)的問題，這里就不細(xì)討論了），大概得出需要使用的緩存空間；之后就可以按照這個(gè)指標(biāo)去申請(qǐng)緩存空間或搭建緩存系統(tǒng)了。

3.2.2 并發(fā)量

這里說并發(fā)量，其實(shí)還不如說是QPS更貼切一些，因?yàn)槲覀兊木彺娌皇侵苯用嫦蛴脩舻?，而只面向?yīng)用的，所以肯定不會(huì)有那個(gè)高的并發(fā)訪問（當(dāng)然，多個(gè)系統(tǒng)共用一套緩存那就另當(dāng)別論了）；所以我們關(guān)心的是一個(gè)緩存系統(tǒng)平均每秒能夠承受多少的訪問量。

我們之所以需要緩存系統(tǒng)，就是要它在關(guān)鍵時(shí)刻能抗住我們的數(shù)據(jù)訪問量的；所以，緩存系統(tǒng)能夠支撐的并發(fā)量是一個(gè)非常重要的指標(biāo)，如果它的性能還不如關(guān)系型數(shù)據(jù)庫，那我們就沒有使用的必要了。

對(duì)于淘寶的系統(tǒng)來說，我們不妨按照下邊的方案來估算并發(fā)量：

QPS = 日PV × 讀寫次數(shù)/PV ÷ (8 × 60 × 60)

這里我們是按照一天8個(gè)小時(shí)來計(jì)算的，這個(gè)值基于一個(gè)互聯(lián)網(wǎng)站點(diǎn)的訪問規(guī)律得出的，當(dāng)然，如果你不同意這個(gè)值，可以自己定義。

在估算訪問量的時(shí)候，我們不得不考慮一個(gè)峰值的問題，尤其是像淘寶、京東這樣大型的電商網(wǎng)站，經(jīng)常會(huì)因?yàn)橐恍┐蟮拇黉N活動(dòng)而使PV、UV沖到平時(shí)的幾倍甚至幾十倍，這也正是緩存系統(tǒng)發(fā)揮作用的關(guān)鍵時(shí)刻；倍受矚目的12306在站點(diǎn)優(yōu)化過程中也大量的引入了緩存（內(nèi)存文件系統(tǒng)）來提升性能。

在計(jì)算出平均值之后，再乘以一個(gè)峰值系數(shù)，基本就可以得出你的緩存系統(tǒng)需要承受的最高QPS，一般情況下，這個(gè)系數(shù)定在10以內(nèi)是合理的。

3.2.3 響應(yīng)時(shí)間

響應(yīng)時(shí)間當(dāng)然也是必要的，如果一個(gè)緩存系統(tǒng)慢的跟蝸牛一樣，甚至直接就超時(shí)了，那和我們使用MySQL也沒啥區(qū)別了。

一般來說，要求一個(gè)緩存系統(tǒng)在1ms或2ms之內(nèi)返回?cái)?shù)據(jù)是不過分的，當(dāng)然前提是你的數(shù)據(jù)不會(huì)太大；如果想更快的話，那你就有點(diǎn)過分了，除非你是用的本地緩存；因?yàn)橐话愣?，在大?/span>IDC內(nèi)部，一個(gè)TCP回環(huán)（不攜帶業(yè)務(wù)數(shù)據(jù)）差不多就要消耗掉0.2ms至0.5ms。

大部分的緩存系統(tǒng)，由于是基于內(nèi)存，所以響應(yīng)時(shí)間都很短，但是問題一般會(huì)出現(xiàn)在數(shù)據(jù)量和QPS變大之后，由于內(nèi)存管理策略、數(shù)據(jù)查找方式、I/O模型、業(yè)務(wù)場(chǎng)景等方面的差異，響應(yīng)時(shí)間可能會(huì)差異很多，所以對(duì)于QPS和響應(yīng)時(shí)間這兩項(xiàng)指標(biāo)，還要靠上線前充分的性能測(cè)試來進(jìn)一步確認(rèn)，不能只單純的依賴官方的測(cè)試結(jié)果。

3.2.4 使用成本

一般分布式緩存系統(tǒng)會(huì)包括服務(wù)端和客戶端兩部分，所以其使用成本上也要分為兩個(gè)部分來講；

首先服務(wù)端，優(yōu)秀的系統(tǒng)要是能夠方便部署和方便運(yùn)維的，不需要高端硬件、不需要復(fù)雜的環(huán)境配置、不能有過多的依賴條件，同時(shí)還要穩(wěn)定、易維護(hù)；

而對(duì)于客戶端的使用成本來說，更關(guān)系到程序員的開發(fā)效率和代碼維護(hù)成本，基本有三點(diǎn)：單一的依賴、簡(jiǎn)潔的配置和人性化的API。

另外有一點(diǎn)要提的是，不管是服務(wù)端還是客戶端，豐富的文檔和技術(shù)支持也是必不可少的。

3.2.5 擴(kuò)展性

緩存系統(tǒng)的擴(kuò)展性是指在空間不足的性情況，能夠通過增加機(jī)器等方式快速的在線擴(kuò)容。這也是能夠支撐業(yè)務(wù)系統(tǒng)快速發(fā)展的一個(gè)重要因素。

一般來講，分布式緩存的負(fù)載均衡策略有兩種，一種是在客戶端來做，另外一種就是在服務(wù)端來做。

客戶端負(fù)載均衡

在客戶端來做負(fù)載均衡的，諸如前面我們提到的Memcached、Redis等，一般都是通過特定Hash算法將key對(duì)應(yīng)的value映射到固定的緩存服務(wù)器上去，這樣的做法最大的好處就是簡(jiǎn)單，不管是自己實(shí)現(xiàn)一個(gè)映射功能還是使用第三方的擴(kuò)展，都很容易；但由此而來的一個(gè)問題是我們無法做到failover。比如說某一臺(tái)Memcached服務(wù)器掛掉了，但是客戶端還會(huì)傻不啦嘰的繼續(xù)請(qǐng)求該服務(wù)器，從而導(dǎo)致大量的線程超時(shí)；當(dāng)然，因此而造成的數(shù)據(jù)丟失是另外一回事了。要想解決，簡(jiǎn)單的可能只改改改代碼或者配置文件就ok了，但是像Java這種就蛋疼了，有可能還需要重啟所有應(yīng)用以便讓變更能夠生效。

如果線上緩存容量不夠了，要增加一些服務(wù)器，也有同樣的問題；而且由于hash算法的改變，還要遷移對(duì)應(yīng)的數(shù)據(jù)到正確的服務(wù)器上去。

服務(wù)端負(fù)載均衡

如果在服務(wù)端來做負(fù)載均衡，那么我們前面提到的failover的問題就很好解決了；客戶端能夠訪問的所有的緩存服務(wù)器的ip和端口都會(huì)事先從一個(gè)中心配置服務(wù)器上獲取，同時(shí)客戶端會(huì)和中心配置服務(wù)器保持一種有效的通信機(jī)制（長(zhǎng)連接或者HeartBeat），能夠使后端緩存服務(wù)器的ip和端口變更即時(shí)的通知到客戶端，這樣，一旦后端服務(wù)器發(fā)生故障時(shí)可以很快的通知到客戶端改變hash策略，到新的服務(wù)器上去存取數(shù)據(jù)。

但這樣做會(huì)帶來另外一個(gè)問題，就是中心配置服務(wù)器會(huì)成為一個(gè)單點(diǎn)。解決辦法就將中心配置服務(wù)器由一臺(tái)變?yōu)槎嗯_(tái)，采用雙機(jī)stand by方式或者zookeeper等方式，這樣可用性也會(huì)大大提高。

3.2.6 容災(zāi)

我們使用緩存系統(tǒng)的初衷就是當(dāng)數(shù)據(jù)請(qǐng)求量很大，數(shù)據(jù)庫無法承受的情況，能夠通過緩存來抵擋住大部分的請(qǐng)求流量，所以一旦緩存服務(wù)器發(fā)生故障，而緩存系統(tǒng)又沒有一個(gè)很好的容災(zāi)措施的話，所有或部分的請(qǐng)求將會(huì)直接壓倒數(shù)據(jù)庫上，這可能會(huì)直接導(dǎo)致DB崩潰。

并不是所有的緩存系統(tǒng)都具有容災(zāi)特性的，所以我們?cè)谶x擇的時(shí)候，一定要根據(jù)自己的業(yè)務(wù)需求，對(duì)緩存數(shù)據(jù)的依賴程度來決定是否需要緩存系統(tǒng)的容災(zāi)特性。

3.3 常見分布式緩存系統(tǒng)比較

3.3.1 Memcached

Memcached嚴(yán)格的說還不能算是一個(gè)分布式緩存系統(tǒng)，個(gè)人更傾向于將其看成一個(gè)單機(jī)的緩存系統(tǒng)，所以從這方面講其容量上是有限制的；但由于Memcached的開源，其訪問協(xié)議也都是公開的，所以目前有很多第三方的客戶端或擴(kuò)展，在一定程度上對(duì)Memcached的集群擴(kuò)展做了支持，但是大部分都只是做了一個(gè)簡(jiǎn)單Hash或者一致性Hash。

由于Memcached內(nèi)部通過固定大小的chunk鏈的方式去管理內(nèi)存數(shù)據(jù)，分配和回收效率很高，所以其讀寫性能也非常高；官方給出的數(shù)據(jù)，64KB對(duì)象的情況下，單機(jī)QPS可達(dá)到15w以上。

Memcached集群的不同機(jī)器之間是相互獨(dú)立的，沒有數(shù)據(jù)方面的通信，所以也不具備failover的能力，在發(fā)生數(shù)據(jù)傾斜的時(shí)候也無法自動(dòng)調(diào)整。

Memcached的多語言支持非常好，目前可支持C/C++、Java、C#、PHP、Python、Perl、Ruby等常用語言，也有大量的文檔和示例代碼可供參考，而且其穩(wěn)定性也經(jīng)過了長(zhǎng)期的檢驗(yàn)，應(yīng)該說比較適合于中小型系統(tǒng)和初學(xué)者使用的緩存系統(tǒng)。

3.3.2 Redis

Redis也是眼下比較流行的一個(gè)緩存系統(tǒng)，在國(guó)內(nèi)外很多互聯(lián)網(wǎng)公司都在使用（新浪微博就是個(gè)典型的例子），很多人把Redis看成是Memcached的替代品。

下面就簡(jiǎn)單介紹下Redis的一些特性；

Redis除了像Memcached那樣支持普通的<k,v>類型的存儲(chǔ)外，還支持List、Set、Map等集合類型的存儲(chǔ)，這種特性有時(shí)候在業(yè)務(wù)開發(fā)中會(huì)比較方便；

Redis源生支持持久化存儲(chǔ)，但是根據(jù)很多人的使用情況和測(cè)試結(jié)果來看，Redis的持久化是個(gè)雞肋，就連官方也不推薦過度依賴Redis持久化存儲(chǔ)功能。就性能來講，在全部命中緩存時(shí)，Redis的性能接近memcached，但是一旦使用了持久化之后，性能會(huì)迅速下降，甚至?xí)嗖钜粋€(gè)數(shù)量級(jí)。

Redis支持“集群”，這里的集群還是要加上引號(hào)的，因?yàn)槟壳?/span>Redis能夠支持的只是Master-Slave模式；這種模式只在可用性方面有一定的提升，當(dāng)主機(jī)宕機(jī)時(shí)，可以快速的切換到備機(jī)，和MySQL的主備模式差不多，但是還算不上是分布式系統(tǒng)；

此外，Redis支持訂閱模式，即一個(gè)緩存對(duì)象發(fā)生變化時(shí)，所有訂閱的客戶端都會(huì)收到通知，這個(gè)特性在分布式緩存系統(tǒng)中是很少見的。

在擴(kuò)展方面，Redis目前還沒有成熟的方案，官方只給出了一個(gè)單機(jī)多實(shí)例部署的替代方案，并通過主備同步的模式進(jìn)行擴(kuò)容時(shí)的數(shù)據(jù)遷移，但是還是無法做到持續(xù)的線性擴(kuò)容。

3.3.3 淘寶Tair

Tair是淘寶自主開發(fā)并開源的一款的緩存系統(tǒng)，而且也是一套真正意義上的分布式并且可以跨多機(jī)房部署，同時(shí)支持內(nèi)存緩存和持久化存儲(chǔ)的解決方案；我們數(shù)平這邊也有自己的改進(jìn)版本。

Tair實(shí)現(xiàn)了緩存框架和緩存存儲(chǔ)引擎的獨(dú)立，在遵守接口規(guī)范的情況下，可以根據(jù)需求更換存儲(chǔ)引擎，目前支持mdb（基于memcached）、rdb（基于Redis）、kdb（基于kyoto cabinet，持久存儲(chǔ)，目前已不推薦使用）和rdb（基于gooogle的levelDB，持久化存儲(chǔ)）幾種引擎；

由于基于mdb和rdb，所以Tair能夠間距兩者的特性，而且在并發(fā)量和響應(yīng)時(shí)間上，也接近二者的裸系統(tǒng)。

在擴(kuò)展性和容災(zāi)方面，Tair自己做了增強(qiáng)；通過使用虛擬節(jié)點(diǎn)Hash（一致性Hash的變種實(shí)現(xiàn)）的方案，將key通過Hash函數(shù)映射到到某個(gè)虛擬節(jié)點(diǎn)（桶）上，然后通過中心服務(wù)器（configserver）來管理虛擬節(jié)點(diǎn)到物理節(jié)點(diǎn)的映射關(guān)系；這樣，Tair不但實(shí)現(xiàn)了基于Hash的首次負(fù)載均衡，同時(shí)又可以通過調(diào)整虛擬節(jié)點(diǎn)和物理節(jié)點(diǎn)的映射關(guān)系來實(shí)現(xiàn)二次負(fù)載均衡，這樣有效的解決了由于業(yè)務(wù)熱點(diǎn)導(dǎo)致的訪問不均衡問題以及線性擴(kuò)容時(shí)數(shù)據(jù)遷移麻煩；此外，Tair的每臺(tái)緩存服務(wù)器和中心服務(wù)器（configserver）也有主備設(shè)計(jì)，所以其可用性也大大提高。

3.3.4 內(nèi)存數(shù)據(jù)庫

這里的內(nèi)存數(shù)據(jù)庫只要是指關(guān)系型內(nèi)存數(shù)據(jù)庫。一般來說，內(nèi)存數(shù)據(jù)庫使用場(chǎng)景可大致分為兩種情況：

一是對(duì)數(shù)據(jù)計(jì)算實(shí)時(shí)性要求比較高，基于磁盤的數(shù)據(jù)庫很難處理；同時(shí)又要依賴關(guān)系型數(shù)據(jù)庫的一些特性，比如說排序、加合、復(fù)雜條件查詢等等；這樣的數(shù)據(jù)一般是臨時(shí)的數(shù)據(jù)，生命周期比較短，計(jì)算完成或者是進(jìn)程結(jié)束時(shí)即可丟棄；

另一種是數(shù)據(jù)的訪問量比較大，但是數(shù)據(jù)量卻不大，這樣即便丟失也可以很快的從持久化存儲(chǔ)中把數(shù)據(jù)加載進(jìn)內(nèi)存；

但不管是在哪種場(chǎng)景中，存在于內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)都必須是相對(duì)獨(dú)立的或者是只服務(wù)于讀請(qǐng)求的，這樣不需要復(fù)雜的數(shù)據(jù)同步處理。

3.4 緩存的設(shè)計(jì)與策略

3.4.1 緩存對(duì)象設(shè)計(jì)

3.4.1.1 緩存對(duì)象粒度

對(duì)于本地磁盤或分布是緩存系統(tǒng)來說，其緩存的數(shù)據(jù)一般都不是結(jié)構(gòu)化的，而是半結(jié)構(gòu)話或是序列化的；這就導(dǎo)致了我們讀取緩存時(shí)，很難直接拿到程序最終想要的結(jié)果；這就像快遞的包裹，如果你不打開外層的包裝，你就拿不出來里邊的東西；

如果包裹里的東西有很多，但是其中只有一個(gè)是你需要的，其他的還要再包好送給別人；這時(shí)候你打開包裹時(shí)就會(huì)很痛苦——為了拿到自己的東西，必須要拆開包裹，但是拆開后還要很麻煩的將剩下的再包會(huì)去；等包裹傳遞到下一個(gè)人的手里，又是如此！

所以，這個(gè)時(shí)候粒度的控制就很重要了；到底是一件東西就一個(gè)包裹呢，還是好多東西都包一塊呢？前者拆起來方便，后著節(jié)約包裹數(shù)量。映射到我們的系統(tǒng)上，我們的緩存對(duì)象中到底要放哪些數(shù)據(jù)？一種數(shù)據(jù)一個(gè)對(duì)象，簡(jiǎn)單，讀取寫入都快，但是種類一多，緩存的管理成本就會(huì)很高；多種數(shù)據(jù)放在一個(gè)對(duì)象里，方便，一塊全出來了，想用哪個(gè)都可以，但是如果我只要一種數(shù)據(jù)，其他的就都浪費(fèi)了，網(wǎng)絡(luò)帶寬和傳輸延遲的消耗也很可觀。

這個(gè)時(shí)候主要的考慮點(diǎn)就應(yīng)該是業(yè)務(wù)場(chǎng)景了，不同的場(chǎng)景使用不同的緩存粒度，折衷權(quán)衡；不要不在乎這點(diǎn)性能損失，緩存一般都是訪問頻率非常高的數(shù)據(jù)，各個(gè)點(diǎn)的累積效應(yīng)可能是非常巨大的！

當(dāng)然，有些緩存系統(tǒng)的設(shè)計(jì)也要求我們必須考慮緩存對(duì)象的粒度問題；比如說Memcached，其chunk設(shè)計(jì)要求業(yè)務(wù)要能很好的控制其緩存對(duì)象的大小；淘寶的Tair也是，對(duì)于尺寸超過1M的對(duì)象，處理效率將大為降低；

像Redis這種提供同時(shí)提供了Map、List結(jié)構(gòu)支持的系統(tǒng)來說，雖然增加了緩存結(jié)構(gòu)的靈活性，但最多也只能算是半結(jié)構(gòu)化緩存，還無法做到像本地內(nèi)存那樣的靈活性。

粒度設(shè)計(jì)的過粗還會(huì)遇到并發(fā)問題。一個(gè)大對(duì)象里包含的多種數(shù)據(jù)，很多地方多要用，這時(shí)如果使用的是緩存修改模式而不是過期模式，那么很可能會(huì)因?yàn)椴l(fā)更新而導(dǎo)致數(shù)據(jù)被覆蓋；版本控制是一種解決方法，但是這樣會(huì)使緩存更新失敗的概率大大增加，而且有些緩存系統(tǒng)也不提供版本支持（比如說用的很廣泛的Memcached）。

3.4.1.2 緩存對(duì)象結(jié)構(gòu)

同緩存粒度一樣，緩存的結(jié)構(gòu)也是一樣的道理。對(duì)于一個(gè)緩存對(duì)象來說，并不是其粒度越小，體積也越?。蝗绻愕囊粋€(gè)字符串就有1M大小，那也是很恐怖的；

數(shù)據(jù)的結(jié)構(gòu)決定著你讀取的方式，舉個(gè)很簡(jiǎn)單的例子，集合對(duì)象中，List和Map兩種數(shù)據(jù)結(jié)構(gòu)，由于其底層存儲(chǔ)方式不同，所以使用的場(chǎng)景也不一樣；前者更適合有序遍歷，而后者適合隨機(jī)存?。换叵胍幌?，你是不是曾經(jīng)在程序中遇到過為了merge兩個(gè)list中的數(shù)據(jù)，而不得不循環(huán)嵌套？

所以，根據(jù)具體應(yīng)用場(chǎng)景去為緩存對(duì)象設(shè)計(jì)一個(gè)更合適的存儲(chǔ)結(jié)構(gòu)，也是一個(gè)很值得注意的點(diǎn)。

3.4.2 緩存更新策略

緩存的更新策略主要有兩種：被動(dòng)失效和主動(dòng)更新，下面分別進(jìn)行介紹；

3.4.2.1 被動(dòng)失效

一般來說，緩存數(shù)據(jù)主要是服務(wù)讀請(qǐng)求的，并設(shè)置一個(gè)過期時(shí)間；或者當(dāng)數(shù)據(jù)庫狀態(tài)改變時(shí)，通過一個(gè)簡(jiǎn)單的delete操作，使數(shù)據(jù)失效掉；當(dāng)下次再去讀取時(shí)，如果發(fā)現(xiàn)數(shù)據(jù)過期了或者不存在了，那么就重新去持久層讀取，然后更新到緩存中；這即是所謂的被動(dòng)失效策略。

但是在被動(dòng)失效策略中存在一個(gè)問題，就是從緩存失效或者丟失開始直到新的數(shù)據(jù)再次被更新到緩存中的這段時(shí)間，所有的讀請(qǐng)求都將會(huì)直接落到數(shù)據(jù)庫上；而對(duì)于一個(gè)大訪問量的系統(tǒng)來說，這有可能會(huì)帶來風(fēng)險(xiǎn)。所以我們換一種策略就是，當(dāng)數(shù)據(jù)庫更新時(shí)，主動(dòng)去同步更新緩存，這樣在緩存數(shù)據(jù)的整個(gè)生命期內(nèi)，就不會(huì)有空窗期，前端請(qǐng)求也就沒有機(jī)會(huì)去親密接觸數(shù)據(jù)庫。

3.4.2.2 主動(dòng)更新

前面我們提到主動(dòng)更新主要是為了解決空窗期的問題，但是這同樣會(huì)帶來另一個(gè)問題，就是并發(fā)更新的情況；

在集群環(huán)境下，多臺(tái)應(yīng)用服務(wù)器同時(shí)訪問一份數(shù)據(jù)是很正常的，這樣就會(huì)存在一臺(tái)服務(wù)器讀取并修改了緩存數(shù)據(jù)，但是還沒來得及寫入的情況下，另一臺(tái)服務(wù)器也讀取并修改舊的數(shù)據(jù)，這時(shí)候，后寫入的將會(huì)覆蓋前面的，從而導(dǎo)致數(shù)據(jù)丟失；這也是分布式系統(tǒng)開發(fā)中，必然會(huì)遇到的一個(gè)問題。解決的方式主要有三種：

a、鎖控制；這種方式一般在客戶端實(shí)現(xiàn)（在服務(wù)端加鎖是另外一種情況），其基本原理就是使用讀寫鎖，即任何進(jìn)程要調(diào)用寫方法時(shí)，先要獲取一個(gè)排他鎖，阻塞住所有的其他訪問，等自己完全修改完后才能釋放；如果遇到其他進(jìn)程也正在修改或讀取數(shù)據(jù)，那么則需要等待；

鎖控制雖然是一種方案，但是很少有真的這樣去做的，其缺點(diǎn)顯而易見，其并發(fā)性只存在于讀操作之間，只要有寫操作存在，就只能串行。

b、版本控制；這種方式也有兩種實(shí)現(xiàn)，一種是單版本機(jī)制，即為每份數(shù)據(jù)保存一個(gè)版本號(hào)，當(dāng)緩存數(shù)據(jù)寫入時(shí)，需要傳入這個(gè)版本號(hào)，然后服務(wù)端將傳入的版本號(hào)和數(shù)據(jù)當(dāng)前的版本號(hào)進(jìn)行比對(duì)，如果大于當(dāng)前版本，則成功寫入，否則返回失敗；這樣解決方式比較簡(jiǎn)單；但是增加了高并發(fā)下客戶端的寫失敗概率；

還有一種方式就是多版本機(jī)制，即存儲(chǔ)系統(tǒng)為每個(gè)數(shù)據(jù)保存多份，每份都有自己的版本號(hào)，互不沖突，然后通過一定的策略來定期合并，再或者就是交由客戶端自己去選擇讀取哪個(gè)版本的數(shù)據(jù)。很多分布式緩存一般會(huì)使用單版本機(jī)制，而很多NoSQL則使用后者。

3.4.3 數(shù)據(jù)對(duì)象序列化

由于獨(dú)立于應(yīng)用系統(tǒng)，分布式緩存的本質(zhì)就是將所有的業(yè)務(wù)數(shù)據(jù)對(duì)象序列化為字節(jié)數(shù)組，然后保存到自己的內(nèi)存中。所使用的序列化方案也自然會(huì)成為影響系統(tǒng)性能的關(guān)鍵點(diǎn)之一。

一般來說，我們對(duì)一個(gè)序列化框架的關(guān)注主要有以下幾點(diǎn)：

a 序列化速度；即對(duì)一個(gè)普通對(duì)象，將其從內(nèi)存對(duì)象轉(zhuǎn)換為字節(jié)數(shù)組需要多長(zhǎng)時(shí)間；這個(gè)當(dāng)然是越快越好；

b對(duì)象壓縮比；即序列化后生成對(duì)象的與原內(nèi)存對(duì)象的體積比；

c支持的數(shù)據(jù)類型范圍；序列化框架都支持什么樣的數(shù)據(jù)結(jié)構(gòu)；對(duì)于大部分的序列化框架來說，都會(huì)支持普通的對(duì)象類型，但是對(duì)于復(fù)雜對(duì)象（比如說多繼承關(guān)系、交叉引用、集合類等）可能不支持或支持的不夠好；

d易用性；一個(gè)好的序列化框架必須也是使用方便的，不需要用戶做太多的依賴或者額外配置；

對(duì)于一個(gè)序列化框架來說，以上幾個(gè)特性很難都做到很出色，這是一個(gè)魚和熊掌不可兼得的東西（具體原因后面會(huì)介紹），但是終歸有自己的優(yōu)勢(shì)和特長(zhǎng)，需要使用者根據(jù)實(shí)際場(chǎng)景仔細(xì)考量。

我們接下來會(huì)討論幾種典型的序列化工具；

首先我們先針對(duì)幾組框架來做一個(gè)簡(jiǎn)單的對(duì)比測(cè)試，看看他們?cè)趯?duì)象壓縮比和性能方面到底如何；

我們先定義一個(gè)Java對(duì)象，該對(duì)象里主要包含了我們常用的int、long、float、double、String和Date類型的屬性，每種類型的屬性各有兩個(gè)；

測(cè)試時(shí)的樣本數(shù)據(jù)隨機(jī)生成，并且數(shù)據(jù)生成時(shí)間不計(jì)入測(cè)試時(shí)間；因?yàn)槊糠N序列化框架的內(nèi)部實(shí)現(xiàn)策略，所以即便是同一框架在處理不同類型數(shù)據(jù)時(shí)表現(xiàn)也會(huì)有差異；同時(shí)測(cè)試結(jié)果也會(huì)受到機(jī)器配置、運(yùn)行環(huán)境等影響；限于篇幅，此處只是簡(jiǎn)單做了一個(gè)對(duì)比測(cè)試，感興趣的同學(xué)可以針對(duì)自己項(xiàng)目中的實(shí)際數(shù)據(jù)，來做更詳細(xì)、更有針對(duì)性的測(cè)試；

首先我們先來看下幾種框架壓縮后的體積情況，如下表：

單位：字節(jié)

接下來再看一下序列化處理時(shí)間數(shù)據(jù)；如下表所示：

單位：納秒

綜合來看，如果只處理數(shù)值類型，幾種序列化框架的對(duì)象壓縮比相差驚人，Protobuf和kryo生成的自己數(shù)組只有Hessian和Java的五分之一或六分之一，加上字符串的處理后（對(duì)于大尺寸文檔，有很多壓縮算法都可以做到高效的壓縮比，但是針對(duì)對(duì)象屬性中的這種小尺寸文本，可用的壓縮算法并不多），差距縮小了大概一倍。而在處理時(shí)間上，幾種框架也有者相應(yīng)程度的差距，二者的增減性是基本一致的。

Java源生序列化

Java源生序列化是JDK自帶的對(duì)象序列化方式，也是我們最常用的一種；其優(yōu)點(diǎn)是簡(jiǎn)單、方便，不需要額外的依賴而且大部分三方系統(tǒng)或框架都支持；目前看來，Java源生序列化的兼容性也是最好的，可支持任何實(shí)現(xiàn)了Serializable接口的對(duì)象（包括多繼承、循環(huán)引用、集合類等等）。但隨之而來不可避免的就是，其序列化的速度和生成的對(duì)象體積和其他序列化框架相比，幾乎都是最差的。

我們不妨先來看一下序列化工具要處理那些事情：

a、 首先，要記錄序列化對(duì)象的描述信息，包括類名和路徑，反序列化時(shí)要用；

b、 要記錄類中所有的屬性的描述信息，包括屬性名稱、類型和屬性值；

c、 如果類有繼承關(guān)系，則要對(duì)所有父類進(jìn)行前述a和b步驟的處理；

d、 如果屬性中有復(fù)雜類型，這還要對(duì)這些對(duì)象進(jìn)行a、b、c步驟的處理；

e、 記錄List、Set、Map等集合類的描述信息，同時(shí)要對(duì)key或value中的復(fù)雜對(duì)象進(jìn)行a、b、c、d步驟的操作

可見，一個(gè)對(duì)象的序列化所需要做的工作是遞歸的，相當(dāng)繁瑣，要記錄大量的描述信息，而我們的Java源生序列化不但做了上邊所有的事情，而且還做的規(guī)規(guī)矩矩，甚至還“自作多情”的幫你加上了一些JVM執(zhí)行時(shí)要用到的信息。

所以現(xiàn)在就是用腳都能夠想明白，Java原生序列化幫你做了這么多事情，它能不慢么？而且還做得這么規(guī)矩（迂腐？），結(jié)果能不大么？

下面就基本是各個(gè)工具針對(duì)Java弱點(diǎn)的改進(jìn)了。

Hessian

Hessian的序列化實(shí)現(xiàn)和Java的原生序列化很相似，只是對(duì)于序列化反序列化本身并不需要的一些元數(shù)據(jù)進(jìn)行了刪減；所以Hessian可以像Java的源生序列化那樣，可以支持任意類型的對(duì)象；但是在存儲(chǔ)上，Hessian并沒有做相應(yīng)的優(yōu)化，所以其生成的對(duì)象體積相較于Java的源生序列化并沒有下降太多；

比如，Hessian對(duì)于數(shù)值類型仍然使用了定長(zhǎng)存儲(chǔ)，而在通常情況下，經(jīng)常使用的數(shù)據(jù)都是比較小的，大部分的存儲(chǔ)空間是被浪費(fèi)掉的；

為了標(biāo)志屬性區(qū)段的結(jié)束，Hessian使用了長(zhǎng)度字段來表示，這在一定程度上會(huì)增大結(jié)果數(shù)據(jù)的體積；

由于Hessian相較于Java源生序列化并沒有太大的優(yōu)勢(shì)，所以一般情況下，如果系統(tǒng)中沒有使用Hessian的rpc框架，則很少單獨(dú)使用Hessian的序列化機(jī)制。

Google Protobuf

GPB最大的特點(diǎn)就是自己定義了一套自己數(shù)據(jù)類型，并且規(guī)定只允許用我的這套；所以在使用GPB的時(shí)候，我們不得不為它單獨(dú)定義一個(gè)描述文件，或者叫schema文件，用來完成Java對(duì)象中的基本數(shù)據(jù)類型和GPB自己定義的類型之間的一個(gè)映射；

不過也正是GPB對(duì)類型的自定義，也讓他可以更好的針對(duì)這些類型做出存儲(chǔ)和解析上的優(yōu)化，從而避免了Java源生序列化中的諸多弱點(diǎn)。

對(duì)于對(duì)象屬性，GPB并沒有直接存儲(chǔ)屬性名稱，而是根據(jù)schema文件中的映射關(guān)系，只保存該屬性的順序id；而對(duì)于，GPB針對(duì)常用的幾種數(shù)據(jù)類型采用了不同程度的壓縮，同時(shí)屬性區(qū)段之間采用特定標(biāo)記進(jìn)行分隔，這樣可以大大減少存儲(chǔ)所占用的空間。

對(duì)于數(shù)值類型，常見的壓縮方式有變長(zhǎng)byte、分組byte、差值存儲(chǔ)等，一般都是根據(jù)屬性的使用特點(diǎn)來做定制化的壓縮策略。

GPB的另一個(gè)優(yōu)點(diǎn)就是跨語言，支持Java、C、PHP、Python等目前比較大眾的語言；其他類似的還有Facebook的Thrift，也需要描述文件的支持，同時(shí)也包含了一個(gè)rpc框架和更豐富的語言支持；

Kryo

前面我們提到，諸如Hessian和GPB這些三方的序列化框架或多或少的都對(duì)Java原生序列化機(jī)制做出了一些改進(jìn)；而對(duì)于Kryo來說，改進(jìn)無疑是更徹底一些；在很多評(píng)測(cè)中，Kryo的數(shù)據(jù)都是遙遙領(lǐng)先的；

Kryo的處理和Google Protobuf類似。但有一點(diǎn)需要說明的是，Kryo在做序列化時(shí)，也沒有記錄屬性的名稱，而是給每個(gè)屬性分配了一個(gè)id，但是他卻并沒有GPB那樣通過一個(gè)schema文件去做id和屬性的一個(gè)映射描述，所以一旦我們修改了對(duì)象的屬性信息，比如說新增了一個(gè)字段，那么Kryo進(jìn)行反序列化時(shí)就可能發(fā)生屬性值錯(cuò)亂甚至是反序列化失敗的情況；而且由于Kryo沒有序列化屬性名稱的描述信息，所以序列化/反序列化之前，需要先將要處理的類在Kryo中進(jìn)行注冊(cè)，這一操作在首次序列化時(shí)也會(huì)消耗一定的性能。

另外需要提一下的就是目前kryo目前還只支持Java語言。

如何選擇？

就Java原生序列化功能而言，雖然它性能和體積表現(xiàn)都非常差，但是從使用上來說卻是非常廣泛，只要是使用Java的框架，那就可以用Java原生序列化；誰讓人家是“親兒子”呢，即便是看在人家“爹”的份兒上，也得給人家?guī)追置孀樱?/span>

尤其是在我們需要序列化的對(duì)象類型有限，同時(shí)又對(duì)速度和體積有很高的要求的時(shí)候，我們不妨試一下自己來處理對(duì)象的序列化；因?yàn)檫@樣我們可以根據(jù)要序列化對(duì)象的實(shí)際內(nèi)容來決定具體如何去處理，甚至可以使用一些取巧的方法，即使這些方法對(duì)其他的對(duì)象類型并不適用；

有一點(diǎn)我們可以相信，就是我們總能在特定的場(chǎng)景下設(shè)計(jì)出一個(gè)極致的方案！