浩毛的博客

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）

代码实现：