目前的互聯(lián)網(wǎng)應(yīng)用，一個突出的焦點就是用戶量非常大，給服務(wù)器開發(fā)和設(shè)計帶來了許多挑戰(zhàn)，這里想談本人對這些問題的思考和體會.
大規(guī)模的多人在線系統(tǒng)，我接觸的比較多的，有一下幾種：
1. p2p
系統(tǒng)，p2p直播軟件，在播放比較熱點的節(jié)目時，會遇到數(shù)十萬甚至上百萬人同時觀看的問題，由于p2p的特殊性質(zhì)，一般不會去統(tǒng)一保持用戶信息，
服務(wù)器需要的只是給p2p客戶提供節(jié)目源， 以及為p2p
客戶查找其他p2p節(jié)點提供tracker服務(wù)。所以p2p在對付大規(guī)模的人數(shù)在線時，只要簡單的添加tracker
和界目源即可。這種多人在線是在軟件設(shè)計時需要考慮的最少的一種。
2. 網(wǎng)游服務(wù)器系統(tǒng)。 網(wǎng)游服務(wù)器對付這種問題的方法是， 把整個用戶空間隔離為n個世界， 譬如mmo中的某區(qū)某服， 或者休閑游戲中的房間。
當用戶量不斷增加時，只需不斷的增加服務(wù)器組和房間服務(wù)器即可。
唯一麻煩的地方，就是在于一個用戶的統(tǒng)一認證和經(jīng)濟系統(tǒng)這塊。由于這兩塊負載不大，
邏輯也相對簡單，實現(xiàn)起來難度不太大。
3. IM 系統(tǒng)， im系統(tǒng)的問題就在于，他的整個用戶空間，是完全統(tǒng)一在一起的，沒法采用區(qū)服，房間的方式來隔離。
當im服務(wù)器的在線人數(shù)突破10，20萬之后，
設(shè)計一套集群系統(tǒng)就是勢在必行的了。這個時候單臺邏輯服務(wù)器，單臺數(shù)據(jù)庫已經(jīng)無法滿足系統(tǒng)的性能要求了。
必須采用把數(shù)據(jù)，服務(wù)，分散在各個物理服務(wù)器內(nèi)，
采用集群的方式來進行管理。
當并發(fā)人數(shù)在100萬以下時，我設(shè)計的一種做法是， 后臺的db部分，采用一臺或者幾臺類似mysql proxy的服務(wù)器來統(tǒng)一進行訪問。
db 內(nèi)的數(shù)據(jù)采用按照數(shù)字賬號分段，或者按照某種hash 算法進行 分塊的存儲。 前臺的邏輯服務(wù)器，不直接和db 打交道。而是通過DB
Proxy來訪問數(shù)據(jù)庫，
這樣可以保證數(shù)據(jù)庫的存儲策略不透明，可以于前臺的邏輯部分進行獨立的變化，前臺邏輯服務(wù)器，連數(shù)據(jù)庫的表結(jié)構(gòu)都不需要知道，只需要發(fā)送請求，去DB
Proxy請求指定條件的查詢和結(jié)果集就可以了。
而邏輯服務(wù)器之間，當100萬人以下同時在線時，邏輯服務(wù)器的數(shù)目并不會太多。這些邏輯服務(wù)器之間可以直接互聯(lián)。每個邏輯服務(wù)器負責一段數(shù)字賬號的邏輯處理，每個邏輯服務(wù)器向其他服務(wù)器通報自己負責的數(shù)字段范圍。當遇到不是本服務(wù)器能處理的請求時，譬如給其他邏輯服務(wù)器上的用戶發(fā)送文本消息時，
直接轉(zhuǎn)發(fā)給其他邏輯服務(wù)器即可。
DB Proxy 在db server前端，單臺DB Proxy的處理能力畢竟有限，這里可能還要考慮每幾臺DB服務(wù)器就配置一臺DB
Proxy。每幾臺前臺邏輯服務(wù)器共享一臺DB Proxy. im
系統(tǒng)的數(shù)據(jù)庫訪問非常頻繁，在im系統(tǒng)中實現(xiàn)數(shù)據(jù)庫cache，對于性能的提高是非常有幫助的。前臺邏輯服務(wù)器，也應(yīng)該盡量的cache數(shù)據(jù)，減少訪問DB
Proxy的次數(shù)，以提高系統(tǒng)的整體性能。
這里為了把客戶端指引到連接指定的邏輯服務(wù)器，前臺需要有Dispatch 服務(wù)器，提供邏輯服務(wù)器的地址，端口。im
客戶端連接邏輯服務(wù)器前必須查詢Dispatch Server,來獲知邏輯服務(wù)器地址。 為了增強靈活性，可以設(shè)置一臺中心服務(wù)器，。來動態(tài)的提供邏輯服務(wù)器，DB
Proxy等的配置信息。以及方便進行服務(wù)器組的后臺管理。
這里的設(shè)計是針對udp 的im 系統(tǒng)來的。tcp 的im系統(tǒng)，成本偏高，研究的較少。
實際的應(yīng)用中，還需要一些性能測試數(shù)據(jù)的配合和運營數(shù)據(jù)，才能得出比較優(yōu)化了的架構(gòu)。