策略型网页游戏的服务端计算能力瓶颈

看完此贴有如下结论:

1、楼主的担心是有道理的。需要有方案解决。
2、有一楼给出了解决方案。把地图划分为格子的办法，也是我们采用过的。
3、前面大部分搞B/S开发的同志并不懂网游开发.
4、说瓶颈在数据库的，可能也不太懂网游开发，实时性要求这么高的，必须以内存来处理绝大多数非关键性数据。涉及MONEY的可能才需要立刻持久化到数据库中。

看了一遍，忍不住了，插句嘴～～

webgame 根本没有，也不需要什么大量实时数据要处理～～

例如类似部落战争的行军，这个其实早就根据所选兵种、指挥官、宝物等等生成了一个事件存放在事件队列中（可能是内存对象、可能是某种数据缓存更有可能是数据库的某条记录），然后服务器在那个事件事件到达的时候取出事件对象执行一下，得到一个结果，接着存起来。至于行军途中到哪个位置如何如何，那是给玩家想象的，服务器根本不管。总之，事件运算有三种方式：1。玩家请求时已经运算完成，到了特定时间通知玩家。2。事件执行时间运算完成，并通知玩家。3。在服务器空闲时，处理待处理的运算，到了特定时间通知玩家。

webgame， MMO 实时性不是首先考虑的。例如资源增长，如果服务器有 10W 激活用户，在同一时间增长资源是几乎不可能的。那就将一分钟划分60秒（废话），每秒开一个新线程来处理一部分用户（10W/60）的资源增长。资源增长基本上就是浮点数加减乘除，对于现在的 cpu 来说，并不是很高。何况服务器 N 个 cpu……

简单的说，webgame 不像 MMO 需要“随时”客户端跟服务器端通讯。更多情况，web 服务器通过某种方式从 game server 中获得一个当前游戏状态的快照返回到浏览器。并从浏览器接收数据，然后在一个可接受的，合理的时间内去修改 game server 的状态。请再次注意，again！这不是“实时”的！

最后再罗嗦一下，webgame 的 game server 更多情况下是一个 task server。它不需要去预测客户端行为，也不需要计算碰撞、寻找可行路径……
另外，我个人的体会，RPG 类型的 webgame 在运算负载上来说，远小于策略形的。并且通常只需要 3 台服务器配合：web server、task server、db server。

哦，还有，如果用 flash 的 socket 方式开发，不在上述范围内。当这种模式是个客户端能力稍差的 MMO 好了。

好吧，这贴我自己来结……
跟人聊天聊到的，发现世界上还有实时数据库这个东西……

BerkeleyDB 开源免费，好似只支持可笑的键值对……索引查询怎么办！
extremedb 这玩意支持各种索引，性能宣称是微妙级，应该是最王霸的了，GFW用的就是这个，当然持久化到介质上的支持怕是有些吃力。
这两个应该都不支持标准SQL
Oracle TimesTen 这东西的优点似乎是跟硬盘介质是无缝的？你可以用标准的SQL享受内存数据库的性能，同时完全不必管理持久化上介质的处理

以上应该都支持事务和锁。

Erlang 比较适合做这个

客户端计算了也没用。服务端还是要计算一遍的，否则容易被修改数据。。

高质量回复！ 想加分，可是加不了···

同感！  确实如此

这可能并非开发人员想偷懒，也许游戏就是这么策划的，一个复杂的战斗系统不一定适合WebGame。我只玩过武林三国这种部落战争类的游戏，不知道其他的策略型WebGame是否都采用这种战斗模式。从程序实现的角度来说，实现每个坐标点的交互，与之前的战斗模式相比其实是差不多的。比如A进攻B，在到达B之前，B可以选择呼叫援军，也可以FS，这都会改变B的某些状态，但都对A与B即将发生的战斗毫无关系。当A的军队最终到达B的那一刻，才触发真正的战斗计算。同理，加入了上面所说的“遭遇战”后，当A到达某个坐标，也触发一个事件，然后判断到达这个坐标点的各支军队，进行一次战斗计算，这与A到达B时的计算很类似。只要坐标划得足够粗，计算量就不会呈指数级增加了。比如最快的军队都需要2分钟才能到达下一个坐标点，这2分钟就足以完成计算了。技术上来说可能比更实时的传统MMORPG简单多了，我猜是基于游戏复杂度、WebGame所面向的用户群体、游戏定位等综合考量，策划上刻意做了很多简化。一个让你点不停的WebGame，用户体验始终不如传统c/s架构的游戏吧。

C与Java的性能不可能差出很多倍，语言上的性能差别倒其次了。
我的观点，解决性能问题就几种办法，对游戏也应该适用：消除单点瓶颈（良好的可扩展设计、适当的分区策略）、缓存、针对具体应用场景分析，找出瓶颈所在。

策划或者gameplay设计的问题就由策划来解决。我现在追求的只是一个自由度。
自由度上去了，怎样用轻松简洁的手法来呈现出来，让用户体验最好，这跟性能的追求是两码事。不可能因为追求性能所以耽误了用户体验，那是庸才策划的结果。
之所以想要设计城墙的效果，或者设计岗哨的效果，基本思想也是出于让用户体验尽量舒适，尽量减少实时交互的压力为出发点的。正是上了高性能才有可能让用户体验更舒适，OGAME玩家用闹钟半夜按小时起来一次搞FS，对玩家来讲是相当糟糕的。
具体实现的话，城墙勉强还能说好办（也好不到哪里去，没有索引可用，加一条墙就得把移动中部队全部遍历一遍加碰撞），岗哨就真的不能等遭遇时点了。

我们的游戏事件处理就是这么做的，资源增长如果按照老兄这么来做，有点太过复杂，我们是保留上次的余额的时间点，然后根据产量生成当前的余额，如果有变化重新生成余额和对应时间点。

我们的webserver和taskserver在一起，因此一组服务器也就2台服务器，2个服务器加起来不超过3万rmb，收入好的服务器1-2天就能拿回服务器成本。我们最高激活用户数量是一组12w用户，此时服务器也没什么卡的情况。

重复之前的，我们的gameserver负载非常低，负载高的在db服务器上，我们此间采用了多重cache，cache命中率在70%左右。

用户质量，我们的几十家合作伙伴中，涵盖了国内绝大多数大型网站，用户质量良莠不齐，这也对webgame的收入有很大影响。

海外用户质量非常好，用户的arup值比国内的高好几倍，就是能开多少组服务器的问题。

一款webgame的成功关键点不在于技术，可以说技术对于在座各位应该问题不大，难点在于产品策划、推广和运营能力。

webgame市场看着好像风风火火，实际上竞争激烈，去年有300多款网页游戏，成功不过10款，今年可能更惨烈。

有志于这方面的人才，可以跟我联系，我这里大力欢迎！