[转载]高性能MMORPG通用服务端引擎设计之->基本概念篇二

baacloud免费翻墙vpn注册使用

[转载]高性能MMORPG通用服务端引擎设计之->基本概念篇二 – 懒人居 – Coding for fun – 博客园.

上回说道我们将服务器组的职责划分为了,前端服务器,场景服务器,登录服务器,数据服务器…etc.

如图:

Logic-Service   Logic-Service    DB-Service

|                     |                     |

———————————–

|

Scene Manager

|

————————————-

|                       |                      |

Front Server   Front Server     Login Server

|                      |

Client             Client

不过经过思考后发现这个结构有点问题。

问题何在呢?我们来好好分析一下游戏的逻辑后会发现,整个MMORPG的服务端逻辑,其实是对服务端事件的响应,这里有两种事件,一种是对自身属性 的改变(比如切换技能,向腰带放入药瓶之类的),一种是改变其他玩家属性,或者是需要通知其他玩家知道的自身属性改变(比如,攻击对方,自己回血,换装, 移动等),也就是前文中我们分析发生在场景中的事件,第二种事件远远超过第一种事件,而且大部分的业务逻辑也发生在这些事件中,所以这类事件的处理需要消 耗更多的CPU。这样就带来问题了,前端服务器的压力主要在IO,而场景服务器的压力主要在CPU,那么如果分开在不同的机器上部署,那么这两边服务器的 压力就不均衡了,前端服务器的CPU剩余很多,场景服务器的CPU又不够用。所以我决定将这两个部分再次合并起来,合成Logic服务,然后多个 Logic服务并行运行。

所有的游戏逻辑都在逻辑服务中运算,但是按照MMORPG的业务,所有的逻辑基本都是按照场景来分布的,所以这个时候我门又面临2难的选择题了。第 一种方案是,我们可以按照场景来组织逻辑,比如服务器A负责1,3,5,7场景,服务器B负责2,4,6场景,因为场景之间的人数不平均,有的场景人多 (比如某某城内,正在被大批人追杀的BOSS所在地),有的场景人少(比如运行一段时间后的新手村),而且游戏中的热点场景是动态变化的,随着游戏进程的 发展会有变化。所以这个情况下我们需要一个场景管理服务,这个服务用于监控每个逻辑服务,将热点场景所在的服务里的其他场景迁移到空闲逻辑服务器。这个逻 辑需要客户端提供支持,要实现服务器的软切换。还有一种方式是将场景的逻辑随机分布到所有逻辑服务器上,场景间的联系通过消息来传递,由一个消息服务器来 为所有场景提供广播组来分发消息。这样就会多个消息服务器出来。这两个方案中第一个对单个玩家来说延迟最小,但是如果场景管理做得不好就会造成CPU资源 分布不均匀,还有就是场景容量受到单个进程处理能力极限的局限。第二种方案延迟肯定大过第一种,但是场景的容量不受单个进程计算能力的影响,扩展性更好一 点。

最后我决定用Python来实现这个想法,一,有丰富的基础框架可以选择,比如用高性能的Gevnet或者Eruasia来作为TCP Server的基础。二是Python本来就是动态的,所以不需要再嵌入另一个动态语言来适应多变的业务逻辑了。其三是Python是动态类型的,在实现 消息服务的时候更方便。本来打算用erlang的,不过暂时对OTP还不是很熟悉所以暂时作罢,不过如果采用第二种方式的话我可能会用Erlang来实现 消息服务器。

下一章直接进入实现阶段,并且无论如何我都会把这个玩意儿弄出来,如果没有公司愿意花钱让我弄,我就业余时间自己弄出来开源,哼哼

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏