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

一 應用無狀態（淘寶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產品所採用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，很是適合一些非結構化的數據，如key-value形式數據存儲，而且這些產品有個很好的優勢就是水平伸縮性。 

七 監控、預警系統 

         大型分佈式系統涉及各類設備，好比網絡交換機，普通PC機，各類型號的網卡，硬盤，內存等等，在數量很是多的時候，出現錯誤的機率也會變大，所以要時刻監控系統狀態。 

         監控有粒度的粗細之分： 

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

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

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