web策略类游戏开发(四)一个可以承载万人在线的架构

web策略类游戏开发(四)一个可以承载万人在线的架构

Webgame现在已经开始需要进入大统一服务器时代，每个游戏区域容纳的玩家数量将从现在的几万人发展到几十万人，因此在新的背景下，webgame如何处理大量用户的请求将成为问题。目前一台asp.net做的weggame服务器每秒能处理500~1000个页面请求，按照每个玩家每隔3~5秒做一次页面操作（页面请求），一台服务器能承受2k~4k的玩家在线，对于一个只有几万人的策略游戏来说，已经是足够了。但对于一个未来将承载几十万人的游戏来说远远不够。

通过分析，玩家在游戏过程中，有80%以上的访问仅仅只是查看玩家在游戏里的状态，实际上真正会对游戏运行状态及数据修改的的页面请求不足20%。因此，我们可以将呈现页面和处理游戏逻辑的功能拆分为2组服务器：页面服务器和逻辑服务器。两者之间可以通过remoting的方式进行数据通讯。将服务器分离后，随着页面服务器的增加，页面访问能力能应该能提升4~6倍。在往上逻辑服务器就会出现访问瓶颈。解决方法可以让页面服务器在读取玩家数据时直接访问数据库或者增加一个对象缓存服务器。页面服务器只有在必要的时候（需要进行逻辑运算时）才访问逻辑服务器，而逻辑服务器在玩家数据发生改变后更新对象缓存服务器和数据库。这样就可以大大降低逻辑服务器的访问次数，使页面访问能力进一步提升，轻松突破万人在线。如果访问量还需要继续扩大，可以用httpd做前台负责相应图片以及css等静态文件。

我觉得没必要这么做，如果并发很大的情况下，同时在线3000-4000.可以把数据库服务器分离，应用程序服务器架集群做负载平衡就可以了。没必要把页面和逻辑都分离。n024.gif

楼主的前四篇都看了，支持继续写下去.

[quote]原帖由 [i]tblack19[/i] 于 2008-5-4 04:27 PM 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3725313&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]
我觉得没必要这么做，如果并发很大的情况下，同时在线3000-4000.可以把数据库服务器分离，应用程序服务器架集群做负载平衡就可以了。没必要把页面和逻辑都分离。n024.gif [/quote]
这也很难断定的，我认为实际要视乎产品的设计及其需要，再根据实际情况及作出测试才知道。不同的产品的解决方案应该不同的。

[quote]原帖由 [i]tblack19[/i] 于 2008-5-4 16:27 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3725313&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]
我觉得没必要这么做，如果并发很大的情况下，同时在线3000-4000.可以把数据库服务器分离，应用程序服务器架集群做负载平衡就可以了。没必要把页面和逻辑都分离。n024.gif [/quote]

webgame 的设计和一般的网站有很多区别，最大的区别是游戏会存在一个服务程序（进程）处理一些页面响应无法处理到的逻辑。在单服务器架构里这个很容易解决，但一旦上升到多服务器架构时，这个服务程序就不那么好处理了。最显著的问题就是数据同步的问题。

LZ这么做的代价太高了，到后来会累死你自己。

[quote]原帖由 [i]jackyz[/i] 于 2008-5-4 19:26 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3726840&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]
LZ这么做的代价太高了，到后来会累死你自己。 [/quote]


真的做成这个模式就不是一个人在做了，而是一个团队在做，累死自己的问题不太可能发生...

有了团队，资源的浪费就不是浪费了？

问题其实好解决，楼主再动动脑子，发展发展，就会得到一个更简洁高效的架构了。

大型的数据库都支持数据同步，当主服务器甚至子服务器的数据发生变化时，可以及时向其他相关服务器更新数据。负载均衡既然作为一种解决方案，你想到的问题都有方法解决，唯一的问题是成本而不是技术。

你一样可以把你的逻辑服务器概念扩展成逻辑服务器群组啊，没冲突的

[quote]原帖由 [i]Rail100[/i] 于 2008-5-4 19:45 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3726954&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]
大型的数据库都支持数据同步，当主服务器甚至子服务器的数据发生变化时，可以及时向其他相关服务器更新数据。负载均衡既然作为一种解决方案，你想到的问题都有方法解决，唯一的问题是成本而不是技术。

你一样 ... [/quote]

前面的页面服务器是通过负载平衡的方式来处理玩家的页面请求，后面的逻辑服务器主要功能是在处理逻辑运算时能够确保数据不回发生不一致的情况。数据库的作用只在于数据存储，已经一些非逻辑运算的数据访问（玩家之间的消息）。通过数据库的事务来确保数据的正确性我感觉有点浪费，而且还有可能会将大量的访问压力转嫁到数据库造成瓶颈。

[quote]原帖由 [i]dogvane[/i] 于 2008-5-4 19:24 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3726832&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]


webgame 的设计和一般的网站有很多区别，最大的区别是游戏会存在一个服务程序（进程）处理一些页面响应无法处理到的逻辑。在单服务器架构里这个很容易解决，但一旦上升到多服务器架构时，这个服务程序就不那 ... [/quote]

啊，我也想请问一下，这里说的数据同步，具体是指什么？请赐教。。。

一个比较简单的例子：
A，B两个服务器分别从数据库里获得同一个数据C = 10，这时A先计算C+10然后写入数据，当A将数据写入数据库后，如果B里的数据C不更新，那么B在计算的时候就会发生数据不一致的错误，但这时B仍然认为自己是正确的。

楼主的架构模式，很象服务器集群。
只不过只用到了页面服务器上。
逻辑服务器和数据库也可以集群起来啊。

一台备份用的数据库服务器（databak）；一台基础数据库服务器（database）；增加多台数据库交互数据库服务器（db1、db2、db3）。

一台判断数据流向逻辑流向（需要数据库操作及逻辑操作时）、连接流向（仅仅是访问页面时）的服务器（check）；多台页面服务器（web1、web2、web3）；多台逻辑服务器(action1、action2、action3)。

下一楼是图。数据库同步应该有更好的方法，不过我不太懂。所以方法比较搞笑。用同时写入2个数据库的方式来模拟同步。再用定时删除多余数据表，定时优化数据库的方式来保持数据库服务器的稳定和正常。
定时处理上通过在action服务器上的服务器程序实现。C，java等等都行。

数据库架构的时候，几乎每个表都需要多个字段表示该表或该数据所在的主服务器是哪一个。

逻辑处理的时候也得完成额外的数据表同步的工作。

这方法太麻烦。反正没试过。

[[i] 本帖最后由 北里闻箫 于 2008-5-8 00:45 编辑 [/i]]

上面说明的图

新增加了个action服务器。定时处理多余的数据用的。

程序员的毛病就是这个

系列收藏n002.gif

LZ写得很好 但是知识战争策略的游戏可以这样弄！

呵呵，问一个问题：为什么大家谈起架构，总是从“DB-Action-Web”这个模型来切入呢，有新想法没？

策略类也不需要这样弄，一台高配置（双4核CPU64位，4G内存，73G SAS硬盘）单独负载一个网页游戏的数据库和web服务完全可以，而且可以支持策略类游戏3万人注册同时在线至少3000人以上。

如果觉得服务器负载过大，最多把DBserv分离出来，做成2台一组的结构。

技术层面讲支持几十万人在线，从游戏内容层面讲根本没有必要，一个战略游戏，比如ogame一个服务器支持注册12000人，一个玩家“一辈子”发生交互的玩家不超过1000人，要是没有排行榜，可能有的玩家游戏一年都没见过某人。那么ogame就是一个人与人交互的游戏，12000就已经满足要求了，有必要搞10万20万人在一个服务器吗？

另外，LZ还要考虑到游戏生命周期的问题，当一个游戏一年左右生命周期结束的时候，服务器在线也不过200人左右，成本的控制在运营中非常重要。如果Travian一组10台，9个月生命周期到了，一个服务器里就200人在线，运营商不是损失太大了吗？

[quote]原帖由 [i]kusomania[/i] 于 2008-5-11 05:40 发表 [url=http://www.cwebgame.com/redirect.php?goto=findpost&pid=3770425&ptid=190403][img]http://www.cwebgame.com/images/common/back.gif[/img][/url]
策略类也不需要这样弄，一台高配置（双4核CPU64位，4G内存，73G SAS硬盘）单独负载一个网页游戏的数据库和web服务完全可以，而且可以支持策略类游戏3万人注册同时在线至少3000人以上。

如果觉得服务器负载过 ... [/quote]


对于是否采用高性能服务器替代多服务器，目前业界也没有一个统一的定论，不过采用多服务器架构设计的游戏在出现访问瓶颈时，会比采用高性能服务器发生瓶颈后容易解决问题，硬件投入的代价也会小很多，这个比较适合中小型的运营商。
webgame的压力不在于数据库，而在于生成客户端页面，所以需要存在多台的页面服务器。
目前从策划的角度上看，一般的策略类webgame是不需要10w，20w玩家在同一组服务器里，但其他类型的呢，想rpg,养成类的，人多在一起才有趣。
至于游戏的生命周期，那就更不成问题了，架构既然决定了能将游戏分散到多个服务器里运行，也能将多个服务器的程序配置到同一台服务器上，这样运营初期和末期，实际上只需要1台服务器即可。

bz008.GIF  了解～

n002.gif n002.gif n002.gif ,太有份量了!以后一定顶力支持!

php的论坛可以做到支持万人webgame也一样做到

n013.gif支持楼主的想法, 程序开发基于多服务器考虑,在适应多重情况下更有余地,

webgame 在相同资源下支持游戏人数远比传统网游要多, 这个是webgame的优势,不能忽视了.

多服务器架构的理论是可行的，简单的进行remoting方式的架构处理在国外很多的WEBGAME里就有了，如何解决对于页面的处理其实是很关键的因素，如果不考虑到以后的客户介质的转移问题应该是个很不错的方法。

另，中国其实最要解决的是网通和电信的数据瓶颈问题。

把页面和逻辑隔离开确实是一种负载均衡。 而且书写代码的时候，把展现和逻辑隔离开也是一种好习惯。

图中MENCACHE和逻辑服务器的交互画清楚点就更好了~~加油！！

基本上不管是什么游戏 只要程序员思维定势到试图支持1w以上玩家同服 老板就可以让他收拾东西回家了

弄全世界人一起玩一个游戏，就很有意思么？