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