网游能够通过扩展服务器集群从而支持无限制的用户吗?

已查看 37 次
跳至第一个未读帖子

老范

未读,
2007年5月31日 02:28:442007/5/31
收件人 高性能网络编程邮件列表
(我另外开一个帖, 讨论这个问题, 不在那个吵架帖问了)

一个世界对于游戏玩家是非常有吸引力的。 当然不是eve ,second life 那种2-3万人在线的一个世界。而是像征途那样100万用户在线
的一个世界。

征途现在已经用了集群,那么是什么原因把每个区设置在1-2万人在线这个规模呢?

sunway

未读,
2007年5月31日 02:47:192007/5/31
收件人 高性能网络编程邮件列表
对于MMO来说,单机能处理的用户始终是有限的,无限扩大用户数实际意义并不大。

Yun Fan

未读,
2007年5月31日 03:18:352007/5/31
收件人 dev4s...@googlegroups.com
不是指单机。 是指集群。 瓶颈出现在什么地方使得不能实现100万人同个世界?

liam

未读,
2007年5月31日 03:19:022007/5/31
收件人 高性能网络编程邮件列表
LZ说的应该不是指区的概念吧.应该是服吧.
区大一些.
征途一组服务器可以承载上W人.这并不是空谈的.我前一段在玩
你可以看一下Ghost Cheng 发过的贴子,里面包含了不少设计的思想.

无限的用户支持它是受硬件限制,比如说有带宽.并且在我们大多数游戏中每组服务器的人数基本上都是抛物线的增长方式.而不是双曲线.

> > 征途现在已经用了集群,那么是什么原因把每个区设置在1-2万人在线这个规模呢?- Hide quoted text -
>
> - Show quoted text -

sunway

未读,
2007年5月31日 03:33:592007/5/31
收件人 高性能网络编程邮件列表
由于MMO 实时性要求较高,单服能支撑的人数相对比较少。

其实大家可以把IM看做一个MMO,目前的IM都能支撑巨量用户。

> > 征途现在已经用了集群,那么是什么原因把每个区设置在1-2万人在线这个规模呢?- 隐藏被引用文字 -
>
> - 显示引用的文字 -

sunway

未读,
2007年5月31日 03:48:372007/5/31
收件人 高性能网络编程邮件列表
目前的IM系统单机都能带上W人。
网易的泡泡采用TCP协议,单机据说能带3W人以上(据说采用kqueue)
QQ的大部分协议是UDP,据说能到10W人单机UDP。
MSN不详,当然他的用户量非常大,协议也是TCP 类HTML文本协议。

如果采用UDP协议的话
而且还可以采用P2P方式来降低服务器和客户端的流量。

MMO数据交换量远远超过IM系统,单机负载有限,限制了他的用户数。


On 5月31日, 下午2时47分, sunway <sunhui...@gmail.com> wrote:

Yun Fan

未读,
2007年5月31日 03:53:332007/5/31
收件人 dev4s...@googlegroups.com
理解各位老大说的意思。

但是既然能够多台机器集群来支撑一个区(或者网游都叫一个服),那么是的这个区/服 不能无限扩展的原因出在哪里呢?

网络带宽也可以让idc 加的啊。

lijie

未读,
2007年5月31日 04:21:162007/5/31
收件人 dev4s...@googlegroups.com
在07-5-31,Yun Fan <fanyu...@gmail.com> 写道:
理解各位老大说的意思。

但是既然能够多台机器集群来支撑一个区(或者网游都叫一个服),那么是的这个区/服 不能无限扩展的原因出在哪里呢?

网络带宽也可以让idc 加的啊。

如果服务器实现了动态分块 (区),自然没有什么问题了,100万人在同一个大地图,就动态把地图切成更小的块分到更多物理服务器上,其它人少的服务器动态合并到某一个物理服务器上,这个实现起来非常困难,前段时间看过的"大型多人在线游戏"一书有提及,不过我相信很难实现一个稳定的版本。100万人太夸张了,服务器动态分区、动态转移数据通讯量都是非常大的,想在用户毫无察觉的情况下做应该是不可能。

征途这样的游戏,各个点位上只能站一个人,上面这种想法还是有可能实现的,魔兽这种许多人都可以重叠在一点上,怕是有些困难,一个点上叠几十人个,一块地图就没办法分得更小了。

sunway

未读,
2007年5月31日 04:24:302007/5/31
收件人 高性能网络编程邮件列表
一般网游服务器逻辑服务器主要处理用户和周围的对象(可能是其他玩家,怪物,NPC等)的操作。
交互产生的数据量是比较大,对实时性要求比较高。
我们可以做如下考虑:
如果用户发生交互的逻辑由于用户交互的对象在其他逻辑服务器上,因此需要多个服务器协同处理
,那么数据一致性和实时性很难保证,用户的体验也不好。

因此正常情况下MMO用户的逻辑数据不能在多个逻辑处理服务器间传递和处理。

IM一般情况下用户只和自己的几个好友进行消息传输,交互实时性要求不高,用户的消息
可以在多个服务器之间传递。
因此IM类的用户数据可以在多个逻辑服务器之间传递,并不会降低用户体验。

lijie

未读,
2007年5月31日 04:27:422007/5/31
收件人 dev4s...@googlegroups.com
或者这样,每台服务器本来就各开50个进程,启动时假设一台服务器负责一个地图,但这个地图是要分到50个进程上的。这样的架构,本来就需要把一个地图拆成多个小块,在单台机器上进行用户的转移,还可以更进一步,做以动态调整地图。哪台服务器压力大了,就让其中的一部分进程把数据转到其它服务器上。压力小时可能完成的是本机进程间转移,压力大时完成机器间转移而已,还是进程间。

想想而已,实现难度可想而知。

在07-5-31,lijie <cpu...@gmail.com> 写道:

diclogic

未读,
2007年5月31日 05:03:312007/5/31
收件人 高性能网络编程邮件列表
难就难在:压力大时还要进行转移的操作,用户多时还要对用户多的那个zone进行影响用户体验的事情。
兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?


On May 31, 4:27 pm, lijie <cpun...@gmail.com> wrote:
> 或者这样,每台服务器本来就各开50个进程,启动时假设一台服务器负责一个地图,但这个地图是要分到50个进程上的。这样的架构,本来就需要把一个地图拆成多个小块,在单台机器上进行用户的转移,还可以更进一步,做以动态调整地图。哪台服务器压力大了,就让其中的一部分进程把数据转到其它服务器上。压力小时可能完成的是本机进程间转移,压力大时完成机器间转移而已,还是进程间。
>
> 想想而已,实现难度可想而知。
>

> 在07-5-31,lijie <cpun...@gmail.com> 写道:
>
>
>
> > 在07-5-31,Yun Fan <fanyun2...@gmail.com> 写道:

lijie

未读,
2007年5月31日 05:11:222007/5/31
收件人 dev4s...@googlegroups.com
压力不是突然增大的,慢慢增大时就会进行转移操作了,不同的是压力大的时候,各进程负责的地图区块变小,这样用户行走很容易转移不同进程,通讯量增大。

我用50个进程来模拟50台机器,这样就不需要动态分区了,压力小时这假设这50个进程可以负责一个地图,压力大时其中一些进程把工作转到其它服务器上,降低了本机压力,进程数没变。

把动态分区问题转变成动态转移问题,后者难度显然小得多,如果服务器架构之初就这么做了,自然不用区分是本机进程还是其它机器。需要实现一个调度服务器,它的稳定性和正确性应该得到保证,它只负责根据压力转移地图区块到不同服务器,不负责用户转移工作,否则它的压力将非常大。当然压力本来不是用户造成的,各服务器需要定时把压力情况通知给该调度服务器。

突然想到,这不是erlang的思想嘛,稍有不同,但都是进程。呵呵。

在07-5-31,diclogic <dicl...@gmail.com> 写道:

sunway

未读,
2007年5月31日 05:16:572007/5/31
收件人 高性能网络编程邮件列表
最大的问题是用户的操作处理不能被多个服务器同时处理,这是MMO很难做成完全分布式的原因。
比如google可以把用户的请求map到多个服务器处理,而MMO很难这么做。

On 5月31日, 下午5时11分, lijie <cpun...@gmail.com> wrote:
> 压力不是突然增大的,慢慢增大时就会进行转移操作了,不同的是压力大的时候,各进程负责的地图区块变小,这样用户行走很容易转移不同进程,通讯量增大。
>

> 我用50个进程来模拟50台机器,这样就不需要动态分区了,压力小时这假设这50个进程可以负责一个地图,压力大时其中一些进程把工作转到其它服务器上,降低了 本机压力,进程数没变。


>
> 把动态分区问题转变成动态转移问题,后者难度显然小得多,如果服务器架构之初就这么做了,自然不用区分是本机进程还是其它机器。需要实现一个调度服务器,它的稳 定性和正确性应该得到保证,它只负责根据压力转移地图区块到不同服务器,不负责用户转移工作,否则它的压力将非常大。当然压力本来不是用户造成的,各服务器需要 定时把压力情况通知给该调度服务器。
>
> 突然想到,这不是erlang的思想嘛,稍有不同,但都是进程。呵呵。
>

> 在07-5-31,diclogic <diclo...@gmail.com> 写道:


>
>
>
>
>
> > 难就难在:压力大时还要进行转移的操作,用户多时还要对用户多的那个zone进行影响用户体验的事情。
> > 兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?
>
> > On May 31, 4:27 pm, lijie <cpun...@gmail.com> wrote:
>

> > 或者这样,每台服务器本来就各开50个进程,启动时假设一台服务器负责一个地图,但这个地图是要分到50个进程上的。这样的架构,本来就需要把一个地图拆成多个 小块,在单台机器上进行用户的转移,还可以更进一步,做以动态调整地图。哪台服务器压力大了,就让其中的一部分进程把数据转到其它服务器上。压力小时可能完成的 是本机进程间转移,压力大时完成机器间转移而已,还是进程间。


>
> > > 想想而已,实现难度可想而知。
>
> > > 在07-5-31,lijie <cpun...@gmail.com> 写道:
>
> > > > 在07-5-31,Yun Fan <fanyun2...@gmail.com> 写道:
>
> > > > > 理解各位老大说的意思。
>
> > > > > 但是既然能够多台机器集群来支撑一个区(或者网游都叫一个服),那么是的这个区/服 不能无限扩展的原因出在哪里呢?
>
> > > > > 网络带宽也可以让idc 加的啊。
>
> > > > 如果服务器实现了动态分块
>

> > (区),自然没有什么问题了,100万人在同一个大地图,就动态把地图切成更小的块分到更多物理服务器上,其它人少的服务器动态合并到某一个物理服务器上,这个 实现起来非常困难,前段时间看过的"大型多人在线游戏"一书有提及,不过我相信很难实现一个稳定的版本。100万人太夸张了,服务器动态分区、动态转移数据通讯 量都是非常大的,想在用户毫无察觉的情况下做应该是不可能。
>
> > 征途这样的游戏,各个点位上只能站一个人,上面这种想法还是有可能实现的,魔兽这种许多人都可以重叠在一点上,怕是有些困难,一个点上叠几十人个,一块地图就没 办法分得更小了。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

lijie

未读,
2007年5月31日 05:18:012007/5/31
收件人 dev4s...@googlegroups.com
"兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?"
这个问题没回答到。是把单个地图切分成50块,给50个进程,用户在同一地图上跑的时候就可能在各个进程之间转移。
压力大的时候,其中一些进程把数据转移到其它服务器,自己不再耗CPU,相当于把CPU压力分担出去了。
简单一句话,就是用静态分区(50个固定进程)取代动态分区。

如果不熟悉动态分区这个概念,可以看一下"大型多人在线游",里面有简短的描述,跨区服务器那部分,讲的还行。

上面的静态分区,还是要涉及到2个在不同进程中的人相互战斗的问题,这本书也提到了,相邻进程(书中是服务器)要保存一些边界重复数据,这个重复区块大小也是有说头的。

总之难度还是相当高的。

在07-5-31, lijie <cpu...@gmail.com> 写道:

sunway

未读,
2007年5月31日 05:25:322007/5/31
收件人 高性能网络编程邮件列表
2003年时我就听说过这样的想法,而且那个时候已经有这样的实现的MMO引擎,可惜由于其他原因,这个引擎
目前已经失败。
个人综合考虑:
边界无缝地图目前实现只有技术上的价值,实际用处并不大,而且国内MMO的环境恶劣,外挂很多,尤其是复制装备问题是无缝地图的最大的挑战。
而且目前用户也接受跳地图短暂的黑屏或者动画。
以后如果网络条件好了,外挂没有这么猖獗,无缝地图还是可以尝试的。

On 5月31日, 下午5时18分, lijie <cpun...@gmail.com> wrote:
> "兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?"
> 这个问题没回答到。是把单个地图切分成50块,给50个进程,用户在同一地图上跑的时候就可能在各个进程之间转移。
> 压力大的时候,其中一些进程把数据转移到其它服务器,自己不再耗CPU,相当于把CPU压力分担出去了。
> 简单一句话,就是用静态分区(50个固定进程)取代动态分区。
>
> 如果不熟悉动态分区这个概念,可以看一下"大型多人在线游",里面有简短的描述,跨区服务器那部分,讲的还行。
>
> 上面的静态分区,还是要涉及到2个在不同进程中的人相互战斗的问题,这本书也提到了,相邻进程(书中是服务器)要保存一些边界重复数据,这个重复区块大小也是有 说头的。
>
> 总之难度还是相当高的。
>

> 在07-5-31,lijie <cpun...@gmail.com> 写道:


>
>
>
>
>
> > 压力不是突然增大的,慢慢增大时就会进行转移操作了,不同的是压力大的时候,各进程负责的地图区块变小,这样用户行走很容易转移不同进程,通讯量增大。
>

> > 我用50个进程来模拟50台机器,这样就不需要动态分区了,压力小时这假设这50个进程可以负责一个地图,压力大时其中一些进程把工作转到其它服务器上,降低了 本机压力,进程数没变。
>
> > 把动态分区问题转变成动态转移问题,后者难度显然小得多,如果服务器架构之初就这么做了,自然不用区分是本机进程还是其它机器。需要实现一个调度服务器,它的稳 定性和正确性应该得到保证,它只负责根据压力转移地图区块到不同服务器,不负责用户转移工作,否则它的压力将非常大。当然压力本来不是用户造成的,各服务器需要 定时把压力情况通知给该调度服务器。
>

> > 突然想到,这不是erlang的思想嘛,稍有不同,但都是进程。呵呵。
>

> > 在07-5-31,diclogic <diclo...@gmail.com> 写道:


>
> > > 难就难在:压力大时还要进行转移的操作,用户多时还要对用户多的那个zone进行影响用户体验的事情。
> > > 兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?
>
> > > On May 31, 4:27 pm, lijie <cpun...@gmail.com> wrote:
>

> > > 或者这样,每台服务器本来就各开50个进程,启动时假设一台服务器负责一个地图,但这个地图是要分到50个进程上的。这样的架构,本来就需要把一个地图拆成多个 小块,在单台机器上进行用户的转移,还可以更进一步,做以动态调整地图。哪台服务器压力大了,就让其中的一部分进程把数据转到其它服务器上。压力小时可能完成的 是本机进程间转移,压力大时完成机器间转移而已,还是进程间。


>
> > > > 想想而已,实现难度可想而知。
>
> > > > 在07-5-31,lijie <cpun...@gmail.com> 写道:
>
> > > > > 在07-5-31,Yun Fan < fanyun2...@gmail.com> 写道:
>
> > > > > > 理解各位老大说的意思。
>
> > > > > > 但是既然能够多台机器集群来支撑一个区(或者网游都叫一个服),那么是的这个区/服 不能无限扩展的原因出在哪里呢?
>
> > > > > > 网络带宽也可以让idc 加的啊。
>
> > > > > 如果服务器实现了动态分块
>

Yun Fan

未读,
2007年5月31日 05:32:502007/5/31
收件人 dev4s...@googlegroups.com
多谢各位不吝指教。 我的理解不知道对不对。

1.  单个服务器肯定不可能支撑无限用户,因此需要多个服务器集群
2.  当集群的时候如果是采用静态分割地图。 那么如果大量客户涌入同一个区域,这个服务器就挂了
3.  如果采用动态地图支持, 这个开发难度过大, 各个服务器之间互相动态接管开销也很大。采用动态平衡的话理论上可以解决问题2; 但是如果像魔兽这样的多个人站在一个点上,如果1万人站到同一个点, 那么这台服务器也挂了。(好在可能性很小啊)
4.  无论采用动态还是静态分割, 地图边缘上会有问题。 如果两个人正好分在两台机器上,那么互相之间传送消息就很麻烦了,而且会影响游戏速度。 而且一个人从一个服务器跑到另一个服务器就会出现延迟。

所以说无法很好的扩展无限用户,瓶颈出现在世界的交互上。 确实很难办。


顺便问一下, 比如征途,当我从凤凰城去野兽谷,到了地图边缘,系统就停顿一下,然后我就和凤凰城无关了,也看不到凤凰城边缘的人物了。 这是因为切了服务器吧?(魔兽就好一点,地图是连续的)


另外我一直以为 IM 是点对点交互的,服务器只是帮大家中介一下,然后im 之间自己通讯,和服务器无关。不知道这个理解对吗?

Yun Fan

未读,
2007年5月31日 05:39:282007/5/31
收件人 dev4s...@googlegroups.com
呵呵, 原来传说中的复制装备是用无缝地图来搞的啊。 能否详细说说啊?   外挂的人怎么能够精确找到地图的结合部啊,对客户端是透明的啊。




On 5/31/07, sunway <sunh...@gmail.com > wrote:

Ghost Cheng

未读,
2007年5月31日 05:54:592007/5/31
收件人 dev4s...@googlegroups.com
对于无缝地图,我曾经有过一个腹稿,一直没有时间去实现,也不是很成熟。
大概的意思是:
当用户接近当前所在地图的边界时,client开启第二个socket连接,连到边界另一边的场景服务器上。这样客户端从2个场景接收地图角色的数据,用于显示。
当用户跨边界的时候,由于新场景的连接已经建立,所以不会出现卡机等待的显现,
当在新场景里,离边界超过一定距离后,断开旧场景的连接。
每个场景的地图大小,可以设计的小一些,以防止大量玩家挤在一个场景上,但是这里说的小,是隐藏在服务器上的小,玩家可以感觉不到,应该让玩家觉得,四周的多个场景,是一个完整的世界。
当然这种方式的缺点是,相邻的2个场景服务器之间必须存在一个通讯通道,用于处理player数据的迁移。这里可能会遇到很多比较难办的问题。

不过话说回来,无限人数的MMO,没什么实际意义,大多数玩家,喜欢去新区建号玩,开的时间很久的区,一般继续创建新号的玩家不多,因为在老区里,新人想赶超老玩家,很困难。这种设计,我觉得不适合,等级、PK观念严重的游戏。

On 5/31/07, sunway <sunh...@gmail.com> wrote:


--
Sincerely,
Ghost Cheng
Email : ghost...@gmail.com

qiaojie

未读,
2007年5月31日 06:20:052007/5/31
收件人 dev4s...@googlegroups.com
呃~~ 做网关的人居然还会想到开新连接去连接新场景....


在07-5-31,Ghost Cheng <ghost...@gmail.com> 写道:

lijie

未读,
2007年5月31日 06:24:382007/5/31
收件人 dev4s...@googlegroups.com
内部服务器对用户可见了,可能带来新的问题。如果是通过网关,用户不需要建立这么多连接吧,在网关上解决掉?

在07-5-31,Ghost Cheng <ghost...@gmail.com> 写道:
对于无缝地图,我曾经有过一个腹稿,一直没有时间去实现,也不是很成熟。

Ghost Cheng

未读,
2007年5月31日 06:24:442007/5/31
收件人 dev4s...@googlegroups.com
呃。。。什么叫"做网关的人"。。。难不成做过网关,就不能做逻辑了。。。。
技术性种族歧视。。。。恶寒。。。。

qiaojie

未读,
2007年5月31日 06:25:552007/5/31
收件人 dev4s...@googlegroups.com
哦,口误...
是做过网关的人

Ghost Cheng

未读,
2007年5月31日 06:31:352007/5/31
收件人 dev4s...@googlegroups.com
我这里说的第二个连接,可以理解成逻辑的第二个连接,不一定非要是真正的去连接。可以直接在从网关上连接第二个场景。
上面说的只是一种思路,具体实现的时候,可以根据具体的构架去调整。以前有的游戏是没有网关的,比如奇迹。

Qinglan

未读,
2007年5月31日 07:13:032007/5/31
收件人 dev4s...@googlegroups.com
老兄,用你的名字,ghost,来解决这个问题,会更好
 
大家果然都是关注高性能"网络"编程的,这概念都出来好久了
 
参考bigworld, tnl

 

liam

未读,
2007年5月31日 07:21:482007/5/31
收件人 高性能网络编程邮件列表
对于无限大地图.我们为什么不能从设计就开始入手呢?在要独立与不同服务器地图边缘在设计的时候就减少其交换数据的空间.比如边缘较多的障碍物等等.
如果全是平原我觉得在服务器间这样做数据交换不现实..

On 5月31日, 下午6时31分, "Ghost Cheng" <ghost.ch...@gmail.com> wrote:
> 我这里说的第二个连接,可以理解成逻辑的第二个连接,不一定非要是真正的去连接。可以直接在从网关上连接第二个场景。
> 上面说的只是一种思路,具体实现的时候,可以根据具体的构架去调整。以前有的游戏是没有网关的,比如奇迹。
>

> On 5/31/07, lijie <cpun...@gmail.com> wrote:
>
>
>
>
>
> > 内部服务器对用户可见了,可能带来新的问题。如果是通过网关,用户不需要建立这么多连接吧,在网关上解决掉?
>

> > 在07-5-31,Ghost Cheng <ghost.ch...@gmail.com> 写道:


> > > 对于无缝地图,我曾经有过一个腹稿,一直没有时间去实现,也不是很成熟。
> > > 大概的意思是:
>
> > 当用户接近当前所在地图的边界时,client开启第二个socket连接,连到边界另一边的场景服务器上。这样客户端从2个场景接收地图角色的数据,用于显示 。
> > > 当用户跨边界的时候,由于新场景的连接已经建立,所以不会出现卡机等待的显现,
> > > 当在新场景里,离边界超过一定距离后,断开旧场景的连接。
>

> > 每个场景的地图大小,可以设计的小一些,以防止大量玩家挤在一个场景上,但是这里说的小,是隐藏在服务器上的小,玩家可以感觉不到,应该让玩家觉得,四周的多个 场景,是一个完整的世界。
>
> > 当然这种方式的缺点是,相邻的2个场景服务器之间必须存在一个通讯通道,用于处理player数据的迁移。这里可能会遇到很多比较难办的问题。
>
> > 不过话说回来,无限人数的MMO,没什么实际意义,大多数玩家,喜欢去新区建号玩,开的时间很久的区,一般继续创建新号的玩家不多,因为在老区里,新人想赶超老 玩家,很困难。这种设计,我觉得不适合,等级、PK观念严重的游戏。
>
> --
> Sincerely,
> Ghost Cheng
> Email : ghost.ch...@gmail.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -

lijie

未读,
2007年5月31日 07:58:592007/5/31
收件人 dev4s...@googlegroups.com
原来早有实现。。

在07-5-31,Qinglan <helloq...@gmail.com> 写道:

diclogic

未读,
2007年5月31日 08:36:362007/5/31
收件人 高性能网络编程邮件列表
-这书我两年前看过,回忆不清楚了,不过在这之前我就想到过这个办法,需要跨进程同步的只是border中的对象和他的shadow/ghost,实现
起来没什么问题,像liam说过也可以通过巧妙手段尽量限制对象在这个区域出现,wow就是这样做的。这种做法要求border宽度的选取很巧妙。最近
我在想一个更好的办法,思路跟这完全不同,可以突破这些限制,但还没有时间去研究这个设计使它成熟。像sunway说的,不能将耦合因素正交分解是一个
影响server进行并行计算的难点,我也在想这个问题。
-听你说"迁移进程"让我想到了VM,dump进程的所有资源,然后在适当的时间适当的地点再恢复出来,系统级的解决方案,很有意思,希望谁有时间能成
为linux社群的contributor贡献一点代码。
-你说的50块也就是这样一个有border的区域,这个区域的大小也要巧妙衡量,我觉得可以参考相对论的研究,速度与时空关系。
-既然是动态转移,就可能会存在碎片,一条主干道被意外地分散于多个server肯定是个坏消息。保持块之间的spacial coherence,用
一个评估函数完成对转移操作的定量分析,让相邻区块尽可能的存在于一个server上,换句话说同一server上的区块应该尽可能聚拢。
-有前端服务/proxy的话,可以使这些行为对用户透明。

On May 31, 5:18 pm, lijie <cpun...@gmail.com> wrote:
> "兄弟你说的50这个数字有什么物理意义?指所有地区吗?每个地区在每个server上都有一个shadow?"
> 这个问题没回答到。是把单个地图切分成50块,给50个进程,用户在同一地图上跑的时候就可能在各个进程之间转移。
> 压力大的时候,其中一些进程把数据转移到其它服务器,自己不再耗CPU,相当于把CPU压力分担出去了。
> 简单一句话,就是用静态分区(50个固定进程)取代动态分区。
>
> 如果不熟悉动态分区这个概念,可以看一下"大型多人在线游",里面有简短的描述,跨区服务器那部分,讲的还行。
>
> 上面的静态分区,还是要涉及到2个在不同进程中的人相互战斗的问题,这本书也提到了,相邻进程(书中是服务器)要保存一些边界重复数据,这个重复区块大小也是有说头的。
>
> 总之难度还是相当高的。
>

> 在07-5-31,lijie <cpun...@gmail.com> 写道:


>
>
>
> > 压力不是突然增大的,慢慢增大时就会进行转移操作了,不同的是压力大的时候,各进程负责的地图区块变小,这样用户行走很容易转移不同进程,通讯量增大。
>
> > 我用50个进程来模拟50台机器,这样就不需要动态分区了,压力小时这假设这50个进程可以负责一个地图,压力大时其中一些进程把工作转到其它服务器上,降低了本机压力,进程数没变。
>
> > 把动态分区问题转变成动态转移问题,后者难度显然小得多,如果服务器架构之初就这么做了,自然不用区分是本机进程还是其它机器。需要实现一个调度服务器,它的稳定性和正确性应该得到保证,它只负责根据压力转移地图区块到不同服务器,不负责用户转移工作,否则它的压力将非常大。当然压力本来不是用户造成的,各服务器需要定时把压力情况通知给该调度服务器。
>
> > 突然想到,这不是erlang的思想嘛,稍有不同,但都是进程。呵呵。
>

> > 在07-5-31,diclogic <diclo...@gmail.com> 写道:

qiaojie

未读,
2007年5月31日 08:45:272007/5/31
收件人 dev4s...@googlegroups.com
看来老兄确实比较缺乏对于整体设计的思考,对于一套设计良好的分布式系统来说,后端连接什么服务对于客户端来说可以是完全透明的,让客户端去关心连什么服务器那是糟糕的设计。

diclogic

未读,
2007年5月31日 08:57:032007/5/31
收件人 高性能网络编程邮件列表
我的名字是粉色的。。。太不幸了。。。

qiaojie

未读,
2007年5月31日 09:02:192007/5/31
收件人 dev4s...@googlegroups.com
哈哈,你说的那个是TEROZONA吧,根本没跑起来过。BigWorld号称实现了无缝世界,网易似乎有用过,不过貌似也不咋样。
关于无缝世界至今我看到过两种实现。第一种是分割区域,每个服务器运行几个区域,游戏逻辑直接在区域服务器里计算,区域之间通过某些同步算法来同步状态,这个实现理论上可行,但是我没有具体实践过。第二种是用一组玩家服务器单独计算每个用户的游戏逻辑,用户之间的交互通过各个服务器之间的RPC调用实现,而广播则通过单独一台区域服务器实现。三年前我们做的网游(就是那个用ICE开发的Wish,后来项目取消了)就是按照这个架构来的,实践下来基本可行。不过这个方案的问题也比较多,主要是RPC通讯的开销很大,不优化的话性能很糟糕。


 
在07-5-31, sunway <sunh...@gmail.com> 写道:

qiaojie

未读,
2007年5月31日 09:10:212007/5/31
收件人 dev4s...@googlegroups.com
其实万人在线无缝世界这种东西也就是给程序员爽爽的产物,在商业上的价值并不大,实现这样一套系统不但程序开发成本很高,美术、策划同样要付出极大代价,最后导致项目失败的概率是99.9999%。我曾经也比较迷信技术这玩意,花了不少时间去研究,如果上天给我再来一次的机会的话,我会说服我的老板用最简单最低成本的方法来实现的。

 
在07-5-31,qiaojie <qia...@gmail.com> 写道:
回复全部
回复作者
转发
0 个新帖子