因為是轉載文章， 在此標明出處，如有冒犯請聯絡本人。

因為好的文章，以前只想收藏，但連線有時候會失效，所以現在碰到好的直接轉到自己這裡。

原文出處：http://www.cnblogs.com/GmrBrian/p/3777074.html

伺服器是用來處理高併發的請求，同時能夠滿足擴充套件的業務邏輯的需求，最重要的是滿足三點：併發性，穩定性，擴充套件性。

經歷過兩款上線遊戲產品，見識到了遊戲行業的雜亂無章，雖然和傳統軟體行業相比，少了那麼些規範，但是對個人能力要求還真不比傳統軟體行業低。

今天開始，陸續利用業餘時間將自己設計的一個伺服器的框架貼出來，也會包好一些基本的程式碼，也會用到一些開源庫。從最基礎的講起，首先看看一個實時網路遊戲伺服器的框架:

目前市面上的遊戲，總的來說分為兩類：

1.弱聯網類遊戲，像手機上的卡牌類遊戲(MT,Dota傳奇等)，大部分邏輯在客戶端處理，不需要實時聯網，這類遊戲只有一個玩家，而且只有PVE模式，就是打遊戲中的機器人(AI)，不存在玩家與玩家的實時互動。例如一場副本打鬥，只有在開始和結束，才會連線伺服器，請求獲取或者儲存資料，打鬥過程由客戶端計算完成，最後將戰鬥結果提交伺服器就行了。

2.強聯網類遊戲，典型的就是MMORPG或者MMARPG的型別的遊戲，一般常見於端遊或者頁遊，也包含手遊。在一個地圖中，同時有很多玩家，任何一個玩家的狀態或者屬性發生變化，伺服器就需要實時更新遊戲中角色的狀態，並且通知到周圍的玩家。例如在副本中，一個玩家釋放技能，攻擊範圍，傷害計算這些邏輯都是伺服器來完成的，而客戶端只需要負責特效的顯示，這個過程中需要實時的資料互動。

顯然，第2種，MMORPG類遊戲需要伺服器做更多的事情，對伺服器的運算要求更高，實時性要求更高，自然實現起來更復雜。

一個大型的網落遊戲伺服器應該包含幾個模組：網路通訊，業務邏輯，資料儲存，守護監控（不是必須），其中業務邏輯可能根據具體需要，又劃分為好幾個子模組。

這裡說的模組可以指一個程序，或者一個執行緒方式存在，本質上就是一些類的封裝。

對於伺服器的併發性，要麼採用單程序多執行緒，要麼採用多程序單執行緒的方式，說說兩種方式的優缺點：

一、單程序多執行緒的伺服器設計模式，只有一個程序，但一個程序包好多個執行緒：

網路通訊層，業務邏輯，資料儲存，分別在獨立的執行緒中，無守護程序。

優點：

1.資料共享和交換方便，使用全域性變數或者單例就可以，資料儲存方便。

2.單程序，伺服器框架結構相對簡單，編碼容易。

缺點：

1.所有功能只能在單個物理伺服器上，不能做成分散式。

2.不方便監控各個執行緒狀態，容易死鎖

3.一個執行緒出錯，例如記憶體非法訪問，棧空間被破壞，那麼伺服器程序就退出，所有玩家掉線，影響大。

二、多程序單執行緒的伺服器設計模式，多個程序，每個程序只有一個執行緒：

網路通訊，業務邏輯，資料儲存，守護程序，分別在不同的程序。

優點：

1.各個程序可以分佈在不同的物理伺服器上，可以做成分散式的伺服器框架，例如可以將資料儲存單獨放到一個物理伺服器上，供幾個區的伺服器使用。將網路通訊程序獨立出來，甚至可以做成導向伺服器，實現跨服戰。

2.可以通過守護程序監控其它程序狀態，例如有程序死掉，馬上重啟該程序，或者某個程序cpu使用率接近100%（基本可以判斷是某個邏輯死迴圈了）, 強制kill掉該程序，然後重啟。

3.單個伺服器程序異常退出，只要不是網路通訊程序（一般這個都會比較穩定，沒什麼邏輯），那麼就可以及時被守護程序重啟，不會造成玩家掉線，只會造成在1-2秒內，某個邏輯功能無法使用，甚至玩家都感覺不到。

4.伺服器通過共享記憶體進行資料交換，那麼如果其中一個伺服器死掉，資料還在，可以保護使用者資料（當然多執行緒也可以使用共享記憶體）。

5.併發性相對多執行緒要高點。

缺點：

1.不方便使用互斥鎖，因為程序切換的時間片遠遠於執行緒切換，對於一個高併發伺服器是無法允許這麼高時間片的切換代價的。因此必須設計好伺服器的框架，儘量避開使用鎖機制，但要保證資料不出錯。

2.多程序程式設計，在各個程序間會有很多通訊，跨伺服器程序的非同步訊息較多，會讓伺服器的編碼難度加大。

下面先按照一個遊戲的功能，將伺服器的功能分塊框架畫出來

以上是一個遊戲伺服器最基礎的功能框架圖，接下來要做的就是設計伺服器的框架了。