旧话重提: 关于大型MMO应用中的场景系统动态负载均衡问题

[大宝(sodme)]

据我所知, 目前big
world是有这样的一系统服务器动态负载均衡系统的,
不知道这里还有没有人在自己的MMO作类似这样的系统.
我说的动态均衡, 要求达到的目标是:
当发现一个区块的玩家很多之后,
把这个区块的玩家游戏逻辑转移给另外负载轻的场景服务器承担,
从而实现场景的动态负载均衡.

如果没人在作也没关系,
大家可以针对此点说说自己的看法,
比如要作这样的系统, 在设计方面,
我们应该去规划游戏服务器的体系架构. ths.

[胡人]

在我的实践中数据处理服务器就有类似需求，数据处理服务器是为各个游戏服务器服务的，游戏服务器在授权范围内进行查询和数据更新等操作，实际运行中需要多个数据处理服务器同时运行（主要是为了避免一台突然死掉的情况，其实一台就够用），他们之间负载均衡的需要暂时不高但是有数据同步的需要，以后随着要支持更多用户负载均衡需要也会越来越大。说到这里还不得不提一下性能，单台服务器性能的提高弱化了对负载均衡的需要，甚至在支持现有数量用户的情况下单台服务器还显得绰绰有余。

 

 

[xMan]

诚心请教胡人现在你做的网络游戏单台服务器用户数量能达到多少呀

[Collins]

hi sodme:

你近水楼台啊，问问你的同事，他们不是已经在用big world了吗？我也很想知道它是怎么实现的？实现到了哪种程度？

个人意见，网络服务器可以分为三类：

1、无状态独立服务器（如：Web服务器，短连接）
2、有状态独立服务器（如：休闲游戏服务器，一台服务器就是一个完整的世界）
3、有状态集群服务器（如：MMORPG服务器，一台服务器只负责部分场景）

对于第一种服务器，负载均衡技术有很多，如DNS/IP轮巡、NAT。
对于第二种服务器，加个网关，按照session转发请求就可以了，不存在动态负载均衡的需求。
对于MMORPG，服务器网络是不对等的，这种结构的网络应用，动态负载均衡比较困难，我的作法是从策划上就杜绝分布式计算的可能。

我看了big world的介绍，关于动态负载均衡的，那简直就是网格计算技术的一个具现，但是针对第3类服务器，真的可以适用网格计算吗？

盛大号称应用了网格计算技术，那不过是登录和计费，充其量是第1、2种应用。那么第3种呢？big world实现了吗？

欢迎有这方面实践经历的朋友一起讨论。

[xMan]

对于MMORPG，由于服务器网络是不对等的，一般采用SMP并行计算的方式，分布式并不是唯一选择。

[sunway]

我们公司的ZONA引擎有类似的系统。
他的里面有影子这个概念，处理边界的冲突。还有自动移动角色的功能。

[Alan Huang]

原来sunway是盛大的，听说M叔叔现在自己在上海又开了家公司了 ：）

ZONA有在盛大的某个项目中使用吗
 

On 4/5/06, sunway <sunh...@gmail.com> wrote:

我们公司的ZONA引擎有类似的系统。
他的里面有影子这个概念，处理边界的冲突。还有自动移动角色的功能。

--
Yours Sincerely,
Alan Huang

[胡人]

单台服务器能支持的用户数理论极限 ＝ 总带宽/每用户平均带宽

实际运行中单服务器支持的用户与具体游戏有关，有的游戏数据量很少，计算量也很少，能支持很多用户（超过1万），有的游戏数据量或（和）计算量都很大，只能支持比较少的用户（几千或几百）。

 

 

[胡人]

曾经问过一个朋友，他是做传奇类游戏私服的，他跟我说他弄的一款服务器每个server进程只支持28个用户，多了就算不过来，看来那个游戏计算量太大。

[大宝(sodme)]

不要偏题了吧?
我想讨论是单一游戏世界内各场景服务器的动态负载均衡(当然如果单一世界内只有一个场景服务器,
那自然是没有这个问题的),
而不是全服范围内的那种分布式架构.

[疯子阿虹]

首先，
你可以把服务器场景编号，然后让不同的场景服务器加载不同的场景。
因为在MMORPG中，总是有冷场景（人少）和热场景（人多）。
这样就可以把多个冷场景放在一台服务器上，而单个热场景放在单台服务器上。
玩家在切换场景的时候很可能就切换服务器。
这个是有些流行，而且比较方便的做法。

其次，
对于，你说的，
当发现一个区块的玩家很多之后,
把这个区块的玩家游戏逻辑转移给另外负载轻的场景服务器承担,

从而实现场景的动态负载均衡.

这个操作必须是保证客户端透明的，否则即使做了，也不会被采纳。
这样的话，你可以把所有的玩家数据放在一台服务器上，暂时叫做数据服务器。
而场景服务分散在多台服务器上，暂叫场景服务器群。
这样管理很麻烦，效率同时也不一定增加多少，
因为数据服务器和场景服务器群之间会有大量交互。
所以，这种方法，应该是很麻烦的。

客户端透明化的解释：
譬如在A区，游戏中有一个叫做“长安”的场景。
那么对于所有A区玩家（客户端）来说“长安”只能有一个。
不能因为服务器场景分布化了，而导致A区中的玩家张三和李四虽然都在“长安”，
但是互相看不到对方。这就是不透明化了。

大量交互的解释：
因为要达到透明化，所以假设场景服务器群中的场景服务器a和b。
这两台场景服务器都负责处理场景“长安”。
那么这两台场景服务器就必须要知道所有“长安”的数据，
不管他是否会处理到。

不知道你具体指那种，还是有更好的方案。

[xMan]

“有状态集群服务器（如：MMORPG服务器，一台服务器只负责部分场景）”
看来大家还是围绕《传奇》在转，没有办法呀

[大宝(sodme)]

我所指的是这种: 场景分格,
每个场景服务器负责其中若干格,
当某个场景中的某一格或几格出现负载过重时,
可以将此格或此些格的计算迁移到其它场景服务器上去.

如你所说:
1.此迁移要求是客户端透明的;
2.此迁移要求是动态自适应的.

此问题有足够难度, 据我所知,
不止一个团队刚开始有过这种想法,
但在后来的实施过程中都放弃了.

[大宝(sodme)]

不赞成这种说法, 负责部分场景,
并不能说就是围绕"传奇"在转.
WOW东西两块大陆也是分别由不同SERVER承担的,
你能说他也是围绕"传奇"在转? :)

[Collins]

sunway谈到了影子，我把它称为临界区，在连续场景中就是相邻的但是分布在不同server上的场景block的重叠区域，通常宽度是一个可视单位：50米。也就是说一台场景服务器拥有除了它额定的场景面积之外再向外扩沿50米，所以位于临界区内的场景物体其实有两份以上的拷贝。这么作的目的是把分布式计算转化为集中计算。我起初是这么设计的，但是后来发现，如果非临界区的对象和临界区对象产生交互，那么这个对象和它的影子在同步时会产生很多问题，后来我放弃了这种细粒度的同步，而是从策划上禁止不同服务器上的玩家产生复杂交互（利用边界山，河流等），比如战斗。当然像聊天这种纯广播试的交互是可以的。

[bruise]

我的理解:
如果将实时状态/持久数据/逻辑计算等三种处理分布在3种专用的服务器（集群）上，对需要加锁的状态和数据采用队列处理(可以根据逻辑划分多队列)
这样,最小系统存在4台服务器:
数据库服务器,状态服务器,计算服务器,队列服务器

对于游戏系统而言,主要追加的是计算服务器,而应用级均衡也是主要针对计算服务器

采取共享状态和队列方式,虽然降低了单个客户的响应实时性,但换来了整体的性能均衡和高访问量下的可伸缩性,
不知道这样设计是否过于理想化?(至少对开发影响挺大的)

[liu wp]

如果有这样的需求，游戏服务器之间肯定要单独开通道进行通讯了。依靠网关中转是不可能的，数据量太大。
可以给游戏服务器预留一个接口，通过配置打开。
这个只是想法，没试过

在 06-4-6，bruise<bru...@gmail.com> 写道：