關於大型web服務器的設計思路

大型網站，好比門戶網站，在海量用戶訪問、高併發請求方面，基本的解決方案是如下幾點：
  一、高性能的數據庫(oracle/db2/mysql...)
  二、高性能的Web容器(weblogic/apache...)
  三、高效率的編程語言(java/C#)
  四、使用高性能的服務器(小型機、PC服務器)
  五、集羣分佈式運行（好比上百臺小型機器在線運行）

可是在在線用戶上百萬，日點擊量超億，而數據達幾十T，甚至日數據量就達到T級別這種狀況下仍是難以解決
大型網站面臨的高負載和高併發問題。
   本人也常常關注這方面的解決方案，結合本身的經驗。總結了一部分經常使用的設計，但願各位多多指點。

1、設計上有足夠彈性
  這是在前期架構設計師要足夠考慮到的。最終目的是經過物理設備的線性投入來應付業務量的增加，而不止於受到技術框架應用部署的限制，甚至推到重來，這樣的結構設計就是彈性的設計，固然這裏還包括業務上的彈性設計（目前的開發模式、架構設計在很大程度上也是爲了解決這個問題）。
  通常企業也是極力避免這種狀況的發生，不然失去的不只是成本投入還包括了客戶資源。

2、頁面靜態化
  即靜態html格式，這樣避免了對數據資源的訪問，同時也大大下降了應用的CPU消耗。若是能靜態頁面的信息儘可能靜態化。

三、無狀態
  這裏說的無狀態是服務器儘可能設計成無狀態的與客戶端通信，避免了佔用大量內存的狀況，但這也不是絕對的。部分應用中的狀態保留也能大大減小IO流量與數據庫的訪問壓力。看具體狀況而定。

4、數據庫集羣、橫向/縱向切分
    數據庫集羣能緩解數據庫的壓力，但節點過多又會引發寫入同步消耗過大。
    數據庫橫向切分也就是把一個業務數據按不一樣屬性（好比地域歸屬、用戶名hashcode）來平均的分到各個數據庫上。這樣控制分庫的粒度也就是控制了數據庫的分佈，能大大緩解單個數據壓力過大訪問受限的狀況，不利的狀況是常常要跨庫訪問，這樣狀況可能會變得比較複雜。
    數據庫縱向切分也就是按業務內容來分不一樣的數據庫，好比客戶資料是一個數據庫保存，而商品訂單資料又分一個數據庫保存，這樣也能把數據庫壓力分解一部分。
    經過數據庫的切分也能大大減小單個故障點的影響範圍。

5、異步批量處理
    對於非緊急數據，能夠採用異步批量處理，安排在非高峯時刻也能提升應用的使用效率。同時批量自己在實現上效率也高於單筆業務處理。

6、表的分區分段分表設計
    這是針對一個數據庫的狀況下，防止單表數據過大，採用分段分區把一張表分解到不一樣的物理設備上，提升查詢速度，而能夠按業務性質把一張表分紅多張表，分區分表能夠組合應用，這樣在DB維護上也很是有益。同時分表也能有效下降I/O鎖狀況。

7、分歷史數據庫
    對於不少網站來講海量的歷史數據是不多用到的，能夠按照業務性質，把不修改的數據遷移到專門的歷史數據庫上歸檔，好比三個月之前的交易訂單、用戶的資料修改記錄等。對於須要查詢歷史數據的狀況，能夠單獨提供這類應用來查詢歷史數據庫。這樣能避免不斷增長的交易數據帶來的性能壓力。

8、分活動和非活躍用戶
    這是按照用戶的優先級別分別存儲訪問，對於少許的活躍用戶提供高速的訪問（好比經過緩存），這樣實際上大大提升了大部分用戶請求的處理速度，實際上也大幅度下降應用壓力提升併發能力，而對於非活躍用戶繼續保留了完整的請求服務，客戶基本不會產生使用上的差別。

9、分佈式的應用
   包括前臺服務器和中間件（其實包括前面描述的多個數據庫），把壓力盡量的均勻地分佈到不少服務器上，而服務器能夠是上百臺的線性增長。

10、使用 Epoll/IOCP 來提升併發性能
    這些在遊戲類網站上很是有用，能大大提升單臺應用服務器的處理能力。結合多線程多進程多服務器處理能夠解決高併發請求的狀況。

11、創建專門的文檔服務器
    包括的頁面圖片、軟件、文檔等數據，因爲IO流量大，比較佔用應用服務器，必要的時候單獨創建服務器存放。這種對於有大量圖片的應用好比淘寶商品應該是很是有效的。

12、分查詢與更新業務數據庫
   對於更新類關鍵業務提供強有力的高效保證（這類業務相對查詢量應該比較少），而對於查詢庫則能夠提供廉價的數據庫服務。

十3、緩存
   其實全部的應用都或多或少的使用到了緩存，緩存包括 CPU /內存 /硬盤/網絡/客戶端的緩存，客戶端能夠緩存js/圖片等信息，而不用頻繁的訪問應用，內存緩存是很是有效的方式，能夠把靜態的數據放到應用內存上，而不是頻繁訪問數據庫查詢，對於簡單數據庫其實還可使用專業的緩存應用，好比memcache。

十4、海量數據使用非關係數據庫
   對於訪問記錄等數據結構簡單可靠性要求不高的數據持久化，能夠不用關係數據庫，由於數據庫提供的食物訪問一致性、隔離性、關係維護消耗了絕大部分資源，而這些功能對不是應用的要點。因此能夠考慮使用文件方式或者其餘號稱NOSQL的方式來存儲使用。

    本人認爲應用經過分佈式併發負載均衡運行能夠解決應用服務器的性能問題（經過良好的設計來保證當業務持續增長的時候經過服務器的線性增長就能解決），關鍵點是數據庫的惟一一致性要求（一份數據只能保存在一個地方，更新查詢都以它爲基礎）決定了數據庫的成本是很是高的，甚至於沒法用資金來解決（大型機也不見得能保證海量數據的訪問處理），因此只要解決了數據庫的存放問題也就能解決高性能網站的主要問題。
   上邊說了這麼多基本上仍是把數據對象分開存放、儘可能減小對於數據庫的訪問的原則提出解決方案的。
     對於系統的高可用性這裏也總結出幾條：
         A、良好成熟的框架設計（並不必定是很是先進），優秀的業務模型，高內聚低耦合的模塊功能。
         B、優化部署配置，包括數據庫的優化。
         C、預防爲主，有專門的監控負責人，能按期分析系統健康負載狀況。在問題爆發前能及時預警。
         D、有良好的單點控制與應急措施，好比當發帖很是耗性能的時候，單獨關掉「發帖」，
               保證大部分的遊覽功能。 保證客戶應用的最大化
         E、有效專業的開發管理團隊與規範的制度