伺服器是用來處理高併發的請求，同時能夠滿足擴充套件的業務邏輯的需求，最重要的是滿足三點：併發性，穩定性，擴充套件性。
經歷過兩款上線遊戲產品，見識到了遊戲行業的雜亂無章，雖然和傳統軟體行業相比，少了那麼些規範，但是對個人能力要求還真不比傳統軟體行業低。
今天開始，陸續利用業餘時間將自己設計的乙個伺服器的框架貼出來，也會包好一些基本的**，也會用到一些開源庫。從最基礎的講起，首先看看乙個實時網路遊戲伺服器的框架:
目前市面上的遊戲，總的來說分為兩類：
1.弱聯網類遊戲，像手機上的卡牌類遊戲(mt,dota傳奇等)，大部分邏輯在客戶端處理，不需要實時聯網，這類遊戲只有乙個玩家，而且只有pve模式，就是打遊戲中的機械人(ai)，不存在玩家與玩家的實時互動。例如一場副本打鬥，只有在開始和結束，才會連線伺服器，請求獲取或者儲存資料，打鬥過程由客戶端計算完成，最後將戰鬥結果提交伺服器就行了。
2.強聯網類遊戲，典型的就是mmorpg或者mmarpg的型別的遊戲，一般常見於端遊或者頁遊，也包含手遊。在乙個地圖中，同時有很多玩家，任何乙個玩家的狀態或者屬性發生變化，伺服器就需要實時更新遊戲中角色的狀態，並且通知到周圍的玩家。例如在副本中，乙個玩家釋放技能，攻擊範圍，傷害計算這些邏輯都是伺服器來完成的，而客戶端只需要負責特效的顯示，這個過程中需要實時的資料互動。
顯然，第2種，mmorpg類遊戲需要伺服器做更多的事情，對伺服器的運算要求更高，實時性要求更高，自然實現起來更複雜。
這裡說的模組可以指乙個程序，或者乙個執行緒方式存在，本質上就是一些類的封裝。
對於伺服器的併發性，要麼採用單程序多執行緒，要麼採用多程序單執行緒的方式，說說兩種方式的優缺點：
一、單程序多執行緒的伺服器設計模式，只有乙個程序，但乙個程序包好多個執行緒：
優點：
1.資料共享和交換方便，使用全域性變數或者單例就可以，資料儲存方便。
2.單程序，伺服器框架結構相對簡單，編碼容易。
缺點：1.所有功能只能在單個物理伺服器上，不能做成分布式。
2.不方便監控各個執行緒狀態，容易死鎖
3.乙個執行緒出錯，例如記憶體非法訪問，棧空間被破壞，那麼伺服器程序就退出，所有玩家掉線，影響大。
二、多程序單執行緒的伺服器設計模式，多個程序，每個程序只有乙個執行緒：
優點：
2.可以通過守護程序監控其它程序狀態，例如有程序死掉，馬上重啟該程序，或者某個程序cpu使用率接近100%（基本可以判斷是某個邏輯死迴圈了）, 強制kill掉該程序，然後重啟。
4.伺服器通過共享記憶體進行資料交換，那麼如果其中乙個伺服器死掉，資料還在，可以保護使用者資料（當然多執行緒也可以使用共享記憶體）。
5.併發性相對多執行緒要高點。
缺點：1.不方便使用互斥鎖，因為程序切換的時間片遠遠於執行緒切換，對於乙個高併發伺服器是無法允許這麼高時間片的切換代價的。因此必須設計好伺服器的框架，盡量避開使用鎖機制，但要保證資料不出錯。
2.多程序程式設計，在各個程序間會有很多通訊，跨伺服器程序的非同步訊息較多，會讓伺服器的編碼難度加大。
下面先按照乙個遊戲的功能，將伺服器的功能分塊框架畫出來:
以上是乙個遊戲伺服器最基礎的功能框架圖，接下來要做的就是設計伺服器的框架了。
網路遊戲 伺服器
using system using system.collections.generic using system.linq using system.text using system.threading.tasks using system.net.sockets using system.n...
網路遊戲伺服器構架設計（一） 前言
鏈結自 這篇blog題目涉及的範圍真大！以至於在這裡需要先寫一篇前言把範圍縮小。選擇寫這樣乙個系列的文章，主要是想給工作了兩年的自己乙個交代，或者說是乙個階段性的總結。兩年時間裡，房價依然再漲，工資依然跑不贏cpi，某人依然在仰望星空。期間很多夢碎了，很多還在堅持著，生活過得波瀾不驚。而我也從剛畢業...
網路遊戲伺服器構架設計（一） 前言
這篇blog題目涉及的範圍真大！以至於在這裡需要先寫一篇前言把範圍縮小。選擇寫這樣乙個系列的文章，主要是想給工作了兩年的自己乙個交代，或者說是乙個階段性的總結。兩年時間裡，房價依然再漲，工資依然跑不贏cpi，某人依然在仰望星空。期間很多夢碎了，很多還在堅持著，生活過得波瀾不驚。而我也從剛畢業是的青澀...