网游服务端结构设计 作者：Hack

?1.概述
LoginServer?<----->?GameServer
服务端主体分为LoginServer和GameServer,?LoginServer做帐户认证,?GameServer做游戏主逻辑,
中间也可以加一个CharServer啦,?做人物管理,?新建删除人物之类的,?也可以并到GameServer一
起,?LoginServer和CharServer都比较简单,?略过.
通过LoginServer的验证后将分配给Client一个SessionID,?然后与GameServer或CharServer的通信,
都以此SessionID为认证码.?Client只有发送正确的SessionID才能与GameServer建立连接.

2.GameServer层次结构
GameServer分为三层,?网络层<--->逻辑处理层<--->数据库层
每层都有一个消息处理队列,?存放待处理的消息.?消息队列可以采用先进先出队列的方式,?也可以
采用堆或者优先队列的方式,?按优先级对待处理消息进行简单的排序,?嘿嘿,?是不是有点类似QoS
的思想.
每层采用线程池技术,?预先建立一定数量的空闲线程,??不够时建立新线程,?过多时则销毁线程,?
保证线程池中有指定数量的空闲线程(Min/Max),?主线程不断检查处理队列是否有待处理消息,?若
有则从线程池中分配一空闲线程处理之.
偶在Linux下线程池是用pthread_cond_wait和pthread_cond_signal实现的.

2.1.网络层
本层根据操作系统不同可以有多种实现,?主要功能是与客户端建立TCP连接,?将TCP流分割成一个个封包,
如果有加密就解密,?如果有压缩就解压缩,?加入事务层的处理队列,?同时把处理队列中待发送的消息发
送出去,?如果要加密就加密,?如果要压缩就压缩.
Windows下采用IOCP模型,?Unix-like系统下可采用select/poll(epoll)/kqueue
偶在偶的服务端中采用了select方式,?Linux单个端口的连接数有限制,?所以偶开了多个线程监听一组端口,?
由LoginServer做负载均衡,?从而保证不会出现某个端口连接数过多的情况.?每当有新客户端要登录时,?
LoginServer判断每个端口的连接数量,?选最小发送给客户端.?偶想这里也可以做成动态方式,
当每个端口平均连接数超过XXXX时,?就开新线程监听新端口,?并通知LoginServer.

2.2.逻辑处理层
本层是GameServer的核心.?
根据操作码(OPcode)把消息分配到每个子模块里面处理.?最简单的方法就是用从0开始的连续的OPcode,?建立
一个与Opcode对应的处理函数的数组,?Opcode作为数组的下标,?这样只需要O(1)的时间就可以调用到所需的函数
连Hash都省了,?又简单又高效.
子模块详见第7部分

2.3.数据库层
本层用于数据存储,?本质上就是把内存里的数据存到硬盘上,?要是你够拽的话,?可以不用现有的数据库,?
自己写算法存储文本文件,?但为了方便起见,?也为了提高效率,?还是用数据库比较好.
windows下用MSSQL,?或者用MYSQL,?
Unix-like系统下可以用的就多了,?能多兼容几种数据库最好
MYSQL的性能优异,?功能上稍差一点,?如果不需要用到存储过程的话,?MYSQL还是首选的.
数据库层一般用单线程已经足够,?可以不需要做对象互斥,?编程方面也会简单一点.?但是需要注意的是,?
数据库操作方面一定要用Transaction,?可以有效防止复制现象发生,?比如:交易操作一旦发生错误,?则
rollback到交易之前,?不会发生钱已交出,?东西却没拿到的情况.

3.消息格式定义
3.1.网络层<-->逻辑层消息格式(网络封包格式)
3.2.逻辑层<-->数据库层消息格式

4.游戏对象定义(Object)
object?
??|------->?item
??|???????????|---->?container(容器类对象，如仓库、背包等)
??|
??|------->?unit?
??|???????????|----->?player
??|???????????|----->?monster
??|???????????|----->?npc
??|???????????|----->?corpse(尸体对象)
??|
??|------->?gameobj?
??????????????|----->?dynamicobj(如技能产生的临时对象)
??
5.地图场景管理
6.脚本系统
7.逻辑层模块化设计