CN104135506B - 网络数据负载均衡设计系统及方法 - Google Patents

Abstract

一种网络数据负载均衡设计系统及方法，该方法包括：设置负载均衡服务器；负载均衡服务器分配网关服务器的连接数据给客户端；设置场景服务器，通过网关服务器建立客户端与场景服务器的连接；设置HTTP服务器，控制客户端的角色登录和支付相关功能；设置全局数据服务器；设置主中心服务器，管理子中心服务器和离线数据服务器；设置大厅服务器，控制游戏平台中房间的创建和销毁操作，给房间分配竞技服务器；设置缓存服务器，用于通过数据库获取相应数据或进行数据存储。利用本发明可降低各服务器的负荷。

Description

网络数据负载均衡设计系统及方法

技术领域

本发明涉及一种数据处理系统及方法，尤其涉及一种网络数据负载均衡设计系统及方法。

背景技术

随着互联网的迅速发展，中国网民的数量迅速增加，当大量客户端同时与服务器端连接时，可能导致网络堵塞。特别地，目前在线玩网络游戏的用户越来越多，由于网络游戏需要在客户端和服务器端传输大量的数据，当大量网络游戏的客户端同时在线时，将对服务器端造成巨大压力，严重时可能导致服务器崩溃。

发明内容

鉴于以上内容，有必要提供一种网络数据负载均衡设计系统及方法，其可通过对客户端与服务器端、以及服务器端各服务器之间的架构进行优化设计，降低各服务器的负荷，实现客户端与服务器端、以及各服务器之间数据传输的负载均衡。

一种网络数据负载均衡设计系统，该系统包括：负载均衡服务器，与登录服务器连接，用于当客户端连接至登录服务器后，建立客户端与负载均衡服务器的连接；所述负载均衡服务器，还用于分配网关服务器的连接数据给客户端，断开客户端与负载均衡服务器的连接；场景服务器，用于通过网关服务器建立与客户端的连接，并控制客户端操作；超文本传输协议HTTP服务器，与场景服务器连接，用于控制客户端的角色登录和支付相关功能；全局数据服务器，与场景服务器连接，用于存储当前服务器组共享的数据和该数据的逻辑；主中心服务器，用于管理子中心服务器和离线数据服务器，当客户端完成角色登录时建立客户端与离线数据服务器的连接，该离线数据服务器控制客户端离线数据的发送和接收；大厅服务器，与场景服务器连接，用于控制游戏平台中房间的创建和销毁操作，给房间分配竞技服务器，并控制竞技服务器处理客户端的游戏任务；缓存服务器，与场景服务器连接，用于当一个指定服务器需要获取数据或存储数据时，通过与该缓存服务器连接的数据库获取相应数据或进行数据存储。

一种网络数据负载均衡设计方法，该方法包括如下步骤：设置负载均衡服务器，当客户端连接至登录服务器后，建立客户端与负载均衡服务器的连接；负载均衡服务器分配网关服务器的连接数据给客户端，断开客户端与负载均衡服务器的连接；设置场景服务器，通过网关服务器建立客户端与场景服务器的连接，由场景服务器控制客户端操作；设置与场景服务器连接的超文本传输协议HTTP服务器，控制客户端的角色登录和支付相关功能；设置与场景服务器连接的全局数据服务器，存储当前服务器组共享的数据和该数据的逻辑；设置主中心服务器，管理子中心服务器和离线数据服务器，当客户端完成角色登录时建立客户端与离线数据服务器的连接，该离线数据服务器控制客户端离线数据的发送和接收；设置与场景服务器连接的大厅服务器，控制游戏平台中房间的创建和销毁操作，给房间分配竞技服务器，并控制竞技服务器处理客户端的游戏任务；设置与场景服务器连接的缓存服务器，当一个指定服务器需要获取数据或存储数据时，通过与该缓存服务器连接的数据库获取相应数据或进行数据存储。

一种基于上述网络数据负载均衡设计方法的卡棋装置，该卡棋装置的棋盘区域包括：王位，位于棋盘中央区域四条边界的中心位置；出兵点，位于离王位最近的3个方格间，代表客户端的出兵点；天元，位于棋盘区域的中央位置，用于阻挡一切移动和攻击线路；套牌位，位于王位的右下方，客户端套牌放置的位置，所述套牌包括人物牌、法术牌和装备牌中的一种或多种；标记位，位于王位的右下方，标记卡放置的位置；体力卡，位于王位的正下方，用于记录王者的剩余体力；墓地，位于王位的左下方，用于放置死亡的人物、使用过的法术和装备。

相较于现有技术，所述的网络数据负载均衡设计系统及方法，通过对客户端与服务器端、以及服务器端各服务器之间的架构进行优化设计，降低各服务器的负荷，实现客户端与服务器端、以及各服务器之间数据传输的负载均衡。

进一步地，根据上述网络数据负载均衡设计系统，本发明提供一种新的网络游戏：卡棋游戏，该卡棋游戏同时具备传统卡牌游戏和棋类游戏的优点。

附图说明

图1是本发明网络数据负载均衡设计系统的主体架构图。

图2是图1中某个大区的服务器组架构图。

图3是图2中的场景服务器寻找匹配客户端的算法示意图。

图4是图2中的客户端的架构图。

图5是图4中的客户端的资源管理模块进行资源管理的示意图。

图6是本发明网络数据负载均衡设计方法的主流程图。

图7是基于网络数据负载均衡设计系统的卡棋游戏的棋盘区域示意图。

图8是本发明设计的卡棋游戏的人物牌示意图。

图9是本发明设计的卡棋游戏的法术牌示意图。

图10是本发明设计的卡棋游戏的装备牌示意图。

图11是本发明设计的卡棋游戏的标记卡示意图。

图12是基于网络数据负载均衡设计系统的卡棋游戏用户界面示意图。

具体实施方式

如图1所示，是本发明网络数据负载均衡设计系统的主体架构图。在本实施例中，网络数据负载均衡设计系统2包括一个或多个客户端20(图1中仅示出一个)、登录服务器(Login Server)30、HTTP(Hypertext Transfer Protocol，超文本传输协议)服务器31、第一缓存服务器(Database Cache Server)32、以及负责各个大区的负载均衡服务器，例如A区负载均衡服务器33、B区负载均衡服务器34、N区负载均衡服务器35。所述大区可以是一个省或多个省，也可以是一个直辖市或计划单列市等。

所述第一缓存服务器32通过数据库连接与第一数据库320相连，该第一数据库320中存储有所有大区的帐号信息，如客户端20的帐号和密码等。在本实施例中，所述数据库连接可以为Java数据库连接(Java Database Connection，JDBC)或开放式数据库连接(OpenDatabase Connectivity，ODBC)，所述第一数据库320可以是Mysql或SQL Server。

所述客户端20通过网络与登录服务器30连接，用于输入帐号进行登录和选取一个大区，该登录服务器30用于根据第一数据库320中存储的帐号信息验证客户端20的帐号，当客户端20的帐号验证通过后(帐号和密码都正确)，返回客户端20所选取大区对应的负载均衡服务器的地址(如IP地址)和端口信息至客户端20。然后，客户端20断开与登录服务器30的连接，并根据所选取大区对应的负载均衡服务器的地址和端口信息连接至所选取大区对应的负载均衡服务器。举例而言，假设客户端20选取的大区为A区，则当客户端20的帐号通过验证后，将断开与登录服务器30的连接，并与A区负载均衡服务器33建立连接。在本实施例中，所有大区共用一个登录服务器30。

进一步地，当客户端20登录游戏平台时，HTTP服务器31建立客户端20与该游戏平台的连接，完成客户端20的平台登录和平台支付等相关功能。

以下以图2为例，详细介绍图1中某个大区的服务器组架构图。该大区的服务器组包括，但不限于，负载均衡服务器36、网关服务器37、场景服务器40、HTTP服务器31、全局数据服务器(Global Data Server)38、主中心服务器(Main Center)41、一个或多个子中心服务器(图2仅示出一个)43、离线数据服务器44、大厅服务器51、PVP服务器(Player VersusPlayer Server，或称之为“竞技服务器”)52、日志服务器(Log Server)46、及第二缓存服务器45。所述第二缓存服务器45通过数据库连接与第二数据库450相连，该第二数据库450中存储有客户端20的角色数据和日志数据等。

其中，所述负载均衡服务器36用于连接到图1所示的登录服务器30，实时汇报相关数据(如登录数据)给登录服务器30。当客户端20从登录服务器30断开后，会先连接到负载均衡服务器36，负载均衡服务器36给客户端20分配相关场景网关(即网关服务器37)的连接数据，如网关服务器37的IP地址。客户端20在获取到场景网关的连接数据后，断开与负载均衡服务器36的连接，并通过网关服务器37连接至场景服务器40。

所述网关服务器37用于保护服务器组内的各服务器，避免使其直接曝露在公网上被攻击。进一步地，网关服务器37分摊游戏场景与客户端20网络通信的压力，如网络通信数据的加密与解密等。

所述场景服务器40用作最主要的游戏逻辑服务器，角色的上下线，PVE(PlayerVersus Environment，玩家vs环境)任务等，除了PVP逻辑，其它所有游戏逻辑都由场景服务器40控制。

所述HTTP服务器31与场景服务器40连接，用作与游戏平台对接的服务器，用于控制客户端20的角色登录(即游戏平台登录)和支付等相关功能。

所述全局数据服务器38与场景服务器40连接，用于存储该大区的服务器组共享的数据和处理这些数据的逻辑。例如，限时限量抢购商城道具，所有的玩家看到的数据必须是一致的(所有玩家共享),这部分逻辑由场景服务器40处理是不合适的,因为每个场景的数据都是独立和平等的，一个场景当机后,玩家再次登录后会分配到其它场景。另外，与排名有关的游戏逻辑和数据，比如页游中常用的竞技场挑战排名,此部分数据也必须是共享的。

所述主中心服务器41用于管理子中心服务器43和离线数据服务器44等，当客户端20完成角色登录时建立客户端20与离线数据服务器44的连接。

所述子中心服务器43用于充当场景服务器40、HTTP服务器31、全局数据服务器38、离线数据服务器44等的消息路由器，所有需要消息路由的服务器都需要连接到主中心服务器41和每个子中心服务器43，主中心服务器41分配一个指定的子中心服务器43作为主路由服务器。当每个逻辑服务器(如场景服务器40和离线数据服务器44)接收到从其它服务器转发过来的消时息，将通过该指定的子中心服务器43进行消息转发和路由。

所述离线数据服务器44用于控制客户端20进行离线交互(离线数据和逻辑)，如发送离线邮件，访问离线好友的数据等。

所述大厅服务器51与场景服务器40连接，用于控制游戏平台中房间的创建、销毁等操作，给房间分配PVP服务器52，并控制PVP服务器52处理客户端20的游戏任务。

所述PVP服务器52用于处理PVP战斗相关逻辑，客户端20通过网关服务器37连接至PVP服务器52加入PVP战斗，PVP服务器52不保存角色数据，战斗完成后，通过大厅服务器51将相关战斗结果数据(如胜负结果等)发回场景服务器40进行数据合并和保存。

所述日志服务器46与场景服务器40、第二缓存服务器45、及大厅服务器51连接，用于合并和汇总所有需要存储数据的日志，并通过第二缓存服务器45将相关日志写人第二数据库450。

所述第二缓存服务器45与场景服务器40连接，用于当一个指定服务器需要获取数据时(如角色登录时)，第二缓存服务器45首先查看内存中是否有需要获取的数据，如果内存中没有需要获取的数据，则从第二数据库450中读取需要获取的数据，并将读取的数据返回至该指定服务器。如果内存中有需要获取的数据，直接返回内存中的相关数据至该指定服务器。进一步地，当该指定服务器需要保存数据时，第二缓存服务器45先更新该指定服务器缓存中的数据，将需要存储的数据更新至缓存，将缓存中的数据设置为更新标记(如1)，并在第一次更新后的指定时间(如30秒)后将缓存中的数据(更新部分的数据)写入第二数据库450，然后将缓存中的数据设置为非更新标记(如0)。在该指定时间内，无论缓存被刷新了多少次，也只会写一次数据库，有效降低了数据库的访问量。需要说明的是，在其他实施例中，所述第二缓存服务器45也可以直接从第二数据库450读取需要获取的数据，或者直接将需要保存的数据存储至第二数据库450。

进一步地，所述场景服务器40中还包括对手撮合系统，该对手撮合系统用于寻找匹配的对手，即寻找匹配的客户端。举例而言，参阅图3所示，在本实施例中，所述场景服务器40根据当前客户端20的等级(如玩家等级)和等待时间，确定客户端匹配的等级范围(即图3中所示的“匹配范围”)，然后根据确定的等级范围，在排队列表中按时间顺序选取匹配的客户端，即按时间顺序从排队列表中选取等级位于所述匹配范围内的客户端(自己除外)。如果匹配的客户端有多个，则按时间顺序选取报名时间(即请求寻找玩家或对手的时间)最早的客户端作为匹配的客户端。

在本实施例中，所述匹配范围随着客户端等待时间的增加，根据预设的放宽系数依次增大。具体而言，每隔预设时间(如10秒钟)，所述匹配范围增加一个预设的放宽系数X，所述预设的放宽系数X根据以下公式计算得出：X＝Int(预设固定值/排队总人数)+1，其中，Int()代表取整函数。例如，预设固定值为100，如果目前排队列表中的排队总人数为120人，则X＝1，即每隔10秒钟，所述匹配范围放宽正负1级。例如，参阅图3所示，玩家1的等级为13，等待时间为35秒，则匹配范围为10～16级，如果排队列表中的13级玩家为玩家自己，则排队列表的16级玩家为匹配的客户端。在本实施例中，默认玩家的最小等级为1，如果匹配范围的下限值小于1，则取默认最小等级为匹配范围的下限值。例如，参阅图3所示，玩家2的等级为2，等待时间为20秒，则初步确定的匹配范围为0～4级，调整后为1～4级。

以下结合图4，对图2中客户端20的架构进一步描述。在本实施例中，所述客户端20包括，但不限于，通过数据线和信号线相连的逻辑系统201、客户端框架202，资源模块203、用户输入模块204、屏幕输出模块205、游戏引擎206和UI(User Interface，用户界面)模块207。其中，UI模块207用于接收用户输入模块204输入的数据信息(如账户密码等)，并将接收的输入信息传递至游戏引擎206。

进一步地，所述逻辑系统201包括传统游戏平台通用的技能系统、战斗系统、关卡系统、好友系统、公会系统、及聊天系统等。所述逻辑系统201与UI模块207保持数据连接，彼此传输数据信息，如战斗信息、聊天信息等。

所述客户端框架202包括通过数据线和信号线相连的动作动画模块、对象管理模块、事件处理模块、配置文件解析模块、网络模块、资源管理模块、异步加载模块、日志模块等。所述对象管理模块用于对逻辑系统201中的各种对象(如战斗系统、聊天系统等)进行管理。所述事件处理模块用于处理客户端20的注册事件。所述配置文件解析模块用于加载客户端20的注册数据、并从资源模块203中读取配置文件，该配置文件包括用户的角色信息等。

所述网络模块用于处理客户端20的注册消息，与服务器端(如登录服务器30、负载均衡服务器36等)建立通信连接，并将日志信息存储至日志模块。所述异步加载模块用于利用异步加载方法，控制资源模块203中的客户端资源(如图形资源)进行异步加载，并将加载后的客户端资源传递至资源管理模块。在本实施例中，所述异步加载是指前台游戏运行的同时，在后台用另一线程加载资源，而没有加载资源的等待界面。具体而言，在本实施例中，可以在前台玩家战斗或等待的同时，加载牌堆中剩余卡牌相关的人物图形资源。

所述资源管理模块用于对客户端资源进行管理，包括以下三方面内容。

(1)按场景组织资源，同级场景之间共享的资源放在share目录下，当前场景和下级场景之间共享的资源放在common目录下，参阅图5所示。在图5中，hall图标代表游戏大厅，hall_altas目录代表大厅中的角色，player图标代表当前玩家。举例而言，全局common目录下放置有通用字体，是所有场景都用的，而登录、选对战模式、对手匹配3个场景，由于背景图是一样的，故放置于和这3个场景同级的share目录里。

(2)如果客户端20从上级场景切换到下级场景，卸载上级场景自身专用资源和同级共享目录的资源，保留上级场景common目录，加载下级场景common目录，share目录和目标场景。

(3)如果客户端20从下级场景切换到上级场景，卸载下级场景common目录，share目录和下级场景专用资源，加载上级场景share目录和目标场景。

需要说明的是，如果客户端20为台式电脑，游戏资源总量在200M左右时，为了减少网页游戏资源下载量，设置所有的common目录和share目录都不卸载。

进一步地，如果客户端20为手机，当大量人物(如120个)在同一场战斗中出场时，在手机上进入战斗场景有较大的内存压力，可以将角色资源在进入场景后，通过异步加载模块进行异步加载。

需要说明的是，图4只是对客户端20软件结构和硬件结构的示意性说明，客户端20还包括其它必要的电子元器件和系统软件，如显示屏幕和输入设备等，在此不再一一赘述。

如图6所示，是本发明网络数据负载均衡设计方法的主流程图，以下步骤将结合图1和图2的系统架构进行说明。

步骤S601，设置负载均衡服务器36，当客户端20连接至登录服务器30后，建立客户端20与负载均衡服务器36的连接。

步骤S602，负载均衡服务器36分配网关服务器37的连接数据给客户端20，断开客户端20与负载均衡服务器36的连接。

步骤S603，设置场景服务器40，通过网关服务器37建立客户端20与场景服务器40的连接，由场景服务器40控制客户端20操作。

进一步地，所述场景服务器40中还包括对手撮合系统，该对手撮合系统用于寻找匹配的对手，即寻找匹配的客户端，具体方法参阅上述图3的描述。

步骤S604，设置与场景服务器40连接的HTTP服务器31，控制客户端20的角色登录和支付等相关功能。

步骤S605，设置与场景服务器40连接的全局数据服务器38，存储当前服务器组共享的数据和该数据的逻辑。

步骤S606，设置主中心服务器41，用于管理一个或多个子中心服务器43和离线数据服务器44，当客户端20完成角色登录时建立客户端20与离线数据服务器44的连接。该离线数据服务器44用于控制客户端20离线数据的发送和接收。

步骤S607，设置与场景服务器40连接的大厅服务器51，用于控制游戏平台中房间的创建、销毁操作，给房间分配PVP服务器52，并控制PVP服务器52处理客户端20的游戏任务。

步骤S608，设置与场景服务器40连接的缓存服务器(如第二缓存服务器45)，用于当前服务器组中的一个指定服务器需要获取数据或存储数据时，从与该缓存服务器连接的数据库(如第二数据库450)中获取相应数据或进行数据存储，具体方法参阅上述图2的描述。

进一步地，基于上述网络数据负载均衡设计系统2，本发明进一步设计出一种新的网络游戏：卡棋游戏，该卡棋游戏同时具备传统卡牌游戏和棋类游戏的优点。

桌面卡牌游戏于最近十年在中国流行起来，其中以《三国杀》、《万智牌》和《游戏王》最为著名。这些卡牌大都是通过摸牌、出牌结合人物的技能来实现各种玩法。相对于传统的棋牌游戏，桌面卡牌游戏略显复杂一些。

而传统棋类游戏(例如象棋、军旗)则大都采用抽象化的棋子，以移动或者布置棋子、使用棋子的特殊能力进行对抗。

传统卡牌游戏缺少基于空间位置和距离逻辑的策略玩法，因此深度有限，运气成分较大。而以《三国杀》为代表的卡牌游戏门槛也略高，尤其是在中后期新出的卡牌描述和逻辑非常复杂，更难向大众普及。

而传统棋类游戏尽管有策略深度，但由于棋子比较死板，缺少画面表现力和人物个性，因此现代年轻人玩得越来越少。

基于上述网络数据负载均衡设计系统2，本发明进一步设计出一种新的网络游戏：卡棋游戏，解决了传统卡牌游戏存在的深度不足、运气成分较大，以及传统棋类游戏比较死板，缺少画面表现力、人物个性以及携带方便性的问题，该卡棋游戏可推广成为老少皆宜的大众益智娱乐产品。

参阅图7所示，本实施例设计出一种电子版卡棋游戏《神将录》，可供2～8人一起通过网络在线参与。游戏参与者通过消耗法力召唤人物、使用法术和装备来打败敌方的军队，最终消灭对手的王，该卡棋游戏棋盘区域的具体说明如下所述。

王位：位于棋盘中央区域四条边界的中心位置，带有王冠的格子表示该方位玩家的王者所处的位置，王位上不能召唤将士人物。

出兵点：离王位最近的带有+号的3格是该方玩家可用的出兵点，每次出兵只能在这3个空着的格子中选择。若出兵点被占领，则此点不再能出兵。

天元：棋盘区域的中央位置称为“天元”，用于阻挡一切移动和攻击线路(包括范围攻击)。

套牌位：位于王位的右下方，玩家自己方的套牌放置的位置，所述套牌包括，但不限于，人物牌、法术牌和装备牌中的一种或多种。

标记位：位于王位的右下方，标记卡放置的位置。

体力卡：位于王位的正下方，用于记录王者的剩余体力，王者的初始体力默认为6点，不能每回合自动回复。

墓地：位于王位的左下方，用于放置自己方死亡的人物、使用过的法术或装备。

在本实施例中，卡牌分为人物牌、法术牌、装备牌、标记卡、体力卡5种，其中，标记卡和体力卡是用于帮助记录游戏信息的卡牌。需要说明的是，本发明所述卡棋游戏的棋盘和卡牌也可以做成实物的卡棋装置，如纸质棋盘和纸质卡牌等。

参阅图8所示，是本发明所述卡棋游戏中人物牌的示意图，具体说明如下。

顶条颜色：用于快速分辨同阵营人物，不同阵营可以用不同的颜色在人物牌的边框周围进行标记。

攻击力：普通攻击产生的伤害，并不影响攻击型技能的伤害。

体力：一个回合内能够承受一次或者多次攻击的累计伤害最大值。

移动力：一个回合内的最远移动距离。

触发形式：该技能是主动还是自动触发。若是自动触发，则表示无需主动施放而自动生效。

参阅图9所示，是本发明所述卡棋游戏中法术牌的示意图，法力消耗下方有“法术”标识的卡牌表示法术牌。使用法术需要消耗法力，使用后放入各自的墓地。

参阅图10所示，是本发明所述卡棋游戏中装备牌的示意图，具体说明如下。法力消耗下方有“装备”标识的卡牌是装备牌，装备牌一般需要装配到人物身上才能使用它的效果。

一个人物最多只能装配一件装备。若目标人物身上已有装备，则新装备会替换旧装备，旧装备进入“墓地”。若带有装备的人物死亡，则其装备也一并进入墓地。

参阅图11所示，是本发明所述卡棋游戏中标记卡的示意图，具体说明如下。所述标记卡用于标记持续型法术效果，例如中毒、止步、镇压等。其中，每个玩家最多可携带9张标记卡，若某种标记卡用完，则该种标记卡对应的法术效果将不能被触发。

参阅图12所示，是基于网络数据负载均衡设计系统的卡棋游戏用户界面示意图。

在本实施例中，所述卡棋游戏包括，但不限于，1V1模式、身份模式、竞技场模式、及练习模式等。所述1V1模式是指玩家与玩家一对一的模式，所述身份模式类似于《三国杀》中的标准模式，玩家彼此不知道对方的身份，所述竞技场模式是指所有玩家在一起相互战斗的模式，所述练习模式是指玩家与客户端20互动的模式。

以下以竞技场模式为例具体介绍所述卡棋游戏的各个步骤，在竞技场模式中，每个玩家的回合经历4个阶段(步骤)：

(1)开始阶段：若此前被人施放一些延时生效的法术(例如让该人物此回合内不能行动)，则在此阶段生效。若有多个延时法术，则后施放的先生效。游戏开始洗牌后，每个玩家初始摸5张手牌。

(2)摸牌阶段：从牌堆中继续摸2张牌。

(3)行动阶段：具体包括以下3种行为(3.1～3.3)，顺序可自行决定；

3.1召唤人物，按照法力消耗召唤人物上场。一般情况下，刚召唤的人物本回合内不能立刻行动(此称为“立足时间”)，但若受到攻击会反击。

3.2指挥行动，指挥上一回合上场的自己方全部人物陆续行动一次，行动内容有以下3种选择(A～C)：

A、移动后普通攻击一个相邻者；

B、原地使用一次主动技能(自动技能无需使用)；

C、只移动，不战斗。

3.3使用法术或配戴装备，摸到的法术牌或者装备牌可在自己的回合里使用，只要法力值足够。

(4)结束阶段：受伤的人物生命值全部回满。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种网络数据负载均衡设计系统，其特征在于，该系统包括：

登录服务器，用于通过网络与客户端连接，其中，所述客户端用于输入账号登录和选取一个大区，每一个大区对应一负载均衡服务器；

所述登录服务器，还用于验证账号及在账号验证通过后，控制客户端获取所选取大区对应的负载均衡服务器的地址和端口信息，及断开与客户端的连接；

负载均衡服务器，与登录服务器连接，用于根据客户端获取到的负载均衡服务器的地址和端口信息，建立客户端与负载均衡服务器的连接；

所述负载均衡服务器，还用于分配网关服务器的连接数据给客户端，断开客户端与负载均衡服务器的连接；

场景服务器，用于通过网关服务器建立与客户端的连接，并控制客户端操作；

超文本传输协议HTTP服务器，与场景服务器连接，用于控制客户端的角色登录和支付相关功能；

全局数据服务器，与场景服务器连接，用于存储当前服务器组共享的数据和该数据的逻辑；

主中心服务器，用于管理子中心服务器和离线数据服务器，当客户端完成角色登录时建立客户端与离线数据服务器的连接，该离线数据服务器控制客户端离线数据的发送和接收；

大厅服务器，与场景服务器连接，用于控制游戏平台中房间的创建和销毁操作，给房间分配竞技服务器，并控制竞技服务器处理客户端的游戏任务；及

缓存服务器，与场景服务器连接，用于当一个指定服务器需要获取数据或存储数据时，通过与该缓存服务器连接的数据库获取相应数据或进行数据存储。

2.如权利要求1所述的网络数据负载均衡设计系统，其特征在于，所述场景服务器还用于：

根据当前客户端的等级和等待时间，确定客户端匹配的等级范围，其中，所述匹配范围随着客户端等待时间的增加，根据预设的放宽系数依次增大；及

根据确定的等级范围，在排队列表中按时间顺序选取匹配的客户端。

3.如权利要求2所述的网络数据负载均衡设计系统，其特征在于，所述匹配范围每隔预设时间增加一个预设的放宽系数X，所述预设的放宽系数X根据以下公式计算得出，X＝Int(预设固定值/排队总人数)+1，其中，Int()代表取整函数。

4.如权利要求1所述的网络数据负载均衡设计系统，其特征在于，所述缓存服务器还用于：

当该指定服务器需要获取数据时，确定内存中是否有需要获取的数据，如果内存中没有需要获取的数据，则从数据库中读取需要获取的数据，并将读取的数据返回至该指定服务器；如果内存中有需要获取的数据，直接返回内存中的相关数据至该指定服务器；及

当该指定服务器需要存储数据时，首先更新该指定服务器缓存中的数据，将需要存储的数据更新至缓存，并将缓存中的数据设置为更新标记，在第一次更新后的指定时间后将缓存中的数据写入数据库，然后将缓存中的数据设置为非更新标记。

5.一种网络数据负载均衡设计方法，其特征在于，该方法包括如下步骤：设置登录服务器，通过网络与客户端连接，其中，所述客户端用于输入账号登录和选取一个大区，每一个大区对应一负载均衡服务器；验证账号及在账号验证通过后，控制客户端获取所选取大区对应的负载均衡服务器的地址和端口信息，及断开与客户端的连接；

设置负载均衡服务器，根据客户端获取到的负载均衡服务器的地址和端口信息，建立客户端与负载均衡服务器的连接；

负载均衡服务器分配网关服务器的连接数据给客户端，断开客户端与负载均衡服务器的连接；

设置场景服务器，通过网关服务器建立客户端与场景服务器的连接，由场景服务器控制客户端操作；

设置与场景服务器连接的超文本传输协议HTTP服务器，控制客户端的角色登录和支付相关功能；

设置与场景服务器连接的全局数据服务器，存储当前服务器组共享的数据和该数据的逻辑；

设置主中心服务器，管理子中心服务器和离线数据服务器，当客户端完成角色登录时建立客户端与离线数据服务器的连接，该离线数据服务器控制客户端离线数据的发送和接收；

设置与场景服务器连接的大厅服务器，控制游戏平台中房间的创建和销毁操作，给房间分配竞技服务器，并控制竞技服务器处理客户端的游戏任务；及

设置与场景服务器连接的缓存服务器，当一个指定服务器需要获取数据或存储数据时，通过与该缓存服务器连接的数据库获取相应数据或进行数据存储。

6.如权利要求5所述的网络数据负载均衡设计方法，其特征在于，该方法还包括步骤：

场景服务器根据当前客户端的等级和等待时间，确定客户端匹配的等级范围，其中，所述匹配范围随着客户端等待时间的增加，根据预设的放宽系数依次增大；及

根据确定的等级范围，在排队列表中按时间顺序选取匹配的客户端。

7.如权利要求6所述的网络数据负载均衡设计方法，其特征在于，所述匹配范围每隔预设时间增加一个预设的放宽系数X，所述预设的放宽系数X根据以下公式计算得出，X＝Int(预设固定值/排队总人数)+1，其中，Int()代表取整函数。

8.如权利要求5所述的网络数据负载均衡设计方法，其特征在于，该方法还包括如下步骤：

当该指定服务器需要获取数据时，确定内存中是否有需要获取的数据，如果内存中没有需要获取的数据，则从数据库中读取需要获取的数据，并将读取的数据返回至该指定服务器；如果内存中有需要获取的数据，直接返回内存中的相关数据至该指定服务器；及

当该指定服务器需要存储数据时，首先更新该指定服务器缓存中的数据，将需要存储的数据更新至缓存，并将缓存中的数据设置为更新标记，在第一次更新后的指定时间后将缓存中的数据写入数据库，然后将缓存中的数据设置为非更新标记。