游戏服务器设计--点点滴滴

关于服务器中玩家数据缓存：

  服务器在启动的时候会从数据库中导入大量的信息，包括玩家的基本信息，玩家的活动信息，邮件，好友，组队等等。

  问题：哪些信息是必须在服务器初始化时导入的？

  考虑这个问题的因素：并不是所有的玩家角色活动频繁，有一部分的玩家长时间是不登陆的，全部导入会增加服务器的内存，而且查询服务器数据也会带来效率的影响。

  考虑的方案：服务器启动初始化时，仅仅从数据库获取一些经常需要用到的数据，如玩家角色信息，其他数据在需要用到时动态的添加到服务器缓存中。账号服务器也可以采取这样的方案，单个账号服务器存放大量的玩家账号数据，账号服务器启动时候，不导入任何数据，当玩家第一次登陆时候，从数据库获取数据，此时也将玩家数据加入到缓存中，以后登陆直接从缓存中获取数据。此类方案的优势是服务器占用内存小，但可能带来的问题是首次获取数据的时候会相对比较慢，这个需要综合各个因素，如使用的数据库，MYSQL还是MSSQL或者其他的商业数据库。
  一般来说，玩家的数据类型为非字符串，且占用空间小的数据是可以保存中缓存中的，但长字串如邮件类是信息，还是直接从数据库获取会比较好。

 

2010-07-23    17:53:45

关于服务器逻辑的错误处理：

方式一：采用错误代码的方式 ，客户端直接通过错误代码进行判断发生了什么错误。

方式二：定义一个专门处理错误的消息通道，或者说错误提示，有错误直接以字符串的形式发送给客户端。

 

2010-07-26    16:15:59

服务器消息转发机制，半解包，避免冗余代码
一般在设计服务器的时候，服务器组是不会全部暴露在外网，通过一个叫网关或代理的服务器与外网进行通讯。很大程度上，此服务器都在进行消息转发，如果按照通用的编码格式，在网关服务器上也会定义消息，
然后进行转发，但实际上消息的内容没有任何变化。所以考虑在设计的时候，直接使用一个通道，避免在网关服务器上再进行一次消息定义。

 

玩家ID：

服务器不能相信客户端发送的任何数据，所以玩家的唯一标识不能由客户端来提供，而是由服务器来生成。

考虑的一种方案：客户端发的数据包中留一个空位，到网关服务器根据某些信息来生成唯一的标识符，如账号ID+角色索引+其他信息。

 

2010-08-10     09:51:00

设计中可能用到的设计模式：singleton,reactor,factory menthod
单例模式，保证一个类仅有一个实例,提供一个全局的访问点;
在具体的实现中，有很多类仅仅是为了实现功能，只需要使用一个唯一的实例就行了，以前一般的做法是extern ClassName g_Name;
工厂方法,定义一个用于创建对象的接口，让子类决定实例化哪一个类;
设计服务器中，肯定会要有交互的消息，可以设计一个基类，然后所有的消息都由这个基类派生（产品）；实现一个工厂方法，根据自己的需求创建不同的产品。
反应器模式
每个实现的函数地址对应一个函数ID，并与消息ID对应，此ID便是所谓的句柄了；事件分发机制即是用IOCP或者EPOLL了；
服务器不断的从客户端接收数据包，根据消息ID，触发对应的事件。
只是暂时的想法，标记下，等待实现，先从LINUX下的EPOLL开始吧！