棋牌源码网

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

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

  恩 ,实际运营的时候肯定是怎么考虑问题的 。我们平台满负载跑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。连接数方面:老方案较优 ,有效减少连接数,可以节省服务器的网络资源(不要认为无法控制玩家多连接,你说玩家可以看几个游戏什么的 ,这个不重要,他开几个游戏在我们游戏平台来看就是几个用户的,只是同一个玩家而已)

如何提高棋牌游戏服务器利用率 玩家数据 棋牌游戏 资源 棋牌技术  第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都是固定的。

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

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

如何提高棋牌游戏服务器利用率 玩家数据 棋牌游戏 资源 棋牌技术  第2张

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

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

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

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

  分布式服务器的三层架构

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

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

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

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

本文链接:https://www.jr160.com/game/1738.html

版权声明:

本站发布的内容若侵犯到您的权益,请邮件联系 web58678@gmail.com 删除,我们将及时处理!

从您进入本站开始,已表示您已同意接受本站【免责声明】中的一切条款!

本站大部分下载资源收集于网络,不保证其完整性以及安全性,请下载后自行研究。

本站资源仅供学习和交流使用,版权归原作者所有,请勿商业运营、违法使用和传播!请在下载后24小时之内自觉删除。

若作商业用途,请购买正版,由于未及时购买和付费发生的侵权行为,使用者自行承担,概与本站无关。