高併發網站的設計架構的一些通用性原則及技巧

高併發網站的設計架構的一些通用性原則及技巧

高併發網站的設計架構的一些通用性原則及技巧

設計高併發架構需要注意的一些因素與要點：

1,負載均衡架構
    首先網站前端需要採用負載均衡群集解決用戶高併發的響應，目前常用方法包括 a、squid反向代理，這也是各大網站常用的方法，包括sohu、sina…；b、DNS輪循；c、采四層硬體設備，包括google、baidu使用這種方式。。。對於lvs，小頻道或不重要應用可以嘗試使用，對於大流量、實時性要求高的網站目前還不成熟。


2,高性能中間件選擇、優化
    中間件選擇、優化非常重要，當服務流量大於一定承度時，性能的稍微提升，對於整體硬體成本控制、服務的整體性能提升都是非常可觀的。對於web server 目前常用的屬apache，但apache 多進程(線程池)架構有一些缺點，進程頻繁生成\註銷系統開銷大，特別當流量大時更是明顯，對於應用邏輯簡單的可以考慮lighttpd 採用單進程+epoll併發模式，效率高，但對多CPU支持有問題，但可採用啟多服務解決這個問題；如果由於應用架構原因必須使用apache，可考慮apache module 性能比普通CGI成倍提升。。。其它原則，包括各中間件各版本測試、包括性能、安全上的考良，找到平衡點，不要太關注某一點因素，導致整體架構上出現隱患，另外一點非常重要，那就中間件的參數優化，這些方面大家可以google、baidu上找找，比較多，但有個原則那就是需要根據伺服器實際資源情況進行優化，如httpd最大進程數設多大合適呢？有些朋友，就隨手來個2048，覺得這樣肯定不會再出現httpd由於進程閥值過低導致拒絕服務，但這有個隱患，因為生成進程，是需要硬體資源的，當進程數達到一定承度，可能伺服器內存會溢出，導致伺服器crash，特別是內存消耗量大的應用。這樣的案例很多，需謹記
3,擴展性問題
     擴展性對於高速發展期間的網站非常重要，大家可以經常在網上看到某某網站的發展勵途，那簡直就是一部進化史，過程曲折而痛苦~~。因此成熟的經驗就非常重要了，擴展性可以從兩個方面來看：網路系統上的擴展性及應用本身的擴展性，首先在網路上需層次分明，盡量扁平化，全網冗餘不能存在故障點，盡量按業務類型進行劃分網路結構(pv大小、優先順序)防止互擾，重要的一點：網路設計中，簡單就是美~~，在不影響擴展性的前提下，不要搞得太複雜；網路硬體資源、機架位、IDC都需提前至少半年進行規劃，這些規劃的重要依據是公司業務發展的前景評估，這就體現公司的戰略眼光了，包括是否需要外地IDC（依用戶群體而定）。。。；另外，選一個好點的IDC是非常必要的，否則就得疲於IDC遷移了，北京地區好IDC還是不少的：皂君廟（有點老了。）、土城、聯通、酒仙橋、愛立信、互聯世紀、奧運官方機房數字北京據說馬上也能入駐了。。。當然了，有錢也能像google一樣自已搞個IDC，國內誰有這個實力?
     另一點就是應用本身的擴展性了，原則其實很簡單，應用設計時應盡量確保應用的層次化、採用高性能的中間件、邏輯複雜及大數據量交互的功能盡量做成獨立模塊\後台、cache層、資料庫分層（讀/寫操作分離），不要圖前期簡單直接將功能全部揉進前端CGI中，這很致命，隨時都可能會遇到性能瓶頸、而且毫無擴展性。。。
      當以上兩點很好的解決后，現在唯一的問題就是每半年根據業務的PV增漲、新業務發展，預購伺服器了。。。；當然了，對現有架構優化，性能提升才是根本解決之道，特別是現在全球經濟不景氣，大家都不好過，這就是運維工程師的責任了，優化再優化!

4,應用設計、開發中的注意點
    架構層設計好后，應用層設計就是我們重點關注對象了，這也是一個項目成功的關鍵，好的設計主要體現在：性能(高併發承載能力)、可擴展性、可維護、安全性（數據完整性、應用穩定性、前端應用安全如SQL注入。）、模塊冗餘、負載均衡等等，技術點：線程池、epoll、TCP(長/短)連接的選擇、功能模塊的細化及後台化、模塊冗餘/負載均衡考慮(可擴展性)、高頻數據cache緩存、數據分層、應用單故障點的解決(數據唯一性問題)等。
    有兩點要注意：(1)應用設計時要允分考慮伺服器、硬體設備甚基於IDC的不可靠性；也就是說我們在應用設計時需要考慮到應用運行過程中，隨時都可能會有1~2台伺服器或更多伺服器出現故障情況(網路故障、災難、攻擊、停電(整個IDC全掛))，
    如google GFS就是一個典型，我們不能將應用的穩定性寄託於硬體的穩定上，特別是門戶型公司大部份採用的都是X86普通機型，伺服器crash是家常便飯、隨時隨刻(當總量到一定量級時)，所以我們在做應用架構設計時需允分考慮這些問題發生時的對策，做到允分的冗餘/負載均衡（這兩點可統一），如多IDC間通過智能CDN的流控、單IDC應用模塊多節點冗餘/負載均衡等，即使某些應用由於特殊原因無法做到這點，也需允分考慮應急預案。好的設計在這些突發情況下可以做到不用人工干預，當然難度也很大。記得李開復在北大演講時說過：google一個IDC同時故障800台機器，不會影響到任何應用的正常響應；(2)大流量應用/模塊中能不使用資料庫就不要使用資料庫.

5,資料庫問題
    如資料庫緩存，在高併發高處理的時候,在整個應用程序下，緩存是全局共享的，然而在我們進行修改的時候就，如果兩個或者多個請求同時對緩存有更新的要求的情況下，應用程序會直接的死掉。這個時候，就需要一個好的數據併發處理策略以及緩存策略。
    資料庫的死鎖問題，死鎖在高併發的情況下的出現的概率是非常高的.還有就是考慮圖片伺服器分離,資料庫集群和庫表散列,鏡像等

6,用戶分地域優化問題
     這就根據某個地域用戶集中訪問進行相應的設制策略.等服務了。

本文來至：http://www.anyiwa.com/?p=538 如有轉載請附此鏈接，謝謝

Tags: