前言：最近在與廣東網際網路基地一起進行無線城市集中平臺的建設，在系統設計、架構調優上做了很多的探索，也在系統整合測試和效能調優中遭遇了很多的煩惱，心裡有一些所得所悟，希望與大家共同學習探討。

WEB系統最容易出現效能故障的點在哪裡？ 有很多人對此不知其然，或知其然而不知其所以然。

下面這張圖，是在一個大型的WEB系統設計中，經典的架構設計和分層模式。

1） 前端負載均衡： 有錢的用硬體四層交換（想當年雅虎中國2000臺伺服器，只用了四臺Alteon就搞定了），沒錢的用軟體負載均衡（LVS、Nginx）

2） 多級快取：首先要充分利用瀏覽器的快取能力，也就是Cookie，然後要在服務端利用頁面快取機制，前些年大家喜歡用Squid

，現在Varnish更流行起來了，有一個牛逼的故事是挪威的最大的線上報紙 Verdens Gang(vg.no) 使用 3 臺 Varnish 代替了原來的 12 臺 Squid，效能比以前更好，這是 Varnish 最成功的應用案例。 最後一個快取點是在資料庫前方設定，讓那些經常需要被查詢，但是實時性要求不那麼高的資料快取起來，避免對資料庫的頻繁查詢。三級快取可以有效的提升整個系統的效能。

3）應用伺服器層面：先考慮一下你的靜態頁面與動態頁面的佔比，然後考慮一下如何儘量實現動態頁面靜態化，把靜態的部署到Apache上，動態的部署到Tomcat上吧。如果你是一個像Flicker那樣的圖片共享網站，必須考慮設定單獨的圖片伺服器，這是淘寶血淚史告訴我們的真理。

4）現在要考慮資料庫的選型問題了：採用關係型資料庫還是非關係型資料庫完全取決於你的業務場景，如果你要實現實時要求高，資料一致性要求高的場景，關係型資料庫；如果你要實現海量資料的查詢和高併發，非關係型資料庫（考慮Facebook一張表有一億使用者，如果用關係型資料庫查詢。磁碟IO也快撐不住了，而非關係型資料庫則完全沒有這個問題）；

5）資料庫效能問題之外務必考慮清楚資料庫的併發效能：通常會採用生產資料庫與查詢資料庫分離的方式，也就是著名的MySQL的單主多從服務方式。為了實現高可用性HA，有的網站比如淘寶網，在Master之間也會實現叢集部署。

6）資料庫叢集和庫表雜湊: 上面提到的資料庫叢集由於在架構,

成本,擴張性方面都會受到所採用DB型別的限制,於是我們需要從應用程式的角度來考慮改善系統架構,庫表雜湊是常用並且最有效的解決方案，在應用程式中將資料庫進行分離,不同的模組對應不同的資料庫或者表,再按照一定的策略對某個頁面或者功能進行更小的資料庫雜湊,比如使用者表,按照使用者 ID 進行表雜湊,這樣就能夠低成本的提升系統的效能並.且有很好的擴充套件性，sohu 的論壇就是採用了這樣的架構.