淘寶高性能架構簡介

本文只是做個簡介，起拋磚引玉效果，希望能給大家一些啟發（ps：作為一線碼農，在工作中經常接觸并使用這些框架，深深為其強大功能、設計思路所折服）

1. session框架

session大家肯定都不陌生，由于HTTP協議本身是無狀態，前后兩次請求通常是沒有關聯的，但由于一些業務需求，又必須讓其有所關聯（比如登錄，不可能讓用戶每次訪問一個頁面都需要重新登錄一次，那用戶肯定會瘋掉）

此時我們就需要借助session機制，將用戶的一些信息存儲在服務端，其主鍵jsessionid存儲于客戶端的cookie中，下一次用戶發起請求時，servlet框架會根據jsessionid自動尋找關聯的信息。

但隨著互聯網的快速發展，用戶群越來越大，如何來存儲、管理龐大的session信息顯得越來越重要。

通常的作法是采用集群（多么熟悉的名詞，ho~ho~），例如tomcat采用集群節點廣播復制，jboss采用配對復制，但都嚴重影響系統的伸縮性，不能通過增加機器達到更好的水平伸縮，而且隨著節點的增加，節點間的通信也更加頻繁，勢必會造成系統內耗加大。

webX框架的基于cookie的session可以有效的解決這個問題，將信息存于客戶端瀏覽器的cookie中，而應用節點本身不保存任何狀態信息。但要注意的一點是不同的瀏覽器對cookie的支持標準不一樣，關于這塊可參照之前的文章《淺談瀏覽器cookie》。對于這個問題，我們的解決方案是“多值cookie”，一個組合鍵對應多個cookie值，可以有效將cookie的個數控制在20個以內，很大程度節省了cookie信息的存儲空間，更多精彩可參考《Request context之session指南》

2. 緩存tair

緩存，主要是為了減輕對數據庫的壓力，使用場景非常廣泛。有瀏覽器緩存、反向代理緩存、頁面緩存、對象緩存等

tair是淘寶的一個高性能、分布式、可擴展、高可用性的key-value結構的存儲系統。

     非持久化：   

          mdb引擎: 只支持key/value，單機性能7w qps（測試條件：單條記錄512字節，響應時間2ms內）

          rdb引擎: 不僅支持key/value，還支持list/hashmap/set/sortedset等復雜數據結構。

     持久化：

          kdb引擎：采用了kyoto cabinet做為引擎，性能在2000 qps單臺。

          ldb引擎：采用了leveldb做為引擎，并且自帶cache。服務器采用了ssd，性能在5w qps以上。

目前tair已經開源，開源地址：http://code.taobao.org/p/tair/src/

3. 服務化（HSF框架，dubbo）

服務化的核心就是解耦，將生產端和消費端有效拆分，借助于HSF來達成調用關聯。使用系統的整體可用性、擴展性大大增強。

舉個很形象的例子，一個業務開創之初，可能只有一個應用，但隨著業務的不斷膨脹，代碼量也越來越大，無論后期開發還是維護帶來的成本都是很高的，此時，從架構的角度會進行系統拆分，通過增加子域名的形式，借助于http請求，將不同的業務交由不同的系統來處理。

比如商品展示交由系統A處理；當用戶添寫一個購買數量，并選擇好規格屬性后，點擊“購買”按鈕，會將請求發送到系統B來處理， 無論從業務劃分、模塊定位、還是代碼開發，都鮮明不少。

現在回到我們服務化的內容來，在服務化推廣之前，底層業務通常是這樣處理，如果你想使用部門A的業務（通常要數據庫操作），首先要引入相應的jar包，尤其是底層的dal層的包（sql.xml ，接口，接口實現等），然后在應用中手動配置各種bean關系，可以說相當繁瑣。當然如果只是配置一次，再繁瑣也忍了。互聯網千變萬化，電子商務更是瞬息萬變，業務變更相當頻繁，代碼頻繁改動那更是家常便飯。想象一下，如果你的dal層jar包被十幾個業務線所依賴，如果你想改底層的dao接口實現，你是不是需要這十幾個業務線也跟著空發布一次，只是為了打包時能加載你最新的代碼。

痛苦之大難以想象。幸好有了服務化。服務化可以有效將業務收擾到服務端，對外只暴露一個接口即可，如果你想用我的業務，只需做下簡單接口配置即可，調用時，HSF框架會幫你找到對應的服務端，然后服務端會進行相應的業務處理，返回給你想要的結果，是不是清晰了很多。

dubbo已開源，地址：http://code.alibabatech.com/wiki/display/dubbo/Home

4. 數據庫拆分TDDL

現在是大數據時代，隨便一個應用，動輒就是上千萬的數據，數據庫表示壓力越來越大。分庫分表成為業務發展的不二選擇。

TDDL是淘寶開發的一套分布式數據庫訪問引擎。可以有效解決

a）數據訪問路由：數據的讀寫請求發送到最合適的地方

b）數據的多向非對稱復制：一次寫入，多點讀取

c）數據的存儲自由擴展：不再受限于單臺機器的容量瓶頸和速度瓶頸，平滑遷移

關于分庫分表可以看看iteye上的一篇文章《淘寶下單高并發解決方案》

另外tddl也開源了，開源地址：http://code.taobao.org/p/tddl-dynamic-datasource/src/trunk/

5. 異步消息（notify）

主要是借助消息中間件，采用異步通信來達到系統的伸縮性，以最大化的對各個子系統解耦。

具體是采用同步通信還異步通信，需要結合業務來衡量，如果業務本身關聯度較大，建議還是采用同步通信比較靠譜。

關于異步消息這塊，之前有過簡單整理《基于消息的分布式架構設計》

6.  非結構化數據存儲 ( TFS,NOSQL)

并非所有的數據都是結構化的,比如一些配置文件，交易的快照等，一般不適合保存到RDBMS，更符合一種Key-value的結構；另一類數據，數據量非常大，但實時性要求不高，此時這些數據也需要通過另外的一種存儲方式進行存儲。
一些靜態文件，比如各個商品的圖片，商品描述等信息，這些信息因為比較大，放入RDBMS會引起讀取性能問題，影響其它數據讀取性能，也要和其它信息分開存儲，一般的選擇分布式文件系統。

隨著互聯網的發展，08年下半年開始逐漸流行了一個概念就是NOSQL。我們都知道根據CAP理論，一致性，可用性和分區容錯性三者不能同時滿足，最多只能同時滿足兩個。
傳統關系數據庫采用ACID事務策略，更加講究高一致性而降低了可用性的需求；但互聯網應用往往對可用性的要求要略高于一致性的需求，這時候就要避免采用數據的ACID事務策略，轉而采用BASE(基本可用性，事務軟狀態以及最終一致性)事務策略

目前此類產品有非死book 的cassandra,apache hbase,google bigtable等，非常適合一些非結構化的數據，如key-value形式數據存儲，具有很好的水平伸縮性