淘寶海量數據產品的技術架構（有刪減）

緩存系統不得不考慮的另外一個問題是緩存穿透與失效時的雪崩效應。緩存穿透是指查詢一個必定不存在的數據，因爲緩存是不命中時被動寫的，而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。

有不少種方法能夠有效地解決緩存穿透問題，最多見的則是採用布隆過濾器，將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。在數據魔方里，咱們採用了一個更爲簡單粗暴的方法，若是一個查詢返回的數據爲空（不論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。

緩存失效時的雪崩效應對底層系統的衝擊很是可怕。遺憾的是，這個問題目前並無很完美的解決方案。大多數系統設計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的併發請求落到底層存儲系統上。在數據魔方中，咱們設計的緩存過時機制理論上可以將各個客戶端的數據失效時間均勻地分佈在時間軸上，必定程度上可以避免緩存同時失效帶來的雪崩效應。

【1】海量數據領域涵蓋分佈式數據庫、分佈式存儲、數據實時計算、分佈式計算等多個技術方向。
對於海量數據處理，從數據庫層面來說無非就是兩點：一、壓力如何分攤，分攤的目的就是爲了把集中式變爲分佈式。二、採用多種的存儲方案，針對不一樣的業務數據，不一樣的數據特色，採用RDBMS或採用KV Store，選擇不一樣數據庫軟件，使用集中式或分佈式存儲，或者是其餘的一些存儲方案。

【2】將數據庫進行拆分，包括水平拆分和垂直拆分。
水平拆分主要解決兩個問題：一、底層存儲的無關性。二、經過線性的去增長機器，支持數據量以及訪問請求包括TPS（Transaction Per Second）、QPS（Query Per Second）的壓力增加。其方式如把一張大數據表按必定的方式拆分到不一樣的數據庫服務器上。海量數據從集中式走向分佈式，可能涉及跨多個IDC容災備份特性。

【3】阿里巴巴的數據對不一樣地域數據的處理方法。由三個產品密切配合解決：是Erosa、Eromanga和Otter。Erosa作MySQL（或其餘數據庫庫）的Bin-Log時時解析，解析後放到Eromanga。Eromanga是增量數據的發佈訂閱的產品。Erosa產生了時時變動的數據發佈到Eromanga。而後各個業務端（搜索引擎、數據倉庫或關聯的業務方）經過訂閱的方式，把時時變動的數據時時的經過Push或Pull的方式拉到其業務端，進行一些業務處理。而Otter就是跨IDC的數據同步，把數據能及時反映到不一樣的AA站。數據同步可能會有衝突，暫時是以那個站點數據爲優先，好比說A機房的站點的數據是優先的，無論怎麼樣，它就覆蓋到B的。

【4】對於緩存。
一、注意切分力度，根據業務選擇切分力度。把緩存力度劃分的越細，緩存命中率相對會越高。二、確認緩存的有效生命週期。

【5】拆分策略
一、按字段拆分（最細力度）。如把表的Company字段拆掉，就按COMPANY_ID來拆。
二、按表來拆，把一張表拆到MySQL，那張表拆到MySQL集羣，更相似於垂直拆分。
三、按Schema拆分，Schema拆分跟應用相關的。如把某一模塊服務的數據放到某一機羣，另外一模塊服務的數據放到其餘MySQL機羣。但對外提供的總體服務是這些機羣的總體組合，用Cobar來負責協調處理。

 

• 單一應用架構
  • 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
  • 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
• 垂直應用架構
  • 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
  • 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
• 分佈式服務架構
  • 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
• 流動計算架構
• 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
• 此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

幾種通訊協議比較：Socket (BIO/NIO/Netty/MINA) > RMI > HTTP Invoker >= Hessian > REST >> Burlap > EJB >> Web Service

1. 若是協議設計的比較好，Socket性能毫無疑問是最高，同時靈活性和複雜度也最高，若是採用高效的網絡框架如:Mina、Netty等能夠下降開發複雜度，通常在對性能有很是苛刻的條件下使用。
2. RMI 的性能相對略低，可是與Socket還在同1個數量級，同時只能在Java系統間通訊，若是是基於互聯網使用，還存在穿越防火牆的問題。採用Spring 封裝的方式使用比原始RMI方式性能略高，主要緣由是：Spring採用了代理和緩存機制，節省了對象從新獲取的時間。
3. HTTPInvoker是Spring特有的，只能在客戶端和服務器端都採用Spring框架下使用，與RMI本質相同，使用java的序列化技術傳輸對象，二者性能差異較小。
4. Hessian 在數據量較小時性能表現出衆，甚至比RMI還高，在數據結構複雜的對象或者大量數據對象時，較RMI要慢20%左右；Hessian的優勢是精簡高效，同 時能夠跨語言使用，目前支持Java,C++, .net, python, ruby等語言。另外Hessian能夠充分利用web容器的成熟功能，在處理大量用戶訪問時頗有優點，在資源分配、線程排隊、異常處理等方面均可以由 web容器保證，而RMI自己不提供多線程的服務器。
5. REST架構也是一種比較簡單、高效的Web服務架構，相對於Hessian性能略低，但還在同一個數量級，同時也是基於HTTP協議，目前也有比較多的成功案例。
6. Burlap 在數據量很是小時性能尚可，同時性能隨着數據量的增長急劇下降，一般性能耗時是RMI的3倍左右，主要緣由是：Hessian採用二進制傳輸數據，而 Burlap採用XML格式，而XML描述內容太多，一樣的結構，其傳輸量要大不少，同時，XML的解析是比較耗資源的，尤爲大數據量狀況下更是如此。
7. EJB基於RMI協議，性能不高，同時只能在Java系統內使用，不能跨語言，目前使用愈來愈少，目前阿里巴巴內部已經徹底放棄EJB。
8. 在 這些遠程調用協議中，Web Service的性能是最低的，通常狀況下，Web Service的性能相對於Hessian性能要慢10~20倍左右，同時，對於一樣的訪問請求，Web Service的傳輸數據量約爲Hessian的6倍左右，對網絡帶寬消耗很是大，同時XML的解碼器廣泛性能不高，XML<->Java Bean的編碼、解碼很是耗費資源，對於併發和負載比較高的網站不是一個好的選擇。同時，Web Service的使用也不太方便。

總結：Hessian和REST架構我的認爲是比較優秀的高性能通訊協議，若是對性能要求特別苛刻能夠直接採用Socket方式，目前，阿里巴巴內部的遠程調用主要採用Hessian和Dubbo(基於Mina/Netty框架)，經受了苛刻的高併發、高負載考驗。