浩毛的博客

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、 游戲世界由很多個(gè)游戲?qū)ο蠼M成（游戲角色、物品、NPC、技能等）；

 

2、 一個(gè)游戲?qū)ο蟮挠行?shù)據(jù)主要存放在客戶端、游戲服務(wù)器和持久性數(shù)據(jù)庫中；

 

3、 游戲?qū)ο蟮奶幚砜蓜澐譃榕c位置有關(guān)的和與位置無關(guān)的，如公會(huì)處理、物品處理等主要行為可以看作是與位置無關(guān)的處理，而NPC（AI）、戰(zhàn)斗、移動(dòng)這類的主要行為可以看成是與位置有關(guān)的。

 

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

a)         來自服務(wù)器端的動(dòng)作，如另外一個(gè)玩家跳起來。

b)        本地動(dòng)作。僅僅發(fā)生在本地客戶端的動(dòng)作，不需要與服務(wù)器端或其他客戶端通訊。

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

d)        嚴(yán)格服務(wù)器端驗(yàn)證的動(dòng)作。客戶端執(zhí)行動(dòng)作前必須經(jīng)過服務(wù)器端驗(yàn)證后才能執(zhí)行。如交易行為、攻擊其他玩家/NPC。

 

5、 客戶端和服務(wù)器，服務(wù)器進(jìn)程之間的相互的通信從邏輯上看就是就是向RemoteObject 發(fā)起的遠(yuǎn)程過程調(diào)用（RPC），RPC主要有兩種類型：

a)         通知(Notify)。只通知對(duì)方，而不關(guān)心和需要對(duì)方返回結(jié)果。

b)        請(qǐng)求(Request)。向?qū)Ψ桨l(fā)起請(qǐng)求，對(duì)方處理請(qǐng)求后返回結(jié)果，發(fā)起請(qǐng)求和返回結(jié)果這個(gè)過程可以是同步或異步。游戲服務(wù)器中絕大部分RPC請(qǐng)求都是異步的。

 

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

 

 

7、 服務(wù)器負(fù)載，除了升級(jí)硬件設(shè)備外，可以通過一些方式來提高服務(wù)器負(fù)載。

 

a)         保證足夠的網(wǎng)絡(luò)帶寬。

b)        分布式運(yùn)算，合理的集群式架構(gòu)。

c)         游戲策劃從游戲內(nèi)容上避免設(shè)計(jì)高并發(fā)，高消耗的游戲行為。

 

 

 

8、 從服務(wù)器的可伸縮性，穩(wěn)定性和高效率方面來考慮，要試著避免所有事情都在一個(gè)地方處理，盡量讓系統(tǒng)分布式運(yùn)行，但是過多的劃分功能到不同的進(jìn)程/機(jī)器上運(yùn)行，又會(huì)帶來數(shù)據(jù)的大量同步的問題。因此可以將游戲?qū)ο蟮奶幚碇饕獎(jiǎng)澐譃榕c位置無關(guān)和有關(guān)兩種。像公會(huì)，玩家信息，物品信息，組隊(duì)，拍賣等等這類與位置無關(guān)的但是占用CPU資源較少的處理可以盡可能的放在一個(gè)進(jìn)程中，避免進(jìn)程間對(duì)象同步，而像NPC，尋路，AOI運(yùn)算，戰(zhàn)斗處理等與位置有關(guān)的，處理過程中特別關(guān)心對(duì)象坐標(biāo)位置的、運(yùn)算量特別大的，但是進(jìn)程間對(duì)象同步較少的，都可以單獨(dú)劃分成多個(gè)進(jìn)程。

 

每類進(jìn)程服務(wù)的功能盡量單一。負(fù)責(zé)路由的就盡量只負(fù)責(zé)網(wǎng)絡(luò)包轉(zhuǎn)發(fā)，而不再承擔(dān)其他繁重的任務(wù)，負(fù)責(zé)游戲處理的就盡量讓網(wǎng)絡(luò)包流向簡(jiǎn)單。

     摘要:     上一篇內(nèi)存池的實(shí)現(xiàn)其實(shí)更像一個(gè)后備列表的實(shí)現(xiàn)。使用上來說不是很方便，要申請(qǐng)的內(nèi)存塊是一個(gè)BLOCK結(jié)構(gòu)的一個(gè)個(gè)成員，而且每次從系統(tǒng)內(nèi)存堆中申請(qǐng)都是一小塊一小塊，也沒有考慮字節(jié)對(duì)齊。因此讓我們來看看新的一個(gè)內(nèi)存池的實(shí)現(xiàn)吧。    這個(gè)內(nèi)存池是根據(jù)《c++應(yīng)用程序性能優(yōu)化》書里的固定尺寸的內(nèi)存池原理做了一些改動(dòng)用C語言寫的。大家有興趣...  閱讀全文

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

     做過一個(gè)簡(jiǎn)單的測(cè)試，10萬次內(nèi)存池調(diào)用的效率大概比直接分配釋放內(nèi)存提高了30-50%。但是前提是內(nèi)存池不能加鎖（pthread_mutex），加鎖的內(nèi)存池效率和直接分配內(nèi)存的效率差不多，有時(shí)候還要多點(diǎn)點(diǎn)。（測(cè)試的環(huán)境是每次2K，4個(gè)雙核CPU，F(xiàn)REEBSD7）

代碼實(shí)現(xiàn)：