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

　　假设有1w同时在线均匀分布在50个房间内，75%的人在打牌，20%的人在找座位，5%的人登陆/登出，则： 出牌逻辑计算 750次/秒 通讯量 750 * (1+4)次/秒 （按人均10s出一张牌估算） 房间内用户找座位/状态改变/聊天 200次/秒 通讯量 200 * 400次/秒 (按人均10s改变一次状态) 用户登陆/登出 50次/秒 通讯量 50 * 400次/秒 （假设每秒内有50人次的登陆/登出） 本文由网上真钱棋牌游戏www.qpyouxi.net编辑整理,介绍各种网上真钱棋牌游戏游戏技巧,澳门赌场博彩游戏技巧,提供各种网上博彩游戏,网上真钱游戏,免费试玩。

希望如何提高棋牌游戏服务器利用率这篇文章能给你提供帮助。

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

　　现在大家谈论的，基本上基于，设定一个服务器的最大运算能力，然后可以简单的通过添加计算机增加运算能力。

这个很简单实用，但我们确实可以换一种思考方式，假设我们有一台巨大的计算机，不需要考虑内存、速度，我们该怎样做。

　　恩，实际运营的时候肯定是怎么考虑问题的。

我们平台满负载跑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-