网游能够通过扩展服务器集群从而支持无限制的用户吗？
老范
一个世界对于游戏玩家是非常有吸引力的。 当然不是eve ，second life 那种2-3万人在线的一个世界。而是像征途那样100万用户在线
的一个世界。
征途现在已经用了集群，那么是什么原因把每个区设置在1-2万人在线这个规模呢？
sunway
Yun Fan
liam
区大一些.
征途一组服务器可以承载上W人.这并不是空谈的.我前一段在玩
你可以看一下Ghost Cheng 发过的贴子,里面包含了不少设计的思想.
无限的用户支持它是受硬件限制,比如说有带宽.并且在我们大多数游戏中每组服务器的人数基本上都是抛物线的增长方式.而不是双曲线.
> > 征途现在已经用了集群，那么是什么原因把每个区设置在1-2万人在线这个规模呢？- Hide quoted text -
>
> - Show quoted text -
sunway
其实大家可以把IM看做一个MMO，目前的IM都能支撑巨量用户。
> > 征途现在已经用了集群，那么是什么原因把每个区设置在1-2万人在线这个规模呢？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
sunway
网易的泡泡采用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
但是既然能够多台机器集群来支撑一个区（或者网游都叫一个服），那么是的这个区/服 不能无限扩展的原因出在哪里呢？
网络带宽也可以让idc 加的啊。
lijie
理解各位老大说的意思。
但是既然能够多台机器集群来支撑一个区（或者网游都叫一个服），那么是的这个区/服 不能无限扩展的原因出在哪里呢？
网络带宽也可以让idc 加的啊。
如果服务器实现了动态分块 (区)，自然没有什么问题了，100万人在同一个大地图，就动态把地图切成更小的块分到更多物理服务器上，其它人少的服务器动态合并到某一个物理服务器上，这个实现起来非常困难，前段时间看过的"大型多人在线游戏"一书有提及，不过我相信很难实现一个稳定的版本。100万人太夸张了，服务器动态分区、动态转移数据通讯量都是非常大的，想在用户毫无察觉的情况下做应该是不可能。
征途这样的游戏，各个点位上只能站一个人，上面这种想法还是有可能实现的，魔兽这种许多人都可以重叠在一点上，怕是有些困难，一个点上叠几十人个，一块地图就没办法分得更小了。
sunway
交互产生的数据量是比较大，对实时性要求比较高。
我们可以做如下考虑：
如果用户发生交互的逻辑由于用户交互的对象在其他逻辑服务器上，因此需要多个服务器协同处理
，那么数据一致性和实时性很难保证，用户的体验也不好。
因此正常情况下MMO用户的逻辑数据不能在多个逻辑处理服务器间传递和处理。
IM一般情况下用户只和自己的几个好友进行消息传输，交互实时性要求不高，用户的消息
可以在多个服务器之间传递。
因此IM类的用户数据可以在多个逻辑服务器之间传递，并不会降低用户体验。
lijie
想想而已，实现难度可想而知。
diclogic
兄弟你说的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
我用50个进程来模拟50台机器，这样就不需要动态分区了，压力小时这假设这50个进程可以负责一个地图，压力大时其中一些进程把工作转到其它服务器上，降低了本机压力，进程数没变。
把动态分区问题转变成动态转移问题，后者难度显然小得多，如果服务器架构之初就这么做了，自然不用区分是本机进程还是其它机器。需要实现一个调度服务器，它的稳定性和正确性应该得到保证，它只负责根据压力转移地图区块到不同服务器，不负责用户转移工作，否则它的压力将非常大。当然压力本来不是用户造成的，各服务器需要定时把压力情况通知给该调度服务器。
突然想到，这不是erlang的思想嘛，稍有不同，但都是进程。呵呵。
sunway
比如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
这个问题没回答到。是把单个地图切分成50块，给50个进程，用户在同一地图上跑的时候就可能在各个进程之间转移。
压力大的时候，其中一些进程把数据转移到其它服务器，自己不再耗CPU，相当于把CPU压力分担出去了。
简单一句话，就是用静态分区(50个固定进程)取代动态分区。
如果不熟悉动态分区这个概念，可以看一下"大型多人在线游"，里面有简短的描述，跨区服务器那部分，讲的还行。
上面的静态分区，还是要涉及到2个在不同进程中的人相互战斗的问题，这本书也提到了，相邻进程(书中是服务器)要保存一些边界重复数据，这个重复区块大小也是有说头的。
总之难度还是相当高的。
sunway
目前已经失败。
个人综合考虑：
边界无缝地图目前实现只有技术上的价值，实际用处并不大，而且国内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
1. 单个服务器肯定不可能支撑无限用户，因此需要多个服务器集群
2. 当集群的时候如果是采用静态分割地图。 那么如果大量客户涌入同一个区域，这个服务器就挂了
3. 如果采用动态地图支持， 这个开发难度过大， 各个服务器之间互相动态接管开销也很大。采用动态平衡的话理论上可以解决问题2； 但是如果像魔兽这样的多个人站在一个点上，如果1万人站到同一个点， 那么这台服务器也挂了。（好在可能性很小啊）
4. 无论采用动态还是静态分割， 地图边缘上会有问题。 如果两个人正好分在两台机器上，那么互相之间传送消息就很麻烦了，而且会影响游戏速度。 而且一个人从一个服务器跑到另一个服务器就会出现延迟。
所以说无法很好的扩展无限用户，瓶颈出现在世界的交互上。 确实很难办。
顺便问一下， 比如征途，当我从凤凰城去野兽谷，到了地图边缘，系统就停顿一下，然后我就和凤凰城无关了，也看不到凤凰城边缘的人物了。 这是因为切了服务器吧？（魔兽就好一点，地图是连续的）
另外我一直以为 IM 是点对点交互的，服务器只是帮大家中介一下，然后im 之间自己通讯，和服务器无关。不知道这个理解对吗？
Yun Fan
Ghost Cheng
大概的意思是：
当用户接近当前所在地图的边界时，client开启第二个socket连接，连到边界另一边的场景服务器上。这样客户端从2个场景接收地图角色的数据，用于显示。
当用户跨边界的时候，由于新场景的连接已经建立，所以不会出现卡机等待的显现，
当在新场景里，离边界超过一定距离后，断开旧场景的连接。
每个场景的地图大小，可以设计的小一些，以防止大量玩家挤在一个场景上，但是这里说的小，是隐藏在服务器上的小，玩家可以感觉不到，应该让玩家觉得，四周的多个场景，是一个完整的世界。
当然这种方式的缺点是，相邻的2个场景服务器之间必须存在一个通讯通道，用于处理player数据的迁移。这里可能会遇到很多比较难办的问题。
不过话说回来，无限人数的MMO，没什么实际意义，大多数玩家，喜欢去新区建号玩，开的时间很久的区，一般继续创建新号的玩家不多，因为在老区里，新人想赶超老玩家，很困难。这种设计，我觉得不适合，等级、PK观念严重的游戏。
On 5/31/07, sunway <sunh...@gmail.com> wrote:
--
Sincerely,
Ghost Cheng
Email : ghost...@gmail.com
qiaojie
lijie
对于无缝地图，我曾经有过一个腹稿，一直没有时间去实现，也不是很成熟。
Ghost Cheng
技术性种族歧视。。。。恶寒。。。。
qiaojie
是做过网关的人
Ghost Cheng
上面说的只是一种思路，具体实现的时候，可以根据具体的构架去调整。以前有的游戏是没有网关的，比如奇迹。
Qinglan
liam
如果全是平原我觉得在服务器间这样做数据交换不现实..
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
diclogic
起来没什么问题，像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
diclogic
qiaojie
关于无缝世界至今我看到过两种实现。第一种是分割区域，每个服务器运行几个区域，游戏逻辑直接在区域服务器里计算，区域之间通过某些同步算法来同步状态，这个实现理论上可行，但是我没有具体实践过。第二种是用一组玩家服务器单独计算每个用户的游戏逻辑，用户之间的交互通过各个服务器之间的RPC调用实现，而广播则通过单独一台区域服务器实现。三年前我们做的网游（就是那个用ICE开发的Wish，后来项目取消了）就是按照这个架构来的，实践下来基本可行。不过这个方案的问题也比较多，主要是RPC通讯的开销很大，不优化的话性能很糟糕。