如何提高棋牌游戏服务器利用率

自助开通VIP,整站资源任意下载

 看了这么多,好像没有人谈到基础架构,就是分布式,现在小公司可能只有一个机房,但大公司肯定不会只有一个,这样可以分区计算,相应的网络延时也会少几个数量级?。

  现在大家谈论的,基本上基于,设定一个服务器的最大运算能力,然后可以简单的通过添加计算机增加运算能力。这个很简单实用,但我们确实可以换一种思考方式,假设我们有一台巨大的计算机,不需要考虑内存、速度,我们该怎样做。

  恩,实际运营的时候肯定是怎么考虑问题的。我们平台满负载跑1.5W,基本也都是按照1W人上限跑。刚才说的通过Centre Server动态调整房间数量,我们也在运营中用过,不过后来还是关掉这个功能。实际意义不大。

  现有的棋牌游戏架构已经可以很好的工作,联众、QQ等平台处理上百万同时在线也不存在任何问题。负载不均衡有什么关系,多架几台服务器就是了,以每台最保守运行?1w人计算,100w同时在线的也就100来台服务器,这点硬件成本几乎可以忽略不计。而你们讨论的动态负载均衡分布式带来的overhead完全可能超过带来?的好处,最终反而得不偿失。

  你说的没错,这个也是我所认为的,房间数据的传输量是很大的,请问你有好的解决方法吗,如何解决房间人数的失衡问题。我们的设计也并不是凭空想象的。对于房间的数据,我还考虑使用P2P的辅助方式来实现,但是跟服务器的连接依然保持。

  假设有1w同时在线均匀分布在50个房间内,75%的人在打牌,20%的人在找座位,5%的人登陆/登出,则: 出牌逻辑计算 750次/秒  通讯量 750 (1+4)次/秒  (按人均10s出一张牌估算) 房间内用户找座位/状态改变/聊天  200次/秒  通讯量 200 400次/秒  (按人均10s改变一次状态) 用户登陆/登出 50次/秒  通讯量 50 400次/秒  (假设每秒内有50人次的登陆/登出)

如何提高棋牌游戏服务器利用率

  粗略的估算可得知,房间内用户找座位的广播操作是最频繁的,比一桌内打牌用户的操作次数要高1个数量级,而出牌逻辑的计算负载基本可以忽略不计,瓶颈主要在网络通讯上。

  CS有大量长连接,也需要传输大量数据(座位真的需要比较实时,这个请从你玩游戏过程中的体验出发,你说大家都不实时,就会没所谓,但是请你想一下,你看到一个座位一直是空的,但是就是一直也坐不下去,请问你感觉如何),所以现在的情况是CS的任务不会很轻,需要均衡,这里没有给出好的方案。

  还有需要提出的一点,你上面说只有CS与数据服务器有连接,WS不需要,这个对数据库而言,只是连接数多少的问题,工作量并没有降低,你在那边浪费了2 倍玩家的连接数,在这里赚了WS服务器的连接数,意义不是很大。

  比较两个方案,其实可以很容易区分他们的不同,列出他们的优点和缺点就可以了。

  1。连接数方面:老方案较优,有效减少连接数,可以节省服务器的网络资源(不要认为无法控制玩家多连接,你说玩家可以看几个游戏什么的,这个不重要,他开几个游戏在我们游戏平台来看就是几个用户的,只是同一个玩家而已)

  2。逻辑清晰方面,新方案较优,把游戏逻辑与房间信息分开。但是我也在想即使他们是在同一台机器上的,逻辑也是分开的,只是他们交互的渠道不同(不同的机器肯定是用socket,同一台机器可以是socket,也可以是共享内存之类,我想这个可以配置就最好了)

  3。负载均衡方面,新方案解决了桌子服务器的均衡问题,但是CS服务器本身的均衡问题没有解决,老方案对均衡问题没有提出解决方法。我今天想了一下,在老方案中,是否可以这样解决,当他负载重时,象负载轻的服务器发起请求,让负载轻的服务器建立象你那样的WS功能,然后负担重的服务器只需要转发信息就

  可以了,不处理游戏逻辑,或者直接让玩家新建连接,跟你现在的模型一样,但是这个模型只限于当负载失衡受影响的玩家

  暂时我还是这样想,可能你不这样认为。但是你的想法也是很好的,如果可以比较好的解决CS负载均衡的问题,我想还是很不错的,现在我想焦点在这里。

  Cache服务器的意义。我的架构中,ws是不会与数据库产生交互的,ws服务器的用户数据是通过他所属的cs来同步的,所以我说cs是一个Memory Cache服务器,这就意味着一个cs与N个ws构成的集群,只有cs需要与数据库交互,而且cs也是缓存了提供下面所有ws服务器同步的。

  对于服务器而言,衡量的标准是多少个连接而不是多少个客户。你无法规避客户会建立多少个连接的问题,玩魔兽还有人开两个客户端呢,更别说棋牌游戏了,一般同时打两桌是很常见的,你需要去考虑一个客户端建立了多少个连接吗?你只要考虑你的服务器能承受多少连接就可以了。而且,我也说了,这两个连接是分别位于cs和ws上的,而cs和ws并非一台服务器。

  如果采用了回收机制,那自然不会在登陆时采用固定地图的方法了,这不冲突,我说的是我这种动态分布的架构,不要跟QQ的机制混淆了。QQ并没有实现房间拥挤的负荷均衡,而浩方是这样的。

  抢座位这回事,大家都是UDP,就像走路跟开车一样,如果没有汽车,大家一起走路,机会是均等的,你觉得这个上面的实时性在哪里呢?最后说数据库,我说的很明白,第二层的节点越多,就意味着需要直接与数据库沟通的服务器越多,比较我的方案,随着房间的大量拓展,你的数据库瓶颈比我的架构更快地达到。

  呵呵,好似问题牵涉越来越多。我只有一点一点来描述了

  我只是提供一个思路,回收机制你可以不采用,直到最后一个玩家离开房间再把房间给回收也可以,动态生成房间来负载均衡,这种机制在浩方平台上就是这样的。

  首先,如果一个房间只有两三个用户,就是不走,你的房间没办法回收(常发生,有人挂机),其次,动态生产房间满足不了我们的要求,请注意我之前描述的,用户在登陆之后就会得到一幅服务地图,要求房间数目,对应的IP都是固定的。

  至于客户端要有几个连接,这种问题根本不用考虑的。 我们的连接都是长连接,用户每多一个连接,我们的服务器就多几万乃至几十万个连接,也不可以说不考虑的,服务器是相当繁忙的。

  实际上房间服务器的实时性没有你想象的那么高

如何提高棋牌游戏服务器利用率

  棋牌游戏的房间实时性要求是还是比较高的,想想你在QQ GAME中玩拖拉机,看到一个空位置,就想加进去,大家都在抢座位,如果实时性不高,很容易就是看到有空位其实有人,看到有人的地方其实是空的,相当恼火,因为发了很多时间都不能加入游戏,QQ 在这里也不好,他实时性是比较高的,但是由于玩家相当多,很难抢到位,时间常常浪费在找位置上面。

  如果你把房间服务器和游戏服务器架构在一起,一台服务器也就能开10个房间,这样的架构首先不利于扩展,棋牌类游戏种类很多,你是不是每种类型的都需 要 附带一个大同小异的房间服务器功能?

  我确实是这么想的,一个游戏的房间,就有一个该类游戏的服务对象,负责该类服务的事务,扩展的话,你要增加房间,很容易,增加一个这样的对象,让他运行就可以了(该对象可以运行在同一机器或者新增的机器上).至于你说"附带一个大同小异的房间服务器功能",这个没问题,实现的时候只不过是通过继承来 做,多的只是一个对象。

  用户数据上的同步问题没错,我们的数据库也会是独立的一个黑盒子,里面也会有均衡以及扩展的问题,但是我不是好明白你的意思。无论你把查询的工作放在CS也好,放在WS也 好,对于数据服务器,其工作量是不变的,变化的只是CS,WS本身的负荷,可能你的意思是说把CS,WS都放在同一个模块里实现,该模块又需要数据查 询,其效率会低。但是请你明白,任务就是那么多了,放在一起单台机器可能是没有分开的两台机器效率高,但是请注意我是一台,你是两台,原理是一样的,我 一台带的人数可以少点,反正工作量就是这么多,也没有因为这样而浪费效率,好似问题不大。

  分布式服务器的三层架构

  三层构架其实是一个概念的东西,连接,逻辑,数据库。其实这个跟这里好似问题不大,即使按照你说的方法,你也是连接跟逻辑都在同一台机器上,不同的是你把一个逻辑拆分为两个逻辑,我想没必要受这个三层的影响。

  我只是提供一个思路,回收机制你可以不采用,直到最后一个玩家离开房间再把房间给回收也可以,动态生成房间来负载均衡,这种机制在浩方平台上就是这样的。

  至于客户端要有几个连接,这种问题根本不用考虑的。玩过QQ游戏的都知道,玩家同时进三四个房间那是常有的事情,更何况业务服务器和房间服务器是分开的,跟两者各保持一个连接不是更正常吗。

  实际上房间服务器的实时性没有你想象的那么高,他只是在玩家数据的同步上需要更高的实时性,尽量减少对用户数据库的查询,避免引起数据库的瓶颈。而在网络上没有那么高的实时性,所以我更愿意叫它Memory

本站源码仅做学术研究,自娱自乐使用,不得用于赌博性质的非法商业用途!转载请说明出处!
棋牌资源网 » 如何提高棋牌游戏服务器利用率

这里有你所需要的,找专业的人做专业的事!

游戏演示 联系客服