2009年7月 总版技术专家分月排行榜第二2009年3月 总版技术专家分月排行榜第二2009年1月 总版技术专家分月排行榜第二2005年7月 总版技术专家分月排行榜第二2005年5月 总版技术专家分月排行榜第二2005年3月 总版技术专家分月排行榜第二
优秀小版主2015年8月优秀小版主2015年9月优秀小版主2015年5月优秀小版主2015年2月论坛优秀版主
本帖子已过去太久远了，不再提供回复功能。rangercyh 的BLOG
用户名：rangercyh
文章数：173
评论数：475
访问量：495693
注册日期：
阅读量：5863
阅读量：12276
阅读量：420954
阅读量：1109216
51CTO推荐博文
机缘巧合的机会，我有幸能够从头开始设计一个游戏的服务器。中间遇到很多欢声笑语和悲伤泪水，这里分享一下。我之前所在项目组的游戏服务器架构如下图：650) this.width=650;" src="/shard/s12/res/22f-40b9-a959-f6af2a0f3cd5/1.jpg" alt="" class="en-media" style="margin:.857412em 0px 1.286padding:0border:0height:" />这款游戏是一款MMO的端游，GateWay网关的任务是接受客户端的连接，然后通过分发策略，把玩家丢进GameSvr上去，之后玩家的所有请求都直接发给GameSvr，由GameSvr处理了。当然这里的分发策略跟一般的web服务器是不同的，web服务器一般会做成无状态的服务器，也就是对于客户端来说请求到达哪一个服务器都没有关系，都能够被处理，但是游戏服务器大多都是有状态的，web的一般分发策略是做一个负载均衡，只要保证服务器的整体压力没问题就已经是一个好的架构了，但是游戏服务器由于存在状态需要维护，所以通常都没办法做简单的负载均衡。举个例子，由于我们是MMO游戏，所以在服务器逻辑上存在地图的概念，好比魔兽世界的游戏里不同的玩家出生的地图是不一样的，而且你从一张地图下线后，下次上线的地点一般来说都会是你上次下线的地点，而根据游戏历程和策划想要营造的游戏效果来看，游戏里不同地图之间的压力通常来说是不一样的，比如主城的玩家就通常比一张偏远的野外地图的玩家要多，而游戏服务器的压力通常都出现在玩家聚集的时候，例如大量IO的压力。所以从设计人员的角度来看，一般会把不同的地图分配到单独的进程中去，所以GameSvr通常会按照地图来进行划分，那么GameSvr进程天生就具备了自己的状态，因为两个GameSvr进程已经就不一样了，玩家是在哪个地图，就只能把玩家丢到哪个GameSvr上去。当然，这只是我们采取的一种做法，其他人还有不同的做法，不过大致是类似的。我曾仔细考量过上面那个游戏单个GameSvr的承载能力，通常在1000人左右就已经开始吃紧了，这点也比较好理解，根据这个服务器的架构，几乎所有的玩家逻辑都在同一个进程内被处理，只有一些公共的逻辑被分配给Relay进程处理，这里的Relay进程承担两个作用，一个是做不同的GameSvr间的通信转发，另一个是它自身也会维护游戏里的公共逻辑，什么叫公共逻辑呢？比如聊天、帮会、排行榜等等，这些不跟地图相关的游戏逻辑，又被多个GameSvr共享的部分就被抽离到Relay进程上，其实这里有两种做法，一种是让每个GameSvr进程自己去维护这份公共逻辑，但显然这会浪费GameSvr进程仅剩的不多的压力负载。但是把逻辑放入Relay进程也带来一些问题，比如在游戏研发中会发现，越来越多的逻辑需要放进Relay进程，导致Relay进程越来越庞大，比如我们游戏中的帮会数据和全局定时器的维护就由Relay进程来维护的，但是程序员在写功能的时候经常就直接一个RPC调用来使用Relay的功能，因为这很方便，而且从现有架构的设计来看也是合理的，我们当时的relay的rpc接口设计的是同步的接口，于是当rpc激增的时候，整个游戏逻辑就变卡了。Relay的庞大导致两个问题，一个是单点故障的概率变高了，另一个就是Relay的性能低下会导致整个游戏服务器变卡。我们的服务器有段时间在每天晚上10点左右就开始卡，只要涉及到公共逻辑的部分就几乎无法使用，例如无法聊天、无法进行帮会操作等等，最后排查问题的结果就发现是游戏中的某些功能把逻辑写在Relay上，到10点进行了一个十分复杂的计算，导致Relay阻塞在那里，而无法响应GameSvr发来的请求。我是在游戏的开发末期加入这个项目的，当时Relay的体积还是比较小的，大家都刻意的去尽量避免游戏逻辑放在Relay上，但是当游戏真正进入运营期之后，deadline的限定，大家不得不把逻辑放Relay上，因为这是最快的实现方式。我眼看着Relay一步步的胖起来，在我离开这个项目的时候，Relay上的代码已经满目苍夷了。再来谈谈这个架构的其他部分，比如Bishop是用来进行我们游戏内交易数据的统计和验证的模块，主要是和公司的交易系统进行对接，AccoutSvr的作用是处理游戏内账户的相关操作，比如建立账户，新建角色等等，它的主要作用其实是为了保证游戏数据的唯一性，例如角色名的唯一、宠物名的唯一等等。接着是Mysql的部分，云风曾经在博客里说过游戏服务器中数据库的作用应该只是一种备选方案，&也就是说如果存在理想的游戏服务器，永不宕机，永不维护，那么实际上数据库是不需要的部分，数据库承担的是一个游戏恢复和容错的机制，我很赞同云风的这种说法，而一旦不需要去考虑数据库的部分，那么游戏设计其实减掉了很多容错的做法。关于数据库的部分我后面还会谈到。然后是这个架构的扩展性，对于游戏服务器来说，扩展通常有三种，一种是开新区、另一种是合服、最后才是由于服务器压力顶不住而扩展逻辑进程。上面我们这个端游的服务器模块从设计上就不去考虑开新服的机制，单套服务器架构基本只支持一个区，所以在开新区的时候，做法是部署同一套服务器架构，利用客户端更新服务器的地址来实现不同服的架构；合服的情况要更加复杂，因为在设计上没有考虑多服的设计，所以不同服之间的数据可以说是毫不相关，那么在合并服务器的时候必然存在一些冲突数据需要处理，不光是一些玩家数据，甚至还有一些游戏逻辑数据，例如我之前做过一个功能，是实现一个全服的玩家联赛，最后每个区会产生一个冠军，然后冠军的雕像会被放置到游戏中的主城中展示一个月，但是后来有两个区合并了，那么到底展示谁的雕像，因为无论你展示哪一个区的，玩家都会不满，当然，这种事情一般需要策划去考虑然后解决，但是从程序上来说，确实存在这种需要特别处理的地方。在合服的时候，另一个问题是之前保证的角色名不重复是利用的各自区的accsvr，通常accsvr保证惟一性的做法是使用同一个数据库来保存需要排重的信息，但是对于不同的网络运营商，这个数据库很可能没办法统一起来，这样一来，当两个处于不同网络中的区需要合并的时候就出现了难以解决的问题，比如我们有一次把电信和网通的两个区进行合并，本来这两个区各自确实能够保证角色名唯一，但是当跨运营商合并的时候却会发现冲突。然后是服务器压力，不知道是由于当年设计这个架构的人没有考虑到还是当时不存在这样的问题，所以服务器横向扩展的能力是十分弱的，对于新开的副本，relay进程会根据gamesvr的压力来选择把新副本开在哪个gamesvr进程上，但对于常驻地图，却是写死在配置表里，绑定固定的gamesvr，而relay又没有提供动态添加gamesvr的功能，这导致了如果在服务器运行期间出现了单个服务器进程压力，除了重启服务器，几乎没有任何办法。这个在运营期暴露的很明显，由于GameSvr按照地图进行划分，当开新区的时候，玩家大量涌入同一张地图，导致单个GameSvr压力出现峰值，但这个时候却没办法动态的扩展进程进行分压，而导致服务器宕掉。在后期的运营中这样的情况屡见不鲜。后来我还听到过很多关于页游的架构，页游服务器整体上跟端游思路是类似的，由于客户端的通常通信方式不再像端游那样采用原生tcp连接，而是使用http等短连接的协议，所以在客户端连接的部分设计上更加灵活，而且大部分页游的游戏逻辑没有端游那么复杂， 在客户端的表现力有限的情况下，基本上整体的游戏服务器设计要更加精简，所以我看到通常服务器后端会更加偏重于如何进行横向扩展。上面我提到的架构扩展性差的问题，对比页游的滚服方式，体现的最明显了。这就是关于我上一个游戏服务器的样子了，下一篇开始我自己的服务器设计。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)中国领先的IT技术网站
51CTO旗下网站
Oline游戏的服务器负载均衡之层次结构
本文根据前面的文章继续了大型游戏平台的服务器负载均衡的话题，本文主要针对层次结构上的问题，将负载均衡的使用细化分析。
作者：佚名来源：互联网| 12:15
前面，我们针对在线游戏的大型用户平面负载均衡问题进行了剖析，现在，作为补充，我们在把一些内容进行一个拓展介绍。根据我们前面所说，数以万计的web应用要做到服务器的负载均衡并不是单一方面就能解决的，那么更多的方面是如何实现呢？
一般而言,只有在大型在线系统当中才有必要引入负载均衡,那么,多大的系统才能被称为大型系统呢?比如动辄同时在线数十万的网络游戏,比如同时在线数在10万以上的WEB应用,这些我们都可以理解为大型系统,这本身就是一个宽泛的概念｡
设计再好的服务器程序,其单个程序所能承载的同时访问量也是有限的,面对一个庞大且日益增长的网络用户群,如何让我们的架构能适应未来海量用户访问,这自然就牵涉到了负载均衡问题｡支持百万级以上的大型在线系统,它的架构核心就是如何将&百万&这么大的一个同时在线量分摊到每个单独的服务器程序上去｡真正的逻辑处理应该是在这最终的底层的服务器程序(如QQ游戏平台的游戏房间服务器)上的,而在此之前所存在的那些服务器,都可以被称为&引路者&,它们的作用就是将客户端一步步引导到这最终的负责真正逻辑的底层服务器上去,我们计算&百万级在线&所需要的服务器数量,也是首先考虑这底层的逻辑服务器单个可承载的客户端连接量｡
比如:按上篇我们所分析QQ游戏架构而言,假设每个服务器程序最高支持2W的用户在线(假设一台机子只运行一个服务器程序),那么实现150万的在线量至少需要多少台服务器呢?如果算得简单一点的话,就应该是:150/2=75台｡当然,这样算起来,可能并不能代表真正的服务器数量,因为除了这底层的服务器外,还要包括登录/账号服务器以及大厅服务器｡但是,由于登录/账号服务器和大厅服务器,它们与客户端的连接都属于短连接(即:取得所需要信息后,客户端与服务器即断开连接),所以,客户端给这两类服务器带来的压力相比于长连接(即:客户端与服务器始终保持连接)而言就要轻得多,它们的压力主要在处理瞬间的并发访问上｡
&短连接&,是实现应用层负载均衡的基本手段!!!如果客户端要始终与登录/账号服务器以及大厅服务器保持连接,那么这样作的分层架构将是无意义的,这也没有办法从根本上解决用户量不断增长与服务器数量有限之间的矛盾｡
当然,短连接之所以可以被使用并能维护正常的游戏逻辑,是因为在玩家看不到的地方,服务器与服务器之间进行了大量的数据同步操作｡如果一个玩家没有登录到登录服务器上去而是直接连接进了游戏房间服务器并试图进行游戏,那么,由于游戏房间服务器与大厅服务器和登录/账号服务器之间都会有针对于玩家登录的逻辑维护,游戏房间服务器会检测出来该玩家之前并没有到登录服务器进行必要的账号验证工作,它便会将玩家踢下线｡由此看来,各服务器之间的数据同步,又是实现负载均衡的又一必要条件了｡
服务器之间的数据同步问题,依据应用的不同,也会呈现不同的实现方案｡比如,我们在处理玩家登录这个问题上｡我们首先可以向玩家开放一些默认的登录服务器(服务器的IP及PORT信息),当玩家连接到当前的登录服务器后,由该服务器首先判断自己同时连接的玩家是不是超过了自定义的上限,如果是,由向与该服务器连接着的&登录服务器管理者&(一般是一个内部的服务器,不直接向玩家开放)申请仲裁,由&登录服务器管理者&根据当前各登录服务器的负载情况选择一个新的服务器IP和PORT信息传给客户端,客户端收到这个IP和PORT信息之后重定向连接到这个新的登录服务器上去,完成后续的登录验证过程｡
这种方案的一个特点是,在面向玩家的一侧,会提供一个外部访问接口,而在服务器集群的内部,会提供一个&服务器管理者&及时记录各登录服务器的负载情况以便客户端需要重定向时根据策略选择一个新的登录接口给客户端｡
采用分布式结构的好处是可以有效分摊整个系统的压力,但是,不足点就是对于全局信息的索引将会变得比较困难,因为每个单独的底层逻辑服务器上都只是存放了自己这一个服务器上的用户数据,它没有办法查找到其它服务器上的用户数据｡解决这个问题,简单一点的作法,就是在集群内部,由一个中介者,提供一个全局的玩家列表｡这个全局列表,根据需要,可以直接放在&服务器管理者&上,也可以存放在数据库中｡
对于逻辑相对独立的应用,全局列表的使用机会其实并不多,最主要的作用就是用来检测玩家是不是重复登录了｡但如果有其它的某些应用,要使用这样的全局列表,就会使数据同步显得比较复杂｡比如,我们在超大无缝地图的MMORPG里,如果允许跨服操作(如跨服战斗､跨服交易等)的话,这时的数据同步将会变得异常复杂,也容易使处理逻辑出现不可预测性｡
我认为,对于休闲平台而言,QQ游戏的架构已经是比较合理的,也可以称之为休闲平台的标准架构了｡那么,MMORPG一般的架构是什么样的呢?
MMORPG一般是把整个游戏分成若干个游戏世界组,每个组内其实就是一个单独的游戏世界｡而不同的组之间,其数据皆是相互独立的,并不象QQ 休闲平台一样所有的用户都会有一个集中的数据存放点,MMORPG的游戏数据是按服务器组的不同而各自存放的｡玩家在登录QQ游戏时,QQ游戏相关的服务器会自动为玩家的登录进行负载均衡,选择相对不忙的服务器为其执行用户验证并最终让用户选择进入哪一个游戏房间｡但是,玩家在登录MMORPG时,却没有这样的自动负载均衡,一般是由玩家人为地去选择要进入哪一个服务器组,之所以这样,是因为各服务器组之间的数据是不相通的｡其实,细致想来,MMORPG 的服务器架构思想与休闲平台的架构思想有异曲同工之妙,MMORPG的思想是:可以为玩家无限地开独立的游戏世界(即服务器组),以满足大型玩家在线;而休闲平台的思想则是:可以为玩家无限地开游戏房间以满足大量玩家在线｡这两种应用,可以无限开的都是&具有完整游戏性的游戏世界&,对于MMORPG而言,它的一个完整的游戏地图就是一个整体的&游戏世界&,而对于休闲平台,它的一个游戏房间就可以描述为一个&游戏世界&｡如果MMORPG作成了休闲平台那样的全服皆通,也不是不可以,但随之而来的,就是要解决众多跨服问题,比如:好友､组队､帮派等等的问题,所有在传统MMORPG里所定义的这些玩家组织形式的规则可能都会因为&全服皆通&而改变｡
架构的选择是多样性的,确实没有一种可以称得上是最好的所谓的架构,适合于当前项目的,不一定就适合于另一个项目｡针对于特定的应用,会灵活选用不同的架构｡但有一点,是可以说的:不管你如何架构,你所要作的就是--要以尽可能简单的方案实现尽可能的稳定､高效!【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条原创专题专题专题
24H热文一周话题本月最赞
讲师：3人学习过
讲师：2人学习过
讲师：3人学习过
精选博文论坛热帖下载排行
以Linux为代表的自由软件及其稳定性，逐渐在全世界崭露头角且备受重视。由于可以支持多种网络环境，因此在采用Linux系统之前，必须熟悉各种...
订阅51CTO邮刊