网游服务端结构设计

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.逻辑层模块化设计