游戏服务器设计的相关内容

时间:2009-11-20   来源:haooooooo博客   网友评论:0   人气: 371 作者:

作者Blog: http://blog.csdn.net/lfhfut
MSN: beyondlimit2001@hotmail.com

我不得不承认,我的能力不足以写出一个100%不会宕机的游戏服务器程序,这也不能全怪我的能力太弱,谁让咱国内网游玩家数量庞大,哪个游戏刚上线时没有挤的爆满过?还有些或是猎奇,或是谋私的个人和组织,在制造着千奇百怪,匪夷所思的数据包及操作流程来试探你的服务器。这些都曾是我在服务器宕机后向老板开脱的理由。

 

当WOW终于来到中国时,我一边欣喜着终于可以在艾泽拉斯的大陆上自由翱翔,一边却咒骂着9C的破服务器,动不动就宕机。当然,身为游戏程序设计师的我明知道,这大部分的错误都不应归罪于代理商9C,但是,谁让blizzard是我心目中的神,谁又让WOW成为我游戏制作的教科书呢。好吧,我知道上面这段极力追捧blizzard跟WOW的话可能早已让你恶心连连,不堪入目了,对不起,忘了这一节,让我们继续。

 

 

服务器宕机后都发生了些什么?

 

显然的,宕机后玩家会骂,就像我在玩WOW时那样,骂游戏公司,骂老板,骂GM。非常抱歉,我们可爱的玩家们似乎并不清楚,这个时候最该骂的其实是我们这些程序员们。长久的遗忘被我们当成了包容,以至于游戏程序员在公司里都养成了趾高气扬,不可一世的坏毛病:看吧,策划们,你们做的太烂了,数值不平衡,玩法没新意,只会照抄WOW跟大菠萝,能怪玩家骂你们吗?运营不得力,买服务器的钱不知道去了哪里,游戏里卡的要死,偶尔办个活动还没半点吸引力,能不被玩家骂你是无良运营商吗?GM们能不天天被骂家指着骂吗?……呃,又扯远了。

 

赶紧先把服务器重启吧。老板正站在你的身后,一脸愁容,虽然暂时还没有发作,但看得出来:老板很生气,后果很严重!

玩家们很快又回来了,不得不为玩家们的毅力和执着精神而感动,更为自己的错误而愧疚,凌晨时分,服务器启了又宕,宕了又启,如此反复,可热情的玩家们依然陪着我在折腾。哦,当年安其拉开门的时候,我也曾这样折腾过。

这个时候不是你一个人在战斗。GM们在忙碌地处理着玩家不断打来的投诉电话:刚买的装备在宕机后消失了;花光了身上所有材料合成的武器回档了,但材料却没有还给我……数据库维护组的同事们也在紧张的恢复着数据,尽可能的将玩家的损失减到最少。

 

真是一件令人沮丧的事。

 

 

真的该试着做点什么了吧!

 

既然我们非常不愿意看到宕机的情况发生,但又无法100%保证写出来的服务器程序一定不会出错,那我们就在当机发生后的抢救措施上花点功夫,让玩家的损失不至于太大,也让我们的维护人员少些压力吧。

 

一个最简单也最有效的做法是为每一台服务器都配备物理冗余,同步更新冗余服务器上的状态,当宕机发生时,立即将处理切换到后备服务器上。只是,物理冗余的代价太大,从成本方面考虑,老板可能不大愿意点头。

 

既然不能做硬冗余,那就再来考虑软的吧。

如果只是简单的启动冗余进程,其实是换汤不换药的做法。原来能跑1000人的服务器,由于同时运行了两个相同的进程,使得CPU和内存开销都翻了倍,结果是只能跑500人了。还是要加服务器。

 

看来只能更深一层,从架构设计上来动手了。

假设我们的游戏世界是由多个独立场景构成的,那么在实现上我们可以让这些场景在进程上也独立,这样做的好处是可以使得一个场景的宕机不会影响到其他场景的正常运行。如果我们的游戏世界物理上没有分隔,是一个无缝的大世界,我们也可以人为的将其分成多个独立区域,所需要做的额外工作是处理好那些站在区域边界附近的对象。事实上,现在的无缝大世界也都是这样实现的。

 

有了这样一个前提,我们再来看这个已宕掉的场景该如何处理。

还是老办法,赶紧先把它拉起来吧。一个具体可行的方案是,由场景管理器,或者你也有可能叫它世界服务器,来监视各个场景进程的运行状态,当某个场景异常失去联系时,由管理器来将其重新启动。这里需要再花点心思的是,如何让玩家数据正常地发送到新启动的场景进程中,而且这个过程对于客户端来说是透明的。


 

文章评论