大型**,在面對大量使用者訪問、高併發請求方面，基本的解決方案集中在這樣幾個環節：使用高效能的伺服器、高效能的資料庫、高效率的程式語言、還有高效能的web容器。但是除了這幾個方面，還沒法根本解決大型**面臨的高負載和高併發問題。
1、html靜態
對於互動性要求很高的社群型別**來說，盡可能的靜態化也是提高效能的必要手段;
同時，html靜態化也是某些快取策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇 中論壇的公用設定資訊，這些資訊目前的主流論壇都可以進行後台管理並且儲存再資料庫中，這些資訊其實大量被前台程式呼叫，但是更新頻率很小，可以考慮將這 部分內容進行後台更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。
2、伺服器分離
將與頁面進行分離，這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為問題而崩潰，在應用 伺服器和伺服器上，可以進行不同的配置優化
3、資料庫集群和庫表雜湊
在應用程式中安裝業務和應用或者功能模組將資料庫進行分離，不同的模組對應不同的資料庫或者表，再按照一定的策略對某個頁面或者 功能進行更小的資料庫雜湊，比如使用者表，按照使用者id進行表雜湊，這樣就能夠低成本的提公升系統的效能並且有很好的擴充套件性
4、快取
架構方面的快取，對apache比較熟悉的人都能知道apache提供了自己的快取模組，也可以使用外加的squid模組進行快取，這兩種方式均可以有效的提高apache的訪問響應能力。
5、映象
映象是大型**常採用的提高效能和資料安全性的方式，映象的技術可 以解決不同網路接入商和地域帶來的使用者訪問速度差異，比如chinanet和edunet之間的差異就促使了很多**在教育網內搭建映象站點，資料進行定時更新或者實時更新。在映象的細節技術方面，這裡不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如linux上的 rsync等工具。
6、負載均衡
負載均衡將是大型**解決高負荷訪問和大量併發請求採用的終極解決辦法。
硬體四層交換
第四層交換使用第三層和第四層資訊包的報頭資訊，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就象是虛ip，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有http、ftp、nfs、telnet或其他協議。這些業務在物理伺服器基礎上，需要複雜的載量平衡演算法。在ip世界，業務型別由終端tcp或udp埠位址來決定，在第四層交換中的應用區間則由源端和終端ip位址、tcp和udp埠共同 決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如alteon、f5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的效能和很靈活的管理能力。yahoo中國當初接近2000臺伺服器使用了三四臺alteon就搞定了。
軟體四層交換
大家知道了硬體四層交換機的原理後，基於osi模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過效能稍差。
軟體四層交換我們可以使用linux上常用的lvs來解決，lvs就是linux virtual server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬vip配置和管理功能，可以同時滿 足多種應用需求，這對於分布式的系統來說必不可少。
乙個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型**包括搜尋引擎上被採用，這樣的架構低成本、高效能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。
高併發解決方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發解決方案
將靜態資源分離到靜態站，對靜態資源的請求打到靜態站，增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來，使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊，再次請求時直接從快取中獲取，不需要重新生成，頁面快取記憶體中，提高訪問速度 具有相同處理功能的伺...
高併發解決方案
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...