网游服务端结构设计

柔情只为你懂 2022-07-12 14:08 173阅读 0赞

[http://blog.csdn.net/zky/archive/2004/08/26/85393.aspx][http_blog.csdn.net_zky_archive_2004_08_26_85393.aspx]

网游服务端结构设计 作者：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.逻辑层模块化设计

本文来自CSDN博客，转载请标明出处：[http://blog.csdn.net/zky/archive/2004/08/26/85393.aspx][http_blog.csdn.net_zky_archive_2004_08_26_85393.aspx]

[http://blog.csdn.net/ham235/archive/2010/03/22/5402698.aspx][http_blog.csdn.net_ham235_archive_2010_03_22_5402698.aspx]

生产者消费者模型在大数据量处理中的应用

生产者消费者模型是经典的进程/线程协同处理模型，在现实中也有很大量的应用。而在C/S或B/S模式的客户端和服务器交互的应用中却少见。其实在这种应用中如果存在大数据量的处理，使用这种模型也能带来较大的性能提升。

生产者消费者模型原型如下：

其实是一个很简单的模型，生产者不停的往队列里生产Item，如果队列满了则停止生产，直到有空位，消费者不停地从队列里取走Item，队列为空则等待，这样直到整个任务处理完成，队列管理组件负责队列的管理。整个处理过程中生产者和消费者可以并行处理各自的工作任务。

对于C/S或B/S模式中的大数据量的处理，通常都是通过分批处理来完成，通常是采用串行处理方式，客户端循环分批发送请求，如果数据还需要分别在服务端和客户端做一些处理时，则客户端和服务端都需要等待，造成资源不能充分利用，而如果采用生产者消费者模式，客户端和服务端可以并行处理，即使是在网络传输时客户端和服务端都可以作各自的处理，通过这种模式可以较大的提高整个任务的处理性能，通常实际应用中的C/S（B/S）模式的生产者消费者模型图如下：

总的来说客户端是消费者，服务端是生产者，客户端可以采用轮循的模式向服务端请求消费，服务端有一个客户端消费者服务充当客户端消费者代理的作用，向服务端生产者队列中取数据。而对于客户端的轮循组件来说，即充当生产者也充当消费者，对服务端来说是消费者，对客户端的处理来说又是生产者。这样就组成了一个多级生产者消费者模式，尽量使各部分能够并行处理，从而提高整体任务的处理性能，但这个过程中也需要考虑管理成本，对于一些本身处理不是很耗时的操作采用这个模型可能并不会带来明显效果，而对于一些相对复杂和耗时的操作，采用这个模型将带来明显的效果，毕竟客户端、网络和服务端都可以并行地得到充分的利用。

本文来自CSDN博客，转载请标明出处：[http://blog.csdn.net/ham235/archive/2010/03/22/5402698.aspx][http_blog.csdn.net_ham235_archive_2010_03_22_5402698.aspx]

[http_blog.csdn.net_zky_archive_2004_08_26_85393.aspx]: http://blog.csdn.net/zky/archive/2004/08/26/85393.aspx
[http_blog.csdn.net_ham235_archive_2010_03_22_5402698.aspx]: http://blog.csdn.net/ham235/archive/2010/03/22/5402698.aspx