淘寶的可伸縮高性能互聯網架構

一 應用無狀態（淘寶session框架） 

         假如在session中保存了大量與客戶端的狀態信息，保存狀態信息的server宕機時，通常通過集群解決，不僅有負載均衡，更重要的是要有失效恢復 failover，tomcat用集群節點廣播復制，jboss用配對復制等session狀態復制策略，但嚴重影響系統的伸縮性，不能通過增加更多的機器達到良好的水平伸縮，因為集群節點間session通信隨著節點的增多而開銷增大，因此要想做到應用本身的伸縮性，要保證應用無狀態，這樣集群中的各個節點來說都是相同的，使系統更好的水平伸縮。 

        淘寶的session框架用clientcookie實現，將狀態保存到cookie里，使應用節點本身不要保存狀態信息，這樣在系統用戶變多的時候，就可以通過增加更多的應用節點來達到水平擴展的目的。 但有限制，比如每個cookie一般不能超過4K的大小，很多瀏覽器都限制一個站點最多保存20個cookie。 

         淘寶cookie框架是“多值cookie”，一個組合鍵對應多個cookie的值，可以防止cookie數量超過20，還節省了cookie存儲有效信息的空間。 

     除了淘寶目前的session框架的實現方式以外，其實集中式session管理來完成，說具體點就是多個無狀態的應用節點連接一個session 服務器，session服務器將session保 存到緩存中，session服務器后端再配有底層持久性數據源，比如數據庫，文件系統等等。 

二 有效使用緩存（Tair） 

     瀏覽器緩存，反向代理緩存，頁面緩存，局部頁面緩存，對象緩存等等 

     大部分情況都是讀緩存,讀寫比不高，對數據安全性需求不高的數據，將其緩存，減少對數據庫訪問。店鋪系統，如店鋪介紹，店鋪服務條款，寶貝詳情,適合放到緩存中，減少DB的負載。 

三 應用拆分（HSF） 

         拆分（也算是一種解耦），將原來的系統根據一定的標準，比如業務相關性等分為不同的子系統，提高系統擴展性和可維護性，系統的水平伸縮性提升，可以有針對性的對壓力大的子系統進行水平擴展而不影響到其它的子系統。 

         子系統之間的耦合減低了，當某個子系統暫時不可用的時候，整體系統還是可用的，從而整體系統的可用性也大大增強了。 

         拆分也給系統帶來了問題，子系統之間如何通信。一般有同步通信和異步通信，這個時候高性能的遠程調用框架就顯得非常重要。 

四 數據庫拆分（TDDL） 

         應用除了應用級別的拆分以外，另外一個很重要的層面就是存儲如何拆分,通常就是所說的RDBMS進行拆分。 

         數據庫讀取壓力太大，就是到了讀寫分離的時候，配置一個server為master節點，然后配幾個salve節點，通過讀寫分離，使得讀取數據的壓力分攤到了不同的salve節點上面，系統恢復正常。 

         到了master負載太高時就要垂直分區了（就是所謂的分庫），比如將商品信息，用戶信息，交易信息分別存儲到不同數據庫，同時還可以針對商品信息的庫采用master，salve模式，分庫后，各個按照功能拆分的數據庫寫壓力被分擔到了不同的server上面，數據庫的壓力終又恢復到正常狀態。 

         用戶量的不斷增加，系統中某些表異常龐大，比如好友關系表，店鋪參數配置表等，這個時候無論是寫入還是讀取這些表的數據，對數據庫來說都是一個很耗費精力的事情，此時就要進行“水平分區”了（俗話說的分表，或者說sharding）。 

         數據庫是系統中最不容易scale out的一層。 

         大型的應用必然會經過一個從單一DB server,到Master/salve,再到垂直分區（分 庫），然后再到水平分區（分表，sharding）的過程，而在這個過程中，Master/salve 以 及垂直分區相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區join查 詢數據，如何平衡各個shards的 負載等等，這個時候就需要一個通用的DAL框架來屏蔽底層數據存儲對應用邏輯的影響，使得底層數據的訪問對應用透明化。 

         從昂貴的高端存儲（小型機+ORACLE）切換到MYSQL后，勢必會遇到垂直分區（分庫）以及水平分區（Sharding）的問題，淘寶根據其業務特點開發了自己的TDDL框架，解決分庫分表對應用的透明化以及異構數據庫之間的數據復制。 

五 異步通信（Notify） 

         消息中間件登場,采用異步通信關系到系統的伸縮性,以及最大化的對各個子系統進行解耦。 

         異步一定是根據業務特點來的，一定是針對業務的異步，通常適合異步的場合是一些松耦合的通信場合，而對于本身業務上關聯度比較大的業務系統之間，還是要采用同步通信比較靠譜。 

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

         不是所有的數據都是結構化的，比如一些配置文件，用戶對應的動態，一次交易的快照等，一般不適合保存到RDBMS，更符合一種Key-value的結構。 

         另一類數據，數據量非常大，但實時性要求不高，此時這些數據也需要通過另外的一種存儲方式進行存儲，一些靜態文件，比如各個商品的圖片，商品描述等信息，這些信息因為比較大，放入RDBMS會引起讀取性能問題，影響其它數據讀取性能，也要和其它信息分開存儲，一般的選擇分布式文件系統。 

       隨著互聯網的發展，業界從08年 下半年開始逐漸流行了一個概念就是NOSQL。我們都知道根據CAP理論，一致性，可用性和分區容錯性3者 不能同時滿足，最多只能同時滿足兩個。 

         傳統關系數據采用ACID事務策略，更加講究高一致性而降低了可用性的需求，但是互聯網應用往往對可用性的要求要略高于一致性的需求，這時候就要避免采用數據的ACID事務策略，轉而采用BASE(基本可用性，事務軟狀態以及最終一致性)事務策略。 

         通過最終一致性提升系統可用性，這也是目前很多NOSQL產品所采用的策略，包括非死book 的cassandra,apache hbase,google bigtable等，非常適合一些非結構化的數據，如key-value形式數據存儲，并且這些產品有個很好的優點就是水平伸縮性。 

七 監控、預警系統 

         大型分布式系統涉及各種設備，比如網絡交換機，普通PC機，各種型號的網卡，硬盤，內存等等，在數量非常多的時候，出現錯誤的概率也會變大，因此要時刻監控系統狀態。 

         監控有粒度的粗細之分： 

         粒度粗一點，對整個應用系統進行監控，網絡流量，內存利用率，IO，CPU負載，服務訪問壓力，服務的響應時間 

         細粒度一點，對應用中的某個功能，某個URL訪問量，每個頁面的PV，頁面每天占用的帶寬是多少，頁面渲染時間，靜態資源比如圖片每天占用的帶寬。 

         有了監控系統以后，更重要的是要和預警系統結合起來，比如當某個頁面訪問量增多的時候，系統能自動預警，某臺Server的CPU和內存占用率突然變大的 時候，系統也能自動預警，當并發請求丟失嚴重的時候，系統也能自動預警等等，通過監控系統和預警系統的結合可以使得能快速響應系統出現的問題，提高系統的 穩定性和可用性。