逆战server负载均衡的演化

发表于2015-09-17
评论1 387浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯游戏学院游戏策划行业精英群

361498939
逆战server负载均衡的演化

陈明建(jerrychen)

 

 

       在正式介绍server负载均衡策略演化细节前,我们先一起来看下逆战server的几个关键节点:

       上图中箭头曲线展示了负载均衡策略的演进史,柱状图展示了逆战PCU的几个里程碑节点。细心的同学可能已经发现,负载均衡策略的几次调整都在重大里程碑节点来临之前。2011.6内测前,我们于2010.12月正式完成均衡策略的第一次改版;2012.9月不限号测试前,我们完成了策略的第二次改版,这次改版从发起到完成历时较短,但还是顺利通过了60W在线的考验;2013.12月公测前,我们于2013.4月完成了第三次改版,顺利达成129W最高同时在线的目标。

       在历次改版中,我们秉承了“边运营边优化”的原则,从实际运营需求出发,以server的稳定性为第一原则,兼顾了可运维和可扩展性。目前回头来看这种策略还是比较成功的,把握了项目的发展脉搏,在特定的项目发展阶段做恰当的事情,避免了过度优化,

       我们先来看下逆战server的整体负载均衡策略,目前后台server采用了三级负载均衡策略,分别从用户接入,大厅频道分配,战斗server分配三个场景进行负载引导。具体如下图:

其中login server集群负责用户接入层的负载均衡;zone server集群实现大厅频道功能,与login server相配合,实现频道管理层的均衡;dsagent集群即为战斗server集群,该集群与zone server配合实现战斗server分配的均衡。接入层需要做负载均衡很好理解,但频道和战斗server的负载均衡为何要分开呢?这是另外一个话题,本文暂不涉及,如果有兴趣,线下交流J

三级负载均衡中,dsagent集群是本文要介绍的重点,负载均衡策略演化主要发生在zonedsagent之间。下面对各阶段采用的策略及其优缺点做个介绍,抛砖引玉。

1.      Zone ->dsm模式

20107月前,逆战后台采用这种模式。这种模式中,ds的管理模块dsm作为zone进程的一个类形式存在,并且ds server常驻内存中,采用多副本共用一个进程的方式。由于逆战采用UE3引擎,该引擎clientserver端共用一套代码,server端的代码没有针对linux专门进行优化,导致server端在内存使用以及稳定性方面存在很多问题,所以这种方式的问题是显而易见的,实际运营中必然无法满足逆战7*24小时的服务要求。因此在前期demo阶段过后,这种模式就被抛弃,从而有了第一次改版。

2.      Zone->dsa, 1->n模式

这种模型中dsdsagent(简称dsa)管理,每个副本使用一个ds进程,采用类似CGI的服务方式,“用后即焚”,规避了ds进程在linux下不稳定的问题(当然仅仅是规避,ds的稳定性问题花了我们大量的精力来解决)。同时zone不再直接申请ds,而是通过管理dsa的负载信息选择某个dsa来申请ds进程。

这种模式以CGI方式启动副本,对ds的启动时间提出了很高的要求。经过评估,我们发现ds的启动必须在1~3秒内完成,否则就影响到玩家体验,这带来了一个极大的技术挑战。这个技术难题最后在我们的技术大牛jiantang的手上得到完美解决。

从技术封测到开放性测试期间,采用的是上图所示的均衡模型。这期间顺利承担了8W PCU的压力,同时也暴露出该方案的几个缺陷:一是该方案中每个dsa仅为单个zone服务,而玩家在zone上的分布是动态的,这导致在实际运营中某些dsa的利用率很低,某些dsa超负荷运转,这种现象在平时运营中影响不大,但在冲线时影响很大,特别当是当玩家在zone上的分布存在较大不均衡时。二是在线运营时如果要不停服调整dsa的服务对象(zone),则需要手动修改配置,加上dsa的冷却时间较长(需要等待已启动的ds进程全部结束),不能满足在线迅速调配负载的需求。

考虑到这两个缺点,为了能够更好的应对接下来的开放性测试,我们server组同学提出了后面要介绍的第三、四两套方案。经过讨论,大家认为第四套方案应该是最终解决方案,但需要对代码进行较大修改,需要一段时间稳定,在当时紧迫的时间下,最终选择了第三套方案作为过渡方案。

3.      Zone->dsa, n->1模式

这种方案作为过渡性方案主要解决方案二中dsa利用率的问题,避免冲线时出现机器数足够,但负载能力不足的现象。该方案中,每个dsa可以为多个zone服务,从而规避了dsa负载浪费的问题。但明显地它存在以下两个缺陷,一是由于dsa上报负载信息是定时的,导致多个zone可能在心跳间隔期间扎堆向他们看到的“负载最轻”的dsa发请求,导致该dsa瞬间负载升高,增加请求失败率;二是为了减轻zone的“扎堆”现象,需要对根据zonedsa进行手动分组配置,在后续开放性测试中,我们发现前期的配置表配置工作很繁重,特别容易出错。

对于第一个缺点,我们采用有限重试的方式进行规避,第二个缺点,采用人工配置 工具检查的方式进行缓解。最终也顺利顶住了60W同时在线的压力。

当然我们的下一个目标是百万在线,开放性测试结束后,这个中间过渡方案也完成了它的使命。

4.      Zone->dsc->dsan->1->n模式

这套方案是目前逆战正在外网运营的方案,该方案中,我们在zonedsa之间增加了dscenter管理模块,由dscenter负责管理dsa负载信息,dsa的分组信息,以及zoneds的申请。也就是引入了中心节点管理来dsa。那dscenter不就成了单点吗?没错,这是这个方案的最大缺陷。不过我们通过备份部署dscenter的方案解决。由于dscenter上的负载信息可以认为是“随时”处于失效状态,因此只要备份dscenter在工作,整个系统就是稳定的。另外,在实际应用中,不同IDC独立部署dscenter及对应的备份dscenter,对机器数较多的IDC再进行dscenter拆分,部署多个dscenter,既减小了dscenter单点的风险,又增加了负载调度的灵活性。

2013年底的公测中,这个方案顶住了129W 最高在线的压力,其有效性得到了充分验证。

逆战server负载均衡演进史的简单介绍就到这里了。基于第四套方案的细小优化我们还在持续进行中,那会有第四次进化,第五套方案出现吗?看实际运营需求了J

原文链接

著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台