一种数据处理方法、装置及系统与流程

本申请涉及数据处理技术领域，更具体地说，涉及一种数据处理方法、装置及系统。

背景技术：

伴随智能终端的普及，越来越多的游戏软件应用于智能终端上。用户可以在智能终端上打开游戏软件，并在智能终端联网状态下进行游戏。

在用户实际游戏过程中，经常会出现“弱网络”情况，也即终端的网络状态不稳定，容易造成游戏客户端与游戏服务器之间传输的数据包丢失的问题。丢包可以分为两种情况，一种是游戏客户端向游戏服务器发送的消息包丢失，也即游戏服务器未收到游戏客户端发送的消息包；另一种是游戏服务器收到游戏客户端发送的消息包后进行业务处理生成响应包，在将响应包发送给游戏客户端的过程出现异常，造成游戏客户端未接收到响应包。

现有处理方式是，游戏客户端在发送消息包后的一定时间内未收到响应包，则游戏客户端将上次发送的消息包重新进行发送。这种处理方式在出现上述第二种丢包情况时，即首次发送的消息包被游戏服务器接收到并进行了业务处理生成响应包，该响应包未被游戏客户端接收到，则当游戏客户端再次发送消息包且被游戏服务器接收到时，游戏服务器会再次进行相同的业务处理以生成响应包。显然，针对一个消息包游戏服务器进行了两次相同的业务处理，这将会给用户带来负面影响，降低用户游戏体验度。

以用户在游戏中的角色“死亡”后点击“购买复活”图标的操作为例，游戏客户端将“购买复活”的消息包发送给游戏服务器，后者收到后对用户账户进行扣费后生成“复活”指令的响应包发送给游戏客户端，而后者未收到响应包并重新发送相同的消息包给游戏服务器，游戏服务器收到后再次对用户账户进行扣费后生成“复活”指令的响应包发送给游戏客户端。显然，对用户而言，一次“复活”却耗费了双倍的费用，降低了用户的游戏体验度。

技术实现要素：

有鉴于此，本申请提供了一种数据处理方法、装置及系统，用于解决现有游戏数据包处理方式在弱网络状态下容易出现游戏服务器针对同一消息包进行两次相同的业务处理，从而给用户带来负面影响，降低用户游戏体验度的问题。

为了实现上述目的，现提出的方案如下：

一种数据处理方法，应用于游戏服务器，该方法包括：

接收游戏客户端发送的重试的同步包，所述同步包携带有更新游戏数据的同步请求；

查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；

将查询到的响应包发送至所述游戏客户端。

一种数据处理方法，应用于游戏客户端，该方法包括：

确定已发送且未收到对应响应包的同步包，所述同步包携带有更新游戏数据的同步请求；

将确定的同步包再次发送至游戏服务器；

接收所述游戏服务器反馈的响应包，所述响应包为所述游戏服务器收到所述同步包后，在历史缓存的响应包中查询到的与所述同步包对应的响应包，在历史缓存中查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包。

一种数据处理装置，应用于游戏服务器，该装置包括：

同步包接收单元，用于接收游戏客户端发送的消息包，所述消息包携带有包属性，所述包属性用于表明所述消息包是否为重试包；

响应包查询单元，用于查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；

响应包发送单元，用于将查询到的响应包发送至所述游戏客户端。

一种数据处理装置，应用于游戏客户端，该装置包括：

同步包确定单元，用于确定已发送且未收到对应响应包的同步包，所述同步包携带有更新游戏数据的同步请求；

同步包发送单元，用于将确定的同步包再次发送至游戏服务器；

响应包接收单元，用于接收所述游戏服务器反馈的响应包，所述响应包为所述游戏服务器收到所述同步包后，在历史缓存的响应包中查询到的与所述同步包对应的响应包，在历史缓存中查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包。

一种数据处理系统，包括游戏客户端和游戏服务器，其中：

所述游戏客户端确定已发送且未收到对应响应包的同步包，将确定的同步包再次发送至游戏服务器，所述同步包携带有更新游戏数据的同步请求；

所述游戏服务器接收游戏客户端发送的同步包；查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；将查询到的响应包发送至所述游戏客户端。

从上述的技术方案可以看出，本申请实施例提供的应用于游戏服务器的数据处理方法，游戏服务器接收游戏客户端发送的重试的同步包，该同步包携带有更新游戏数据的同步请求，进而，查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包，最后，将查询到的响应包发送至所述游戏客户端。本申请中游戏服务器在确认收到的游戏客户端发送的同步包为重试的同步包时，在缓存中查询与所述同步包对应的响应包，如果查询到，则说明游戏服务器之前收到过该同步包并进行了游戏数据的更新，因此直接将查找到的响应包发送给游戏客户端，而不会再次进行游戏数据的更新，保证了游戏服务器针对同一同步包不会重复进行游戏数据更新，也即不会给用户带来负面影响，保证用户游戏体验度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面 描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例从游戏服务器角度公开的一种数据处理方法流程图；

图2为本申请实施例从游戏服务器角度公开的另一种数据处理方法流程图；

图3为本申请实施例从游戏客户端角度公开的一种数据处理方法流程图；

图4为本申请实施例从游戏服务器角度公开的一种数据处理装置结构示意图；

图5为本申请实施例从游戏客户端角度公开的一种数据处理装置结构示意图；

图6为本申请实施例公开的一种游戏服务器的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请方案之前需要说明，游戏网络通信的消息包，按照重要程度，可以分为同步包和异步包。其中，对于丢包后会影响玩家后续体验或者导致经济损失的一类消息包作为同步包，其余的作为异步包。本申请下文均以同步包进行说明。

本申请针对用户游戏过程，游戏客户端与游戏服务器之间的同步包交互过程进行了改进，以使得游戏服务器针对同一同步包不会重复进行游戏数据更新，保证了用户游戏体验度。

接下来，分别从游戏服务器和游戏客户端的角度来介绍本申请方案。首先，参见图1，图1为本申请实施例从游戏服务器角度公开的一种数据处理方法流程图。

如图1所示，该方法包括：

步骤s100、接收游戏客户端发送的重试的同步包；

具体地，针对游戏客户端而言，响应用户的某一操作而生成同步包，并向游戏服务器发送该同步包。如果在设定时间段内，游戏客户端未收到游戏服务器反馈的与所述同步包对应的响应包，则游戏客户端重新将所述同步包发送至游戏服务器。

针对游戏服务器而言，如果某一时间收到游戏客户端发送的同步包，根据同步包中的同步请求进行了游戏数据更新，生成响应包，并向游戏客户端反馈，而该响应包未被游戏客户端接收，因此一定时间后游戏服务器再次收到相同数据内容的同步包，对于游戏服务器而言，该同步包即为收到的游戏客户端发送的重试的同步包。

可选的，为了表明一个同步包是否为重试的包，可以在同步包中增加包属性，包属性用于记录该同步包是否为重试的包，。同步包可以看作由包头部分和数据部分组成，数据部分携带的是同步请求数据，用于供游戏服务器进行游戏数据更新，而包头部分可以包含包属性。

可选的，可以用“0”来代表同步包为重试的包，用“1”来代表同步包为非重试的包。或者，直接在该字段中用“重试包”或“非重试包”来表明同步包的属性。

步骤s110、查询历史缓存的响应包中与所述同步包对应的响应包；

其中，所查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包。

具体地，由于游戏服务器已经确认接收的同步包为重试的同步包，也即游戏服务器之前曾接收过所述同步包，并根据所述同步包携带的同步请求进行了游戏数据更新，生成对应的响应包。因此，在确定当前接收的同步包为重试的同步包时，在历史缓存的响应包中查找与所述同步包对应的响应包，而不需要再次根据同步包携带的同步请求进行游戏数据的更新、生成响应包。

步骤s120、将查询到的响应包发送至所述游戏客户端。

具体地，如果在缓存中查找到与所述同步包对应的响应包，则意味着游戏服务器历史收到过所述同步包，并针对同步包进行了游戏数据更新，生成了对应的响应包。进而，游戏服务器不需要再次针对所述同步包进行游戏数据更新，直接将查找到的响应包发送给游戏客户端即可。

本申请实施例提供的应用于游戏服务器的数据处理方法，游戏服务器接收游戏客户端发送的重试的同步包，该同步包携带有更新游戏数据的同步请求，进而，查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包，最后，将查询到的响应包发送至所述游戏客户端。本申请中游戏服务器在确认收到的游戏客户端发送的同步包为重试的同步包时，在缓存中查询与所述同步包对应的响应包，如果查询到，则说明游戏服务器之前收到过该同步包并进行了游戏数据的更新，因此直接将查找到的响应包发送给游戏客户端，而不会再次进行游戏数据的更新，保证了游戏服务器针对同一同步包不会重复进行游戏数据更新，也即不会给用户带来负面影响，保证用户游戏体验度。

上述已经说明，同步包携带的同步请求用于供游戏服务器进行游戏数据更新，该游戏数据可以包括游戏结算数据和/或虚拟货币交易数据。

接下来，通过一个具体实例了介绍本申请方案。

以一款角色扮演游戏arpg手游的pve关卡战斗场景(pve关卡战斗场景即为玩家vs环境的战斗场景)为例：

关卡战斗玩法中，游戏客户端与游戏服务器间有网络通信交互的有以下三个操作：

1、关卡战斗开始

2、关卡中途玩家复活，该操作涉及到玩家虚拟货币消费

3、关卡结束时进行结算

单场关卡战斗持续时间大约在3-5分钟，除了上述三个时间点外，中间的战斗过程不需要游戏客户端与游戏服务器进行网络交互。

本实施例中以关卡中途玩家复活为例说明：

玩家在游戏中的角色“死亡”后点击“购买复活”图标，游戏客户端响应用户的这一操作，生成同步包，同步包中携带有“购买复活”指令，并将同步包发送给游戏服务器。

游戏服务器收到同步包后对玩家账户进行虚拟货币扣费，然后生成响应包，该响应包携带有“复活”指令，以供游戏客户端收到该响应包后“复活” 玩家角色。游戏服务器将生成的响应包发送给游戏客户端，同时将该响应包缓存。而由于通信故障，该响应包未被游戏客户端成功接收。

游戏客户端在设定的时间段内未收到针对同步包的响应包，因此将所述同步包重新发送至游戏服务器。

按照现有技术的处理逻辑，游戏服务器收到重试的同步包后将其作为一个全新的同步进行业务处理，也即重复上述“虚拟货币扣费，生成响应包，向游戏客户端发送响应包”步骤。显然，针对玩家而言，其角色“复活”了一次，而进行了两次扣费，对玩家造成了经济损失。

而按照本申请的处理逻辑，游戏服务器收到重试的同步包后，首先在缓存中查找与所述同步包对应的响应包，进而查找到历史缓存的与所述同步包对应的响应包，然后直接将查找到的响应包发送给游戏客户端，而不再针对收到的重试的同步包进行“虚拟货币扣费，生成响应包”的步骤。

游戏客户端收到响应包，复活玩家用户在游戏中的角色。

对比本申请方案与现有技术可知，本申请的方案当由于网络故障而造成游戏服务器生成的响应包未被游戏客户端接收到时，针对游戏客户端发送的重试的同步包，不再进行“虚拟货币扣费，生成响应包”的操作，而是直接查询历史缓存的与所述同步包对应的响应包，将其直接发送给游戏客户端，避免了对玩家经济造成损失。

同理针对“关卡战斗开始”与“关卡结束时结算”两种场景。

进一步需要说明的是，上述为了使游戏服务器能够识别一个同步包是否为重试的包，游戏客户端可以在同步包的包头中增加包属性字段，并设定“0”代表非重试包，“1”代表重试包。这样，游戏服务器在收到一个同步包后，根据同步包包头部分的包属性字段即可确认该同步包是否为重试的包。

可以理解的是，在上述实施例的基础上，若游戏服务器在收到游戏客户端发送的重试的同步包后，在历史缓存的响应包中未能查找到与所述同步包对应的响应包，则意味着游戏服务器历史未曾收到过所述同步包，这可能是因为游戏客户端首次发送的同步包由于网络故障而未被游戏服务器接收到。针对这种情况，本实施例中的游戏服务器可以根据所述同步包中携带的同步请求，进行游戏数据更新，进而生成对应的响应包，然后将生成的响应包缓 存并发送给游戏客户端。

详细参见图2，图2为本申请实施例从游戏服务器角度公开的另一种数据处理方法流程图。

如图2所示，该方法包括：

步骤s200、接收游戏客户端发送的重试的同步包；

可选的，为了表明一个同步包是否为重试的包，可以在同步包中增加包属性，包属性用于记录该同步包是否为重试的包，。同步包可以看作由包头部分和数据部分组成，数据部分携带的是同步请求数据，用于供游戏服务器进行游戏数据更新，而包头部分可以包含包属性。

可选的，可以用“0”来代表同步包为重试的包，用“1”来代表同步包为非重试的包。或者，直接在该字段中用“重试包”或“非重试包”来表明同步包的属性。

步骤s210、查询历史缓存的响应包中是否存在与所述同步包对应的响应包，若是，执行步骤s220，若否，执行步骤s230；

其中，游戏服务器缓存中的响应包为针对收到的历史同步包进行游戏数据更新所生成的与历史同步包对应的响应包。也即，在游戏服务器本次收到同步包之前，针对收到的历史同步包进行游戏数据更新所生成的响应包。

步骤s220、将查询到的响应包发送至所述游戏客户端；

具体地，如果在缓存中查找到与所述同步包对应的响应包，则意味着游戏服务器历史收到所述同步包，并针对所述同步包进行了游戏数据更新，生成了对应的响应包。进而，游戏服务器不需要再次针对所述同步包进行业务处理，直接将查找到的响应包发送给游戏客户端即可。

步骤s230、根据所述同步包中携带的同步请求，进行游戏数据更新，生成对应的响应包；

具体地，如果在缓存中未查找到与所述同步包对应的响应包，则意味着游戏服务器历史未收到过所述同步包，则游戏服务器作为一个新的同步包来进行业务处理。

步骤s240、将生成的响应包进行缓存，并向所述游戏客户端发送该生成的响应包。

具体地，针对业务处理生成的响应包，在向游戏客户端发送的同时，还可以将其进行缓存，以便后续使用。

相比于上一实施例，本实施例中进一步介绍了在确定历史缓存的响应包中不存在与所述同步包对应的响应包时的具体操作方式，也即游戏服务器按照新的同步包进行业务处理，生成响应包并进行缓存。

可选的，上述将生成的响应包进行缓存的过程，具体可以是：

利用生成的响应包覆盖历史缓存的响应包。

也即，游戏服务器中仅缓存最近一次生成的响应包。一般情况下，用户在游戏客户端上点击某个图标来发起请求时，游戏客户端响应用户请求而生成同步包，并向游戏服务器发送。游戏客户端在等待游戏服务器的响应包的过程中，一般会将游戏界面锁定，处于锁定状态的界面不会响应用户的任何操作，从而保证了游戏客户端不会在等待响应包的过程再次向游戏服务器发送新的同步包。

基于此，游戏服务器中仅仅需要缓存最近一次生成的响应包即可，也只有最近一次生成的响应包有可能会使用到。

再进一步的，游戏客户端向游戏服务器发送的同步包中还可以进一步携带有包标识，包标识用于唯一标识一个同步包，可以看作同步包的“身份证”。同时，游戏服务器中历史缓存的响应包也标记有对应同步包的包标识。则上述查询历史缓存的响应包中是否存在与所述同步包对应的响应包的过程可以是：

根据所述同步包的包标识，在历史缓存的响应包中查询是否存在与所述包标识对应的响应包。

接下来，本申请实施例从游戏客户端角度再次对本申请方案进行介绍。

参见图3，图3为本申请实施例从游戏客户端角度公开的一种数据处理方法流程图。

如图3所示，该方法包括：

步骤s300、确定已发送且未收到对应响应包的同步包；

其中，所述同步包携带有更新游戏数据的同步请求。

针对游戏客户端而言，响应用户的某一操作而生成同步包，并向游戏服务器发送该同步包。如果在设定时间段内，游戏客户端未收到游戏服务器反馈的与所述同步包对应的响应包，则确定需要重新发送该同步包。

步骤s310、将确定的同步包再次发送至游戏服务器；

步骤s320、接收所述游戏服务器反馈的响应包。

具体地，所述响应包为所述游戏服务器收到所述同步包后，在历史缓存的响应包中查询到的与所述同步包对应的响应包，在历史缓存中查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包。

可选的，为了便于游戏服务器确定一个同步包是否为重试的包，游戏客户端可以在同步包的包头中增加包属性，包属性用于记录所述同步包是否为重试的包。例如，用“0”代表为重试包，用“1”代表为非重试包。

基于此，上述实施例在步骤s310之前，进一步增加：

对所述同步包的包属性进行更新，更新后的包属性表明所述同步包为重试的包。

也即，游戏客户端首次发送的同步包中包属性表明其为非重试的包，而当确定需要重新发送同步包时，首先将其包属性进行更新，更新后的包属性表明所述同步包为重试的包，进而在步骤s310中，将包属性更新后的同步包发送给游戏服务器。

可选的，在上述将确定的同步包再次发送至游戏服务器的同时，锁定游戏客户端的游戏界面，以屏蔽玩家的游戏操作。从而保证了游戏客户端不会在等待响应包的过程再次向游戏服务器发送新的同步包。

进一步，在游戏客户端接收到游戏服务器反馈的响应包的同时，解除游戏客户端的游戏界面的锁定。解除锁定后，游戏客户端可以再次接收用户的游戏操作。

可选的，游戏客户端发送的同步包还可以进一步携带有包标识，包标识用于唯一标识一个同步包，可以看作同步包的“身份证”。所述包标识用于供游戏服务器缓存针对所述同步包生成的响应包时，将所述响应包与所述包标识关联存储。

可选的，上述已经介绍了游戏客户端设置有超时重试时间，也即游戏客户端在发送同步包后，在超时重试时间到达时仍未收到游戏服务器反馈的响应包，则会重新发送同步包。在此基础上，本申请对游戏服务器业务处理的时间也进行了超时设定，并且游戏服务器业务处理的超时时间必须小于游戏客户端的超时重试时间，从而保证游戏客户端发送重试包时游戏服务器已经执行完业务处理过程，不会出现由于游戏服务器处于业务处理过程，而导致游戏客户端未收到响应包，进而向游戏服务器发送重试包的情况。

在上述基础上，本申请实施例从游戏客户端角度介绍了一种断网重连的机制。

在介绍本申请的断网重连机制之前，首先对现有技术进行简单介绍。

现有技术中，玩家在游戏客户端进行游戏操作，某一时刻游戏客户端检测到网络断开，则游戏客户端即刻锁定游戏界面，终止玩家的游戏操作，同时提示玩家网络断开，是否进行重连。

而针对具体游戏而言，一般仅在“进入关卡”、“死亡复活”和“关卡结束结算”这三个环节需要游戏客户端与游戏服务器进行通信，其余大部分时间游戏客户端不需要和游戏服务器进行通信。因此，现有的断网重连机制，在终端断网时有可能玩家的游戏操作不需要游戏客户端与游戏服务器进行通信，此时终止玩家操作将会影响玩家游戏体验。

为此，本申请提供了一种新的断网重连机制，如下所示：

仅在确定需要针对玩家当前的游戏操作向游戏服务器发送同步包，且游戏客户端处于断网状态时，重新连接网络；

在确定设定重连次数阈值内成功连接网络时，向所述游戏服务器发送同步包；

在确定设定重连次数阈值内未成功连接网络时，提示用户网络断开。

具体实施时，玩家游戏过程中，游戏客户端持续对网络状态进行检测，当某一时刻检测到网络链接断开，则设置断开标志，同时并不终止玩家的游戏操作，也即玩家此时并不知道网络链接断开，仍旧继续游戏。当玩家某个游戏操作触发游戏客户端向游戏服务器发送同步包时，游戏客户端查询存在网络链接断开标志，进而自动重新连接网络。游戏客户端设定了重连次数阈 值，在阈值内如果重连成功，则直接将同步包发送给游戏服务器；在阈值内如果未重连成功，则可以提示用户网络断开。

显然，如果是因为网络不稳定导致的网络链接断开，则按照本申请方案，在确定需要针对玩家当前的游戏操作向游戏服务器发送同步包时进行网络重连，此时的网络可能已经稳定了，重连一次即可成功，进而直接发送同步包。整个“断网-重连”的过程对于用户而言是透明的，用户感受不到网络出现过故障，能够更好的享受游戏过程，提高了玩家的游戏体验度。

可以理解的是，由于游戏客户端侧存在断网重连的机制，对应于游戏服务器一侧，其接收到的同步包可能是游戏客户端在确定需要发送所述同步包且确定自身处于断网状态时，在预置重连次数阈值内成功连接网络后发送的同步包。

仍通过上述arpg手游的pve关卡战斗场景为例：

假设玩家在进入关卡后进入战斗场景，这个过程中游戏客户端不需要与游戏服务器进行网络通信。

在玩家战斗过程中，某一个时刻游戏客户端网络连接断开。

按照现有的处理逻辑，游戏客户端立即锁定游戏界面，终止用户的游戏操作，提示用户网络断开，是否进行重连。

而按照本申请的处理逻辑，游戏客户端在确定网络连接断开后，判断是否需要针对玩家操作而向游戏服务器发送同步包。由于关卡战斗过程是不需要连接游戏服务器的，因此游戏客户端确定不需要向游戏服务器发送同步包，进而维持游戏界面的游戏场景，不终止用户的游戏操作。同时，设置断网标识。

当玩家关卡战斗结束，需要进行关卡结束结算时，游戏客户端查询断网标识，确定网络连接断开，进而按照设定重连次数自动连接网络，在重连次数阈值内成功连接网络时，继续执行业务操作，也即生成同步包，向游戏服务器发送；在重连次数阈值内未成功连接网络时，提示用户网络断开。

对比本申请与现有技术可知，本申请中在玩家战斗过程出现游戏客户端网络连接断开时，游戏客户端确定此时不需要连接游戏服务器时，并不终止玩家游戏操作，也即断网对玩家而言是透明的，仅在游戏客户端确定需要连接游戏服务器时，才自动重新连接网络。本申请方案能够使得玩家更好的享 受游戏过程，提高了玩家的游戏体验度。

下面对本申请实施例提供的数据处理装置进行描述，下文描述的数据处理装置与上文描述的数据处理装置方法可相互对应参照。

参见图4，图4为本申请实施例从游戏服务器角度公开的一种数据处理装置结构示意图。

如图4所示，数据处理装置包括：

同步包接收单元41，用于接收游戏客户端发送的重试的同步包，所述同步包携带有更新游戏数据的同步请求；

响应包查询单元42，用于查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；

响应包发送单元43，用于将查询到的响应包发送至所述游戏客户端。

应用本申请实施例提供的数据处理装置，游戏服务器在确认收到的游戏客户端发送的同步包为重试的同步包时，在缓存中查询与所述同步包对应的响应包，如果查询到，则说明游戏服务器之前收到过该同步包并进行了游戏数据的更新，因此直接将查找到的响应包发送给游戏客户端，而不会再次进行游戏数据的更新，保证了游戏服务器针对同一同步包不会重复进行游戏数据更新，也即不会给用户带来负面影响，保证用户游戏体验度。

需要说明的是，所述同步包携带的同步请求用于更新游戏数据，所述游戏数据可以包括游戏结算数据和/或虚拟货币交易数据。

可选的，所述同步包可以携带有包属性，所述包属性用于记录所述同步包是否为重试的包，则所述同步包接收单元可以包括：

第一同步包接收子单元，用于接收游戏客户端发送的同步包，根据所述同步包的包属性判断所述同步包是否为重试的包；若是，则确定所述同步包为重试的同步包。

可选的，所述同步包还可以携带有包标识，历史缓存的响应包标记有对应消息包的包标识，所述响应包查询单元可以包括：

第一响应包查询子单元，用于根据所述同步包的包标识，在历史缓存的响应包中查询与所述包标识对应的响应包。

参见图5，图5为本申请实施例从游戏客户端角度公开的一种数据处理装置结构示意图。

如图5所示，数据处理装置包括：

同步包确定单元51，用于确定已发送且未收到对应响应包的同步包，所述同步包携带有更新游戏数据的同步请求；

同步包发送单元52，用于将确定的同步包再次发送至游戏服务器；

响应包接收单元53，用于接收所述游戏服务器反馈的响应包，所述响应包为所述游戏服务器收到所述同步包后，在历史缓存的响应包中查询到的与所述同步包对应的响应包，在历史缓存中查询到的响应包为游戏服务器根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包。

可选的，为了便于游戏服务器识别一个同步包是否为重试的包，可以在同步包中设置包属性，包属性用于记录一个同步包是否为重试的包。基于此，该装置还可以包括：

包属性更新单元，用于在所述同步包发送单元之前，对所述同步包的包属性进行更新，更新后的包属性表明所述同步包为重试的包；

则所述同步包发送单元具体用于：

将包属性更新后的同步包再次发送至游戏服务器。

可选的，为了保证游戏客户端在发送了同步包等待游戏服务器反馈响应包的过程中，不会再次向游戏服务器发送新的同步包，本申请的数据处理装置还可以包括：

界面锁定单元，用于在所述将确定的同步包再次发送至游戏服务器的同时，锁定游戏客户端的游戏界面，以屏蔽玩家的游戏操作；

界面解锁单元，用于在所述接收所述游戏服务器反馈的响应包的同时，解除游戏客户端的游戏界面的锁定。

可选的，上述数据处理装置还可以包括：

断网重连单元，用于仅在确定需要针对玩家当前的游戏操作向游戏服务器发送消息包，且游戏客户端处于断网状态时，重新连接网络；在确定预置重连次数阈值内成功连接网络时，向所述游戏服务器发送消息包；在确定预置重连次数阈值内未成功连接网络时，提示用户网络断开。

本申请还提供了一种数据处理系统，包括游戏客户端和游戏服务器，其中：

所述游戏客户端确定已发送且未收到对应响应包的同步包，将确定的同步包再次发送至游戏服务器，所述同步包携带有更新游戏数据的同步请求；

所述游戏服务器接收游戏客户端发送的同步包；查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；将查询到的响应包发送至所述游戏客户端。

本申请还提供了一种游戏服务器，该游戏服务器包括上述应用于游戏服务器的数据处理装置。对于游戏服务器的硬件结构，参见图6，图6为本申请实施例提供的游戏服务器的硬件结构示意图。如图6所示，该游戏服务器可以包括：

处理器1，通信接口2，存储器3，通信总线4，和显示屏5；

其中处理器1、通信接口2、存储器3和显示屏5通过通信总线4完成相互间的通信；

可选的，通信接口2可以为通信模块的接口，如gsm模块的接口；

处理器1，用于执行程序；

存储器3，用于存放程序；

程序可以包括程序代码，所述程序代码包括处理器的操作指令。

处理器1可能是一个中央处理器cpu，或者是特定集成电路asic(applicationspecificintegratedcircuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器3可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，程序可具体用于：

接收游戏客户端发送的重试的同步包，所述同步包携带有更新游戏数据的同步请求；

查询历史缓存的响应包中与所述同步包对应的响应包，其中，所查询到的响应包为根据历史接收的所述同步包携带的同步请求，更新游戏数据后生成的响应包；

将查询到的响应包发送至所述游戏客户端。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。