摘 要：网络游戏由于需要为大量的玩家提供7*24小时的游戏服务，对游戏服务器的稳定性和高效性有较高要求。因此服务器架构" />
免费阅读期刊
论文发表、论文指导
周一至周五
9：00&22：00
一种新型的网络游戏服务器架构设计
2014年3期目录
&&&&&&本期共收录文章20篇
　　摘 要：网络游戏由于需要为大量的玩家提供7*24小时的游戏服务，对游戏服务器的稳定性和高效性有较高要求。因此服务器架构设计是网络游戏开发的关键之处，本文提出了一种高性能、可伸缩、易维护的服务器架构，经过对架构的实际测试取得了较为满意的效果。 中国论文网 /8/view-5131251.htm　　关键词：网络游戏服务器架构；高性能 　　中图分类号：TP368.5 　　网络游戏的开发可以分为客户端、服务器端的开发，客户端主要是负责游戏画面的绘制，以及和玩家的交互[1]。服务器端主要处理游戏的具体逻辑，并对玩家的游戏信息进行存储。为了给玩家良好的用户体验，游戏服务器必须保持高效、稳定，因此这对服务器开发的技术要求带来了更高的挑战[2]。 　　1 传统服务器架构 　　传统的服务器架构如图1所示，从图中可以看出整个游戏服务器共用一个Battle（战斗场景），整个架构中有若干个Game（游戏逻辑服），由Center（全局服务器）负责调度、转发游戏服务器之间的消息。这种结构的服务器设计比较简单，虽然较易实现，但是不能承载大量的用户，而且可扩展性不够强，需要进一步改进。 　　2 新服务器架构设计 　　随着对网络游戏服务器的进一步研究，设计出了一种新型服务器架构，如图2所示。下面详细介绍新架构的功能设计。 　　Group服务器组：Group有别于传统的服务器大区概念，1个服务器大区可以包括若干个Group。大区和大区之间的玩家ID不重复，因此从技术上不再有划分大区的意义，仅用运营需求划分。在技术上按Core服务器的性能上限来划分Group。 　　Game Server游戏服务器：每一个Game只保持一个与Core的连接，且在逻辑上独立，单服结构，不搞多线按world切分Game。Game是玩家主要行为逻辑的所在，Game不直连DB，所有数据交互都通过Core转发。对于Game来说，其角色及游戏内数据都是互相独立的，所以一般情况下每个Game单独配备一台数据库服务器，以减轻数据库的压力。所以Game配置的id与DB的id一一对应。 　　DB Server数据库服务器：每一个DB只保持与一个与Core的连接。简单的数据网络包读写逻辑，和与mysql的查询、修改交互[3]。每个DB在逻辑上也独立，容错性好，一台DB宕机，只有对应的Game才受影响。如果是按数据表划分DB的话，一台DB宕机了，对应的所有Game都会受影响。 　　Battle Server战场服务器：Battle和Game在结构上是基本等价的，在玩家感受上，玩家在Game和在Battle应该是一样的。不同的是一个Battle可以连接到多个Core上，这样凡是被Battle所连接的Core，对应的Game都可以一起跨服了。Battle和Core之间交互的协议与Game与Core之间交互的协议完全一致，Client通过Core从Game切换到Battle上来参加战斗，角色切换到Battle上时，也通过Core向DB要数据。 　　Core的逻辑相对简单，是其他服务器的网关服务器，主要工作还是转发数据，所谓转发数据就是当Core收到一个包时，不需要管网络包里的内容，只需要从网络包中读出是发给哪个服务器，然后原封不动的发出去。 　　Center Server中央服务器：中心服务器全服唯一，连接所有的Core，主要功能包括信息全服广播。在实际运营中，需要权限会比普通玩家高所谓的GM，只需要做一个客户端连接Center，在Center服务器上执行GM命令，这样可以有更高的安全性。维护时，发送服务器关机命令也可以由Center发出，各个服务器走各自的关机流程。 　　3 新架构的性能分析 　　新架构中各个服务器的功能都相对比较单纯，服务器间的连接关系也比较简单。而且跨服可以不用断线，不用在game和battle之间传递玩家数据。Group的灵活性大，可以任意配置，最小粒度甚至可以做到1个game+1个db+1个core。 　　通过实际的架构运行发现新架构极大程度减少了服务器的运算开销，这是因为Core服务器它只是一台管理连接的服务器，并不打算让他承担太多的游戏逻辑，而Core正好满足这个需求，主要逻辑还在Game上。Core连接了各类服务器和客户端，给其他服务器和客户端充当网关的作用，负责转发他们之间交流数据的网络包，同时也管理了客户端的连接与断开。Core因而分担了部分原属于Game的逻辑，从而减轻了Game的性能开销。 　　4 新架构的测试分析 　　一个游戏架构无论涉及得多完美都必须经过严格的功能测试才能正式使用，因此设计了一些具体的测试方案： 　　（1）对异常情况的测试：通过制造错误情况测试服务器对出错的处理，因为有些出错条件的环境实际操作难以实现，这就需要故意修改代码来达到目的，以测试服务器的容错性，避免一旦出现错误，服务器会宕掉的情况。并检查错误提示或者错误日志是否正确；只有通过异常测试，才可以减少服务器挂的几率。比如Core的主要功能是转发包，那么当发包的目的dpid不存在，Core是否会对这种情况做容错性处理[4]。 　　（2）对服务器的破坏性测试：伪造虚拟的客户端封包，以及超大规模的网络包流量，测试服务器端的容错性和并发性能。 　　（3）对性能的监控：监控服务器是否存在内存泄露。以及完善的CPU、IO、带宽的监控和报警机制。 　　（4）服务器日志：监控日志的异常情况，以及日志信息是否完善，以备差错和数据统计使用。 　　通过上述的测试分析，新架构的设计达到了预想的目标。 　　5 结束语 　　网络游戏服务器性能已成为当前网游领域的核心技术难点。本文从实际应用出发，提出了一种高性能、可伸缩、易维护的服务器架构，通过性能分析和具体架构测试后发现新架构取得了较好的效果。 　　参考文献： 　　[1]马亚花.一种高性能的大型多人在线角色扮演游戏服务器架构设计[J].计算机光盘软件与应用，2012（09）. 　　[2]栗芳凯，刘振宇，李敏.基于SmartFoxServer的网络游戏服务器系统的研究与设计[J].电脑知识与技术，2012（13）. 　　[3]樊建国.网络游戏服务器通信架构与结构设计[J].中国新技术新产品，2009（21）. 　　[4]李虎雄，徐贯东，张燕姑.网络游戏数据平台数据通讯的实现方案[J].计算机工程与设计，2005（11）. 　　作者简介：江岸（1982.08-），男，湖南常德人，专职教师，助教，硕士研究生，研究方向：游戏开发、RFID防冲突算法。 　　作者单位：广东农工商职业技术学院计算机科学系，广州 510000
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。推荐这篇日记的豆列
······&&&&网络游戏服务器端的设计与实现.pdf
&网络游戏服务器端的设计与实现.pdf
网络游戏开发服务器开发的基础教程,本人觉得不错!
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：
VIP下载&&免积分60元/年（1200次）
您可能还需要
Q.为什么我点的下载下不了，但积分却被扣了
A. 由于下载人数众多，下载服务器做了并发的限制。若发现下载不了，请稍后再试，多次下载是不会重复扣分的。
Q.我的积分不多了，如何获取积分？
A. 获得积分，详细见。
完成任务获取积分。
论坛可用分兑换下载积分。
第一次绑定手机，将获得5个C币，C币可。
关注并绑定CSDNID，送10个下载分
下载资源意味着您已经同意遵守以下协议
资源的所有权益归上传用户所有
未经权益所有人同意，不得将资源中的内容挪作商业或盈利用途
CSDN下载频道仅提供交流平台，并不能对任何下载资源负责
下载资源中如有侵权或不适当内容，
本站不保证本站提供的资源的准确性，安全性和完整性，同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
网络技术下载排行
您当前C币：0&&&可兑换 0 下载积分
兑换下载分:&
消耗C币:0&
立即兑换&&
兑换成功你当前的下载分为 。前去下载资源
你下载资源过于频繁，请输入验证码
如何快速获得积分？
你已经下载过该资源，再次下载不需要扣除积分
网络游戏服务器端的设计与实现.pdf
所需积分：2
剩余积分：0
扫描微信二维码精彩活动、课程更新抢先知
VIP会员，免积分下载
会员到期时间：日
剩余下载次数：1000
网络游戏服务器端的设计与实现.pdf
剩余次数：&&&&有效期截止到：
你还不是VIP会员VIP会员享免积分 . 专属通道极速下载
VIP下载次数已满VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员
你的VIP会员已过期VIP会员享免积分 . 专属通道极速下载，请继续开通VIP会员网络游戏服务器设计
& 热门职位：
网络游戏服务器设计
日 17:00:50
　 &谈这个话题之前，首先要让大家知道，什么是服务器。在游戏中，服务器所扮演的角色是同步，广播和服务器主动的一些行为，比如说天气，NPC AI之类的，之所以现在的很多网络游戏服务器都需要负担一些游戏逻辑上的运算是因为为了防止客户端的作弊行为。了解到这一点，那么本系列的文章将分为两部分来谈谈网络游戏服务器的设计，一部分是讲如何做好服务器的网络连接，同步，广播以及NPC的设置，另一部分则将着重谈谈哪些逻辑放在服务器比较合适，并且用什么样的结构来安排这些逻辑。
服务器的网络连接
　　大多数的网络游戏的服务器都会选择非阻塞select这种结构，为什么呢？因为网络游戏的服务器需要处理的连接非常之多，并且大部分会选择在Linux/Unix下运行，那么为每个用户开一个线程实际上是很不划算的，一方面因为在Linux/Unix下的线程是用进程这么一个概念模拟出来的，比较消耗系统资源，另外除了I/O之外，每个线程基本上没有什么多余的需要并行的任务，而且网络游戏是互交性非常强的，所以线程间的同步会成为很麻烦的问题。由此一来，对于这种含有大量网络连接的单线程服务器，用阻塞显然是不现实的。对于网络连接，需要用一个结构来储存，其中需要包含一个向客户端写消息的缓冲，还需要一个从客户端读消息的缓冲，具体的大小根据具体的消息结构来定了。另外对于同步，需要一些时间校对的值，还需要一些各种不同的值来记录当前状态，下面给出一个初步的连接的结构：
网络游戏typedef connection_s {
&&& user_t * /* 指向处理服务器端逻辑的结构 */
&&& /* socket连接 */
&&& struct sockaddr_ /* 连接的地址信息 */
&&& char text[MAX_TEXT]; /* 接收的消息缓冲 */
&&& int text_ /* 接收消息缓冲的尾指针 */
&&& int text_ /* 接收消息缓冲的头指针 */
&&& int last_ /* 上一条消息是什么时候接收到的 */
&&& st /* 客户端本地时间和服务器本地时间的差值 */
&&& struct timeval last_confirm_ /* 上一次验证的时间 */
&&& short is_ /* 该连接是否通过验证过 */
&&& int ping_ /* 该客户端到服务器端的ping值 */
&&& int ping_ /* 多少个IO周期处理更新一次ping值 */
&&& int message_ /* 发送缓冲消息长度 */
&&& char message_buf[MAX_TEXT]; /* 发送缓冲区 */
&&& /* 该连接的状态 */
} connection_t;
　　服务器循环的处理所有连接，是一个死循环过程，每次循环都用select检查是否有新连接到达，然后循环所有连接，看哪个连接可以写或者可以读，就处理该连接的读写。由于所有的处理都是非阻塞的，所以所有的Socket IO都可以用一个线程来完成。
　　由于网络传输的关系，每次recv()到的数据可能不止包含一条消息，或者不到一条消息，那么怎么处理呢？所以对于接收消息缓冲用了两个指针，每次接收都从text_start开始读起，因为里面残留的可能是上次接收到的多余的半条消息，然后text_end指向消息缓冲的结尾。这样用两个指针就可以很方便的处理这种情况，另外有一点值得注意的是：解析消息的过程是一个循环的过程，可能一次接收到两条以上的消息在消息缓冲里面，这个时候就应该执行到消息缓冲里面只有一条都不到的消息为止，大体流程如下：
while ( text_end – text_start & 一条完整的消息长度 )
&&& 从text_start处开始处理;
&&& text_start += 该消息长度;
memcpy ( text, text + text_start, text_end – text_start );
　　对于消息的处理，这里首先就需要知道你的游戏总共有哪些消息，所有的消息都有哪些，才能设计出比较合理的消息头。一般来说，消息大概可分为主角消息，场景消息，同步消息和界面消息四个部分。其中主角消息包括客户端所控制的角色的所有动作，包括走路，跑步，战斗之类的。场景消息包括天气变化，一定的时间在场景里出现一些东西等等之类的，这类消息的特点是所有消息的发起者都是服务器，广播对象则是场景里的所有玩家。而同步消息则是针对发起对象是某个玩家，经过服务器广播给所有看得见他的玩家，该消息也是包括所有的动作，和主角消息不同的是该种消息是服务器广播给客户端的，而主角消息一般是客户端主动发给服务器的。最后是界面消息，界面消息包括是服务器发给客户端的聊天消息和各种属性及状态信息。
　　下面来谈谈消息的组成。一般来说，一个消息由消息头和消息体两部分组成，其中消息头的长度是不变的，而消息体的长度是可变的，在消息体中需要保存消息体的长度。由于要给每条消息一个很明显的区分，所以需要定义一个消息头特有的标志，然后需要消息的类型以及消息ID。消息头大体结构如下：
type struct message_s {
&&& unsigned short message_
&&& unsigned char message_
&&& unsigned short message_id
&&& unsigned char message_len
}message_t;
服务器的广播
　　服务器的广播的重点就在于如何计算出广播的对象。很显然，在一张很大的地图里面，某个玩家在最东边的一个动作，一个在最西边的玩家是应该看不到的，那么怎么来计算广播的对象呢？最简单的办法，就是把地图分块，分成大小合适的小块，然后每次只象周围几个小块的玩家进行广播。那么究竟切到多大比较合适呢？一般来说，切得块大了，内存的消耗会增大，切得块小了，CPU的消耗会增大（原因会在后面提到）。个人觉得切成一屏左右的小块比较合适，每次广播广播周围九个小块的玩家，由于广播的操作非常频繁，那么遍利周围九块的操作就会变得相当的频繁，所以如果块分得小了，那么遍利的范围就会扩大，CPU的资源会很快的被吃完。
　　切好块以后，怎么让玩家在各个块之间走来走去呢？让我们来想想在切换一次块的时候要做哪些工作。首先，要算出下个块的周围九块的玩家有哪些是现在当前块没有的，把自己的信息广播给那些玩家，同时也要算出下个块周围九块里面有哪些物件是现在没有的，把那些物件的信息广播给自己，然后把下个块的周围九快里没有的，而现在的块周围九块里面有的物件的消失信息广播给自己，同时也把自己消失的消息广播给那些物件。这个操作不仅烦琐而且会吃掉不少CPU资源，那么有什么办法可以很快的算出这些物件呢？一个个做比较？显然看起来就不是个好办法，这里可以参照二维矩阵碰撞检测的一些思路，以自己周围九块为一个矩阵，目标块周围九块为另一个矩阵，检测这两个矩阵是否碰撞，如果两个矩阵相交，那么没相交的那些块怎么算。这里可以把相交的块的坐标转换成内部坐标，然后再进行运算。
　　对于广播还有另外一种解决方法，实施起来不如切块来的简单，这种方法需要客户端来协助进行运算。首先在服务器端的连接结构里面需要增加一个广播对象的队列，该队列在客户端登陆服务器的时候由服务器传给客户端，然后客户端自己来维护这个队列，当有人走出客户端视野的时候，由客户端主动要求服务器给那个物件发送消失的消息。而对于有人总进视野的情况，则比较麻烦了。
　　首先需要客户端在每次给服务器发送update position的消息的时候，服务器都给该连接算出一个视野范围，然后在需要广播的时候，循环整张地图上的玩家，找到坐标在其视野范围内的玩家。使用这种方法的好处在于不存在转换块的时候需要一次性广播大量的消息，缺点就是在计算广播对象的时候需要遍历整个地图上的玩家，如果当一个地图上的玩家多得比较离谱的时候，该操作就会比较的慢。
【编辑：布谷布谷】
最新应聘信息
建议意见：　商务合作：广告专线：7　客服电话：3}