The Sun Game Server Architecture

     Sun‘s Game Server technology logically is divided vertically into 3 layers: Communications, Simulation Logic, and
Object Store.

     The Object Store layer contains the game states for all games running in the Game Server. It is a highly efficient(tenths of a millisecond per operation), scalable, and fault-tolerant transactional database layer that provides deadlock proof access to the simulation objects, which can either be locked (a write-lock) or peeked (a nonrepeatable read).

     The Simulation Logic layer is responsible for executing the actual game code. Here, tasks are created based on incoming events which, in turn, check objects out of the Object Store as needed. When a task is completed, the object is updated and returned to the Object Store.

     The Communications layer organizes player communication into channels of grouped communicators. It manages routing of data packets between the players and the Simulation Logic servers, and between the players themselves. It also is responsible for translation to and from other forms of networking (e.g., HTTP communications to and from cell phones).

 

1、 游戲世界由很多個游戲對象組成（游戲角色、物品、NPC、技能等）；

 

2、 一個游戲對象的有效數據主要存放在客戶端、游戲服務器和持久性數據庫中；

 

3、 游戲對象的處理可劃分為與位置有關的和與位置無關的，如公會處理、物品處理等主要行為可以看作是與位置無關的處理，而NPC（AI）、戰斗、移動這類的主要行為可以看成是與位置有關的。

 

4、 從客戶端的角度來看，游戲行為可分為四類動作：

a)         來自服務器端的動作，如另外一個玩家跳起來。

b)        本地動作。僅僅發生在本地客戶端的動作，不需要與服務器端或其他客戶端通訊。

c)         先執行后驗證的可撤銷的動作。客戶端先執行，再提交服務器端驗證，驗證不成功通知客戶端將執行的動作撤銷。比如玩家控制的游戲角色執行移動處理。

d)        嚴格服務器端驗證的動作。客戶端執行動作前必須經過服務器端驗證后才能執行。如交易行為、攻擊其他玩家/NPC。

 

5、 客戶端和服務器，服務器進程之間的相互的通信從邏輯上看就是就是向RemoteObject 發起的遠程過程調用（RPC），RPC主要有兩種類型：

a)         通知(Notify)。只通知對方，而不關心和需要對方返回結果。

b)        請求(Request)。向對方發起請求，對方處理請求后返回結果，發起請求和返回結果這個過程可以是同步或異步。游戲服務器中絕大部分RPC請求都是異步的。

 

6、 響應延遲主要是由于網絡帶寬和服務器處理效率引起的。應盡可能的通過一些技巧來隱藏和減少玩家的響應延遲。但不是所有的最新消息都能立刻發送出去（或接收處理到），因此，要在服務器端采用優先隊列來減少重要消息的響應時間。延遲也會由客戶端產生，如收到消息后的對消息的處理速度。

 

 

7、 服務器負載，除了升級硬件設備外，可以通過一些方式來提高服務器負載。

 

a)         保證足夠的網絡帶寬。

b)        分布式運算，合理的集群式架構。

c)         游戲策劃從游戲內容上避免設計高并發，高消耗的游戲行為。

 

 

 

8、 從服務器的可伸縮性，穩定性和高效率方面來考慮，要試著避免所有事情都在一個地方處理，盡量讓系統分布式運行，但是過多的劃分功能到不同的進程/機器上運行，又會帶來數據的大量同步的問題。因此可以將游戲對象的處理主要劃分為與位置無關和有關兩種。像公會，玩家信息，物品信息，組隊，拍賣等等這類與位置無關的但是占用CPU資源較少的處理可以盡可能的放在一個進程中，避免進程間對象同步，而像NPC，尋路，AOI運算，戰斗處理等與位置有關的，處理過程中特別關心對象坐標位置的、運算量特別大的，但是進程間對象同步較少的，都可以單獨劃分成多個進程。

 

每類進程服務的功能盡量單一。負責路由的就盡量只負責網絡包轉發，而不再承擔其他繁重的任務，負責游戲處理的就盡量讓網絡包流向簡單。

     摘要:     上一篇內存池的實現其實更像一個后備列表的實現。使用上來說不是很方便，要申請的內存塊是一個BLOCK結構的一個個成員，而且每次從系統內存堆中申請都是一小塊一小塊，也沒有考慮字節對齊。因此讓我們來看看新的一個內存池的實現吧。    這個內存池是根據《c++應用程序性能優化》書里的固定尺寸的內存池原理做了一些改動用C語言寫的。大家有興趣...  閱讀全文

     都知道頻繁分配內存釋放內存很耗系統資源，而且容易造成內存碎片。因此寫了個簡單的內存池實現，越簡單越好，為什么？做復雜了效率還不如直接malloc。因此這個內存池采用鏈表連接內存塊的方式，分配的是固定大小的內存塊，從池中取內存和歸還內存是用的空閑鏈表堆棧操作， 沒有使用線程鎖，如果要線程安全，建議在外部調用內存池的地方加鎖。

     做過一個簡單的測試，10萬次內存池調用的效率大概比直接分配釋放內存提高了30-50%。但是前提是內存池不能加鎖（pthread_mutex），加鎖的內存池效率和直接分配內存的效率差不多，有時候還要多點點。（測試的環境是每次2K，4個雙核CPU，FREEBSD7）

代碼實現：