原文地址：http://www.wmyouxi.com/a/60368.html#ixzz3tGYG9JwC

1.?前言

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

?

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

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

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

?

2.2 TPS

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

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

?

2.3?響應時間

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

那么這個問題如何解決呢？最簡單有效的辦法當然是緩存！

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

3.1?緩存的類型

3.1.1?本地緩存

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

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

3.1.2?分布式緩存

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

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

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

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

?

3.1.3?客戶端緩存

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

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

?

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

?

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

?

d、?html5的本地存儲；鑒于html5越來越普及，再加上其本地存儲功能比較強大，所以在將來的使用場景應該會越來越多。

?

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

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

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

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

?

3.2?選型指標

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

既然有這么多的系統(tǒng)可用，那么我們在選擇的時候，就要有一定的標準和方法。只有有了標準，才能衡量一個系統(tǒng)時好時壞，或者適不適合，選擇就基本有了方向。

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

?

3.2.1?容量

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

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

?

3.2.2?并發(fā)量

這里說并發(fā)量，其實還不如說是QPS更貼切一些，因為我們的緩存不是直接面向用戶的，而只面向應用的，所以肯定不會有那個高的并發(fā)訪問（當然，多個系統(tǒng)共用一套緩存那就另當別論了）；所以我們關(guān)心的是一個緩存系統(tǒng)平均每秒能夠承受多少的訪問量。

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

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

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

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

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

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

?

3.2.3?響應時間

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

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

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

?

3.2.4?使用成本

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

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

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

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

?

3.2.5?擴展性

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

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

?

客戶端負載均衡

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

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

?

服務端負載均衡

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

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

?

3.2.6?容災

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

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

?

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

3.3.1 Memcached

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

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

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

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

?

3.3.2 Redis

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

下面就簡單介紹下Redis的一些特性；

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

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

Redis支持“集群”，這里的集群還是要加上引號的，因為目前Redis能夠支持的只是Master-Slave模式；這種模式只在可用性方面有一定的提升，當主機宕機時，可以快速的切換到備機，和MySQL的主備模式差不多，但是還算不上是分布式系統(tǒng)；

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

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

?

3.3.3?淘寶Tair

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

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

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

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

?

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

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

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

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

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

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

3.4.1?緩存對象設(shè)計

3.4.1.1?緩存對象粒度

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

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

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

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

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

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

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

?

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

同緩存粒度一樣，緩存的結(jié)構(gòu)也是一樣的道理。對于一個緩存對象來說，并不是其粒度越小，體積也越小；如果你的一個字符串就有1M大小，那也是很恐怖的；

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

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

?

3.4.2?緩存更新策略

緩存的更新策略主要有兩種：被動失效和主動更新，下面分別進行介紹；

?

3.4.2.1?被動失效

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

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

?

3.4.2.2?主動更新

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

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

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

?

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

?

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

?

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

?

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

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

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

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

?

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

?

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

?

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

?

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

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

首先我們先針對幾組框架來做一個簡單的對比測試，看看他們在對象壓縮比和性能方面到底如何；

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

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

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

單位：字節(jié)

工具	Java	Hessian	ProtoBuf	Kryo
僅數(shù)字	392	252	59	56
數(shù)字?+?字符串	494	351	161	149

?

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

單位：納秒

工具	Java	Hessian	ProtoBuf	Kryo
僅數(shù)字	8733	6140	1154	2010
數(shù)字?+?字符串	12497	7863	2978	2863

?

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

?

Java源生序列化

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

?

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

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

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

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

d、?如果屬性中有復雜類型，這還要對這些對象進行a、b、c步驟的處理；

e、?記錄List、Set、Map等集合類的描述信息，同時要對key或value中的復雜對象進行a、b、c、d步驟的操作

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

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

下面就基本是各個工具針對Java弱點的改進了。

?

Hessian

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

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

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

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

?

Google Protobuf

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

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

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

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

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

?

Kryo

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

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

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

?

如何選擇？

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

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

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

1.?前言

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

?

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

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

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

?

2.2 TPS

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

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

?

2.3?響應時間

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

那么這個問題如何解決呢？最簡單有效的辦法當然是緩存！

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

3.1?緩存的類型

3.1.1?本地緩存

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

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

3.1.2?分布式緩存

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

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

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

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

?

3.1.3?客戶端緩存

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

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

?

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

?

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

?

d、?html5的本地存儲；鑒于html5越來越普及，再加上其本地存儲功能比較強大，所以在將來的使用場景應該會越來越多。

?

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

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

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

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

?

3.2?選型指標

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

既然有這么多的系統(tǒng)可用，那么我們在選擇的時候，就要有一定的標準和方法。只有有了標準，才能衡量一個系統(tǒng)時好時壞，或者適不適合，選擇就基本有了方向。

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

?

3.2.1?容量

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

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

?

3.2.2?并發(fā)量

這里說并發(fā)量，其實還不如說是QPS更貼切一些，因為我們的緩存不是直接面向用戶的，而只面向應用的，所以肯定不會有那個高的并發(fā)訪問（當然，多個系統(tǒng)共用一套緩存那就另當別論了）；所以我們關(guān)心的是一個緩存系統(tǒng)平均每秒能夠承受多少的訪問量。

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

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

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

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

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

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

?

3.2.3?響應時間

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

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

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

?

3.2.4?使用成本

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

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

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

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

?

3.2.5?擴展性

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

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

?

客戶端負載均衡

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

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

?

服務端負載均衡

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

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

?

3.2.6?容災

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

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

?

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

3.3.1 Memcached

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

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

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

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

?

3.3.2 Redis

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

下面就簡單介紹下Redis的一些特性；

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

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

Redis支持“集群”，這里的集群還是要加上引號的，因為目前Redis能夠支持的只是Master-Slave模式；這種模式只在可用性方面有一定的提升，當主機宕機時，可以快速的切換到備機，和MySQL的主備模式差不多，但是還算不上是分布式系統(tǒng)；

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

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

?

3.3.3?淘寶Tair

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

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

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

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

?

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

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

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

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

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

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

3.4.1?緩存對象設(shè)計

3.4.1.1?緩存對象粒度

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

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

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

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

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

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

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

?

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

同緩存粒度一樣，緩存的結(jié)構(gòu)也是一樣的道理。對于一個緩存對象來說，并不是其粒度越小，體積也越小；如果你的一個字符串就有1M大小，那也是很恐怖的；

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

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

?

3.4.2?緩存更新策略

緩存的更新策略主要有兩種：被動失效和主動更新，下面分別進行介紹；

?

3.4.2.1?被動失效

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

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

?

3.4.2.2?主動更新

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

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

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

?

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

?

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

?

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

?

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

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

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

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

?

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

?

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

?

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

?

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

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

首先我們先針對幾組框架來做一個簡單的對比測試，看看他們在對象壓縮比和性能方面到底如何；

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

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

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

單位：字節(jié)

工具	Java	Hessian	ProtoBuf	Kryo
僅數(shù)字	392	252	59	56
數(shù)字?+?字符串	494	351	161	149

?

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

單位：納秒

工具	Java	Hessian	ProtoBuf	Kryo
僅數(shù)字	8733	6140	1154	2010
數(shù)字?+?字符串	12497	7863	2978	2863

?

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

?

Java源生序列化

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

?

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

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

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

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

d、?如果屬性中有復雜類型，這還要對這些對象進行a、b、c步驟的處理；

e、?記錄List、Set、Map等集合類的描述信息，同時要對key或value中的復雜對象進行a、b、c、d步驟的操作

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

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

下面就基本是各個工具針對Java弱點的改進了。

?

Hessian

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

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

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

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

?

Google Protobuf

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

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

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

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

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

?

Kryo

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

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

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

?

如何選擇？

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

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/5018375.html

總結(jié)

以上是生活随笔為你收集整理的大型web系统数据缓存设计-l转载的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。