高併發大型網站架構設計思路（待補充）

一個大型的網站網站應該由以下6個子系統組成

負載均衡系統

反向代理系統

Web服務器系統

分佈式存儲系統

底層服務系統

數據庫集羣系統

爲何要作高併發系統設計？

事實上，針對於任何單一的網絡服務器程序，其可承受的同時鏈接數目是有理論峯值的，經過C＋＋中對TSocket的定義類型：word，咱們能夠判 定這個鏈接理論峯值是65535，也就是說，你的單個服務器程序，最多能夠承受6萬多的用戶同時鏈接。可是，在實際應用中，能達到一萬人的同時鏈接並能保 證正常的數據交換已是很不容易了，一般這個值都在2000到5000之間，能達到上萬已經很不錯了。目前的門戶網站動輒幾千萬的訪問量，因此，高併發的 系統架構在所不免。

總體架構

真實中的網站架構也許並不如此也能夠實現高性能。可是高性能的網站莫不過如此。以下圖所示。

第一 負載均衡系統

負載均衡系統分爲硬件和軟件兩種。

硬件負載均衡效率高，可是價格貴，好比F5等。

軟件負載均衡系統價格較低或者免費，效率較硬件負載均衡系統低，不過對於流量通常或稍大些網站來說也足夠使用，好比lvs。

第二 反向代理系統

目前廣泛使用Squid或者nginx,或者Lighttpd，Varish。

這四者又各自有很大的差別。

Squid：主要用來作反向代理，使用內存+硬盤

Nginx：能夠反向代理+負載均衡+WWW解析

Lighttpd：反向代理能力通常，處理FastCGI比較好，消耗內存很小

Varish：主要作內存的反向代理，性能最優

第三 Web服務器系統

由Apache負責解析PHP內容，也能夠用Nginx，或者Lighttpd，相對來講Apache比較穩定。

 

第四 分佈式存儲系統

存儲量很大，常常會達到單臺服務器沒法提供的規模，好比相冊、視頻等應用。所以須要專業的大規模存儲系統。

 

第五 底層服務系統

根據各自須要由C/C++開發設計供上層CGI調用。

 

第六 數據庫系統

1)使用MySQL數據庫，考慮到Web應用的數據庫讀多寫少的特色，咱們主要對讀數據庫作了優化，提供專用的讀數據庫和寫數據庫，在應用程序中實現讀操做和寫操做分別訪問不一樣的數據庫。

2)使用同步機制實現快速將主庫(寫庫)的數據庫複製到從庫(讀庫)。一個主庫對應多個從庫，主庫數據實時同步到從庫。

3)寫數據庫有多臺，每臺均可以提供多個應用共同使用，這樣能夠解決寫庫的性能瓶頸問題和單點故障問題。

 

 

客觀地說，開源的框架作得更好。Openfire 應該是目前最火熱的，它只是一個平臺，你能夠在此平臺基礎上作二次加強，支持集羣等企業級能力。 偷偷的說，我知道的幾家中型企業，就用這個作運營平臺中的即時通信部分，量級約50萬。 若是你不是運營級要求，就用這個應該是差很少了的。 若是非要自行開發，那麼給你以下建議：◎ 分離：登陸服務器、通信服務器、消息服務器 和 數據庫服務器；◎ 登陸服務器（有狀態）：除給Client提供登陸和分配通信服務器外，重點功能是提供關於用戶目前鏈接在哪臺服務器上的查詢，因此全部查詢基本基於緩存完成；考慮到單點故障問題，登陸服務器應雙機冗餘，但不能太多，不然雙機之間的緩存同步代價過高；緩存可以使用開源組件。◎ 通信服務器（有狀態）：負責維護消息長鏈接，以及消息的收發；通信服務器緩存自身的全部用戶鏈接信息，和部分（這個要時狀況動態調整）非自身的熱點用戶鏈接信息（即該用戶連在哪臺通信服務器上）；消息到達時，將消息轉發給消息服務器進行落地；而後根據目標最終用戶先查詢本地表，查不到就去查詢登陸服務器；而後直接尋找目標通信服務器，發送消息到達的通知；通信服務器的問題是沒有Failover，可是也不重要，客戶端鏈接不上就由登陸服務器從新分配新的通信服務器來提供服務便可。◎ 消息服務器（無狀態）：負責接收通信服務器所發來的消息，批量寫入數據庫中，以及供其它消息服務器存取；另外也提供歷史消息查詢這類輔助性功能；由於是無狀態，因此集羣較爲簡單，略。◎ 數據庫服務器：略。