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

 

书接上回<高性能MMORPG通用服务端引擎设计之->基本概念篇>

 

上回说道我们将服务器组的职责划分为了,前端服务器,场景服务器,登录服务器,数据服务器...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来实现消息服务器。

 

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

 

posted on 2011-01-19 20:10 亚历山大同志 阅读(...) 评论(...) 编辑 收藏

导航

公告

统计