大型web系統數據緩存設計

1. 前言

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

2. 資料庫的瓶頸

2.1 數據量

關係型資料庫的數據量是比較小的，以我們常用的MySQL為例，單表數據條數一般應該控制在2000w以內，如果業務很複雜的話，可能還要低一些。即便是對於Oracle這些大型商業資料庫來講，其能存儲的數據量也很難滿足一個擁有幾千萬甚至數億用戶的大型互聯網系統。

2.2 TPS

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

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

2.3 響應時間

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

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

3. 緩存系統選型

3.1 緩存的類型

3.1.1 本地緩存

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

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

3.1.2 分散式緩存

前面提到過，本地緩存的使用很容易讓你的應用伺服器帶上「狀態」，這種情況下，數據同步的開銷會比較大；尤其是在集群環境中更是如此！

分散式緩存這種東西存在的目的就是為了提供比RDB更高的TPS和擴展性，同時有幫你承擔了數據同步的痛苦；優秀的分散式緩存系統有大家所熟知的Memcached、Redis（當然也許你把它看成是NoSQL，但是我個人更願意把分散式緩存也看成是NoSQL），還有國內阿里自主開發的Tair等；

對比關係型資料庫和緩存存儲，其在讀和寫性能上的差距可謂天壤之別；memcached單節點已經可以做到15w以上的tps、Redis、google的levelDB也有不菲的性能，而實現大規模集群後，性能可能會更高！

所以，在技術和業務都可以接受的情況下，我們可以盡量把讀寫壓力從資料庫轉移到緩存上，以保護看似強大，其實卻很脆弱的關係型資料庫。

3.1.3 客戶端緩存

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

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

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

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

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

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

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

3.1.4 資料庫緩存

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

3.2 選型指標

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

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

下邊幾點是我個人覺的應該考慮的幾個點（其實大部分系統選型都是這麼考慮的，並非只有緩存系統）：

3.2.1 容量

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

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

3.2.2 並發量

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

我們之所以需要緩存系統，就是要它在關鍵時刻能抗住我們的數據訪問量的；所以，緩存系統能夠支撐的並發量是一個非常重要的指標，如果它的性能還不如關係型資料庫，那我們就沒有使用的必要了。

對於淘寶的系統來說，我們不妨按照下邊的方案來估算並發量：

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

這裡我們是按照一天8個小時來計算的，這個值基於一個互聯網站點的訪問規律得出的，當然，如果你不同意這個值，可以自己定義。

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

在計算出平均值之後，再乘以一個峰值係數，基本就可以得出你的緩存系統需要承受的最高QPS，一般情況下，這個係數定在10以內是合理的。

3.2.3 響應時間

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

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

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

3.2.4 使用成本

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

首先服務端，優秀的系統要是能夠方便部署和方便運維的，不需要高端硬體、不需要複雜的環境配置、不能有過多的依賴條件，同時還要穩定、易維護；

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

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

3.2.5 擴展性

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

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

客戶端負載均衡

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

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

服務端負載均衡

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

但這樣做會帶來另外一個問題，就是中心配置伺服器會成為一個單點。解決辦法就將中心配置伺服器由一台變為多台，採用雙機stand by方式或者zookeeper等方式，這樣可用性也會大大提高。

3.2.6 容災

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

並不是所有的緩存系統都具有容災特性的，所以我們在選擇的時候，一定要根據自己的業務需求，對緩存數據的依賴程度來決定是否需要緩存系統的容災特性。

3.3 常見分散式緩存系統比較

3.3.1 Memcached

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

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

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

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

3.3.2 Redis

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

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

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

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

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

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

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

3.3.3 淘寶Tair

Tair是淘寶自主開發並開源的一款的緩存系統，而且也是一套真正意義上的分散式並且可以跨多機房部署，同時支持內存緩存和持久化存儲的解決方案；我們數平這邊也有自己的改進版本。

Tair實現了緩存框架和緩存存儲引擎的獨立，在遵守介面規範的情況下，可以根據需求更換存儲引擎，目前支持mdb（基於memcached）、rdb（基於Redis）、kdb（基於kyoto cabinet，持久存儲，目前已不推薦使用）和rdb（基於gooogle的levelDB，持久化存儲）幾種引擎；

由於基於mdb和rdb，所以Tair能夠間距兩者的特性，而且在並發量和響應時間上，也接近二者的裸系統。

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

3.3.4 內存資料庫

這裡的內存資料庫只要是指關係型內存資料庫。一般來說，內存資料庫使用場景可大致分為兩種情況：

一是對數據計算實時性要求比較高，基於磁碟的資料庫很難處理；同時又要依賴關係型資料庫的一些特性，比如說排序、加合、複雜條件查詢等等；這樣的數據一般是臨時的數據，生命周期比較短，計算完成或者是進程結束時即可丟棄；

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

但不管是在哪種場景中，存在於內存資料庫中的數據都必須是相對獨立的或者是只服務於讀請求的，這樣不需要複雜的數據同步處理。

3.4 緩存的設計與策略

3.4.1 緩存對象設計

3.4.1.1 緩存對象粒度

對於本地磁碟或分布是緩存系統來說，其緩存的數據一般都不是結構化的，而是半結構話或是序列化的；這就導致了我們讀取緩存時，很難直接拿到程序最終想要的結果；這就像快遞的包裹，如果你不打開外層的包裝，你就拿不出來裡邊的東西；

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

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

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

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

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

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

3.4.1.2 緩存對象結構

同緩存粒度一樣，緩存的結構也是一樣的道理。對於一個緩存對象來說，並不是其粒度越小，體積也越小；如果你的一個字元串就有1M大小，那也是很恐怖的；

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

所以，根據具體應用場景去為緩存對象設計一個更合適的存儲結構，也是一個很值得注意的點。

3.4.2 緩存更新策略

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

3.4.2.1 被動失效

一般來說，緩存數據主要是服務讀請求的，並設置一個過期時間；或者當資料庫狀態改變時，通過一個簡單的delete操作，使數據失效掉；當下次再去讀取時，如果發現數據過期了或者不存在了，那麼就重新去持久層讀取，然後更新到緩存中；這即是所謂的被動失效策略。

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

3.4.2.2 主動更新

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

在集群環境下，多台應用伺服器同時訪問一份數據是很正常的，這樣就會存在一台伺服器讀取並修改了緩存數據，但是還沒來得及寫入的情況下，另一台伺服器也讀取並修改舊的數據，這時候，後寫入的將會覆蓋前面的，從而導致數據丟失；這也是分散式系統開發中，必然會遇到的一個問題。解決的方式主要有三種：

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

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

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

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

3.4.3 數據對象序列化

由於獨立於應用系統，分散式緩存的本質就是將所有的業務數據對象序列化為位元組數組，然後保存到自己的內存中。所使用的序列化方案也自然會成為影響系統性能的關鍵點之一。

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

a 序列化速度；即對一個普通對象，將其從內存對象轉換為位元組數組需要多長時間；這個當然是越快越好；

b對象壓縮比；即序列化後生成對象的與原內存對象的體積比；

c支持的數據類型範圍；序列化框架都支持什麼樣的數據結構；對於大部分的序列化框架來說，都會支持普通的對象類型，但是對於複雜對象（比如說多繼承關係、交叉引用、集合類等）可能不支持或支持的不夠好；

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

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

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

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

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

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

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

單位：位元組

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

單位：納秒

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

Java源生序列化

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

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

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

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

c、 如果類有繼承關係，則要對所有父類進行前述a和b步驟的處理；

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

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

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

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

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

Hessian

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

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

為了標誌屬性區段的結束，Hessian使用了長度欄位來表示，這在一定程度上會增大結果數據的體積；

由於Hessian相較於Java源生序列化並沒有太大的優勢，所以一般情況下，如果系統中沒有使用Hessian的rpc框架，則很少單獨使用Hessian的序列化機制。

Google Protobuf

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

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

對於對象屬性，GPB並沒有直接存儲屬性名稱，而是根據schema文件中的映射關係，只保存該屬性的順序id；而對於，GPB針對常用的幾種數據類型採用了不同程度的壓縮，同時屬性區段之間採用特定標記進行分隔，這樣可以大大減少存儲所佔用的空間。

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

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

Kryo

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

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

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

如何選擇？

就Java原生序列化功能而言，雖然它性能和體積表現都非常差，但是從使用上來說卻是非常廣泛，只要是使用Java的框架，那就可以用Java原生序列化；誰讓人家是「親兒子」呢，即便是看在人家「爹」的份兒上，也得給人家幾分面子！

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

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