CN115529354A - 一种资源处理方法、装置、设备及存储介质 - Google Patents

Abstract

本公开关于一种资源处理方法、装置、设备及存储介质，涉及计算机技术领域，可以降低服务端的资源。该资源处理方法包括：获取并存储第一时间段的游戏增量资源；接收第一客户端在第一时刻发送的请求消息；第一时刻位于第一时间段之后；请求消息用于请求更新游戏资源；响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。

Description

一种资源处理方法、装置、设备及存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种资源处理方法、装置、设备及存储介质。

背景技术

目前，随着用户对电子设备的使用率逐渐提高，电子设备中的游戏也越来越多。

用户在使用游戏服务时，游戏对应的服务端和客户端之间存在的大量的数据交互。相关技术中，为了保证这些游戏数据的一致性，服务端和客户端之间通常基于长连接的通信协议(例如全双工通信(WebSocket)协议等)进行数据传输。

然而，在数据量较大的情况下，服务端和客户端之间基于长连接的通信协议会占用大量的服务端的资源，成本高且不易维护。

发明内容

本公开提供一种资源处理方法、装置、设备及存储介质，可以降低服务端的资源的占用率。

本公开实施例的技术方案如下：

根据本公开实施例的第一方面，提供一种资源处理方法，该方法可以应用于服务端。该方法可以包括：获取并存储第一时间段的游戏增量资源；接收第一客户端在第一时刻发送的请求消息；第一时刻位于第一时间段之后；请求消息用于请求更新游戏资源；响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。

可选地，接收第一客户端在第一时刻发送的请求消息之前，还包括：接收第一客户端在第二时刻发送的查询消息；第二时刻位于第一时间段之后，且位于第一时刻之前；当第三时刻存储的游戏增量资源与第二时刻存储的游戏增量资源不同时，向第一客户端发送响应消息；响应消息用于表示第三时刻存储的游戏增量资源已更新；第三时刻位于第一时间段之前。

可选地，该资源处理方法还包括：周期性的接收第一客户端发送的查询消息。

可选地，获取并存储第一时间段的游戏增量资源，包括：接收第二客户端在第一时间段内的任意时刻发送的助力信息；助力信息为第二客户端响应于第一客户端发送的助力请求生成的；响应于助力信息，生成并存储第一时间段的游戏增量资源。

可选地，存储第一时间段的游戏增量资源，包括：以第一时间段为标识，存储第一时间段的游戏增量资源。

可选地，该资源处理方法还包括：接收第一客户端在第四时刻发送的游戏退出消息；获取并存储游戏资源在第四时刻的资源信息，和游戏资源在第二时间段的变化信息；第二时间段位于第四时刻之后；资源信息包括：游戏资源的数量和状态；变化信息包括：游戏资源的变化量和变化状态；接收第一客户端在第五时刻发送的游戏登录消息；第五时刻位于第二时间段之后；根据游戏资源在第四时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在第五时刻的资源信息。

根据本公开实施例的第二方面，提供一种资源处理装置，该方法可以应用服务端，包括：获取单元，接收单元和发送单元；获取单元，用于获取并存储第一时间段的游戏增量资源；接收单元，用于接收第一客户端在第一时刻发送的请求消息；第一时刻位于第一时间段之后；请求消息用于请求更新游戏资源；发送单元，用于响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。

可选地，接收单元，还用于接收第一客户端在第二时刻发送的查询消息；第二时刻位于第一时间段之后，且位于第一时刻之前；发送单元，还用于当第三时刻存储的游戏增量资源与第二时刻存储的游戏增量资源不同时，向第一客户端发送响应消息；响应消息用于表示第三时刻存储的游戏增量资源已更新；第三时刻位于第一时间段之前。

可选地，接收单元，还用于周期性的接收第一客户端发送的查询消息。

可选地，获取单元，具体用于：接收第二客户端在第一时间段内的任意时刻发送的助力信息；助力信息为第二客户端响应于第一客户端发送的助力请求生成的；响应于助力信息，生成并存储第一时间段的游戏增量资源。

可选地，获取单元，具体用于：以第一时间段为标识，存储第一时间段的游戏增量资源。

可选地，该资源处理装置还包括：处理单元；接收单元，还用于接收第一客户端在第四时刻发送的游戏退出消息；获取单元，还用于获取并存储游戏资源在第四时刻的资源信息，和游戏资源在第二时间段的变化信息；第二时间段位于第四时刻之后；资源信息包括：游戏资源的数量和状态；变化信息包括：游戏资源的变化量和变化状态；接收单元，还用于接收第一客户端在第五时刻发送的游戏登录消息；第五时刻位于第二时间段之后；处理单元，用于根据游戏资源在第四时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在第五时刻的资源信息。

根据本公开实施例的第三方面，提供一种电子设备，可以包括：处理器和用于存储处理器可执行指令的存储器；其中，处理器被配置为执行所述指令，以实现上述第一方面中任一种可选地资源处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，计算机可读存储介质上存储有指令，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行上述第一方面中任一种可选地资源处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，该计算机程序产品包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如第一方面中任一种可选地实现方式所述的资源处理方法。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

本公开的实施例提供的技术方案至少带来以下有益效果：

基于上述任一方面，本公开中，服务端在获取第一时间段的游戏增量资源后，可以先存储第一时间段的游戏增量资源。接着，服务端可以在接收第一客户端在第一时刻(位于第一时间段之后)发送的请求消息(用于请求更新游戏资源)后，再响应于该请求消息，向第一客户端发送第一时间段的游戏增量资源。这样一来，服务端无需与客户端保持长连接，也无需在获取到游戏增量资源后实时的向第一客户端发送该游戏增量资源，而是在接收到请求消息后，才向第一客户端发送第一时间段的游戏增量资源。相比通用技术，本公开对于实时性要求较低的游戏，可以降低服务端的资源占有量，进而降低服务端的机器成本和维护成本，提高了服务端的开发效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1示出了本公开实施例提供的一种相关技术中的资源处理系统的流程示意图；

图2示出了本公开实施例提供的一种资源处理系统的结构示意图；

图3示出了本公开实施例提供的一种资源处理方法的流程示意图；

图4示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图5示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图6示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图7示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图8示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图9示出了本公开实施例提供的又一种资源处理方法的流程示意图；

图10示出了本公开实施例提供的一种资源处理装置的结构示意图；

图11示出了本公开实施例提供的一种终端的结构示意图；

图12示出了本公开实施例提供的一种服务器的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

还应当理解的是，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素和/或组件的存在或添加。

本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据。

通用技术中，用户在使用游戏服务时，游戏对应的服务端和客户端之间存在的大量的数据交互。相关技术中，为了保证这些游戏数据的一致性，服务端和客户端之间通常基于长连接的通信协议(例如全双工通信(WebSocket)协议等)进行数据传输。

示例性的，如图1所示，预设某塔防类的小游戏需要好友助力才能实现保护游戏成果的过程。在这种情况下，第一客户端(即用户A)可以向第二客户端(即用户A的好友用户B)发送分享链接，请求第二客户端完成助力。在接收到第一客户端发送的分享链接后，用户B可以对分享链接执行触发操作，帮助第一客户端完成助力。

接着，第二客户端响应于用户B对分享链接执行的触发操作，触发一次向服务端发送的请求消息，用于请求上报助力状态。服务端在接收到第二客户端发送的请求消息后，可以基于WebSocket协议，实时的将助力信息发送给第一客户端。

由上述描述可知，由于WebSocket协议为长连接的通信协议，因此，服务端与第一客户端之间需要实时的保持通信连接。在数据量较大的情况下，服务端和客户端之间基于长连接的通信协议会占用大量的服务端的资源，成本高且不易维护。

基于此，本公开实施例提供一种资源处理方法，服务端在获取第一时间段的游戏增量资源后，可以先存储第一时间段的游戏增量资源。接着，服务端可以在接收第一客户端在第一时刻(位于第一时间段之后)发送的请求消息(用于请求更新游戏资源)后，再响应于该请求消息，向第一客户端发送第一时间段的游戏增量资源。这样一来，服务端无需与客户端保持长连接，也无需在获取到游戏增量资源后实时的向第一客户端发送该游戏增量资源，而是在在接收到请求消息后，才向第一客户端发送第一时间段的游戏增量资源。相比通用技术，本公开对于实时性要求较低的游戏，可以降低服务端的资源占有量，进而降低服务端的机器成本和维护成本，提高了服务端的开发效率。

图2为本公开实施例提供的一种资源处理系统示意图，如图2所示，该资源处理系统中可以包括：服务端110、第一客户端120和第二客户端130，服务端110可以通过有线网络或无线网络分别与第一客户端120和第二客户端130之间建立连接。

其中，服务端110可以是一些多媒体资源服务平台的数据服务器，可以用于存储和处理多媒体资源。例如，多媒体资源服务平台可以是短视频应用服务平台、新闻服务平台、直播服务平台、购物服务平台、外卖服务平台、共享服务平台、功能性网站等。其中，短视频应用服务平台提供的多媒体资源可以为一些短视频作品，新闻服务平台提供的多媒体资源可以为一些新闻信息，直播服务平台提供的多媒体资源可以为直播作品等，其余不再一一赘述。本公开对多媒体资源服务平台的具体类型并不作限制。

本公开中，服务端110可以是游戏资源平台对应的服务端，主要用于存储和处理游戏资源，例如：游戏增量资源等。服务端110可以在接收到第一客户端120或者第二客户端130发送的数据获取请求时，将相应的游戏资源等数据发送给第一客户端120或者第二客户端130。

一些实施例中，服务端110还可以包含有数据库或与数据库连接，多媒体资源服务平台的多媒体资源可以存储于数据库中。第一客户端120或者第二客户端130可以通过服务端110实现对数据库中多媒体资源的访问操作。

上述服务端110可以是单独的一个服务器，或者，也可以是由多个服务器构成的服务器集群。部分实施方式中，服务器集群还可以是分布式集群。本公开对服务器的具体实现方式也不作限制。

上述第一客户端120或者第二客户端130可以是手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备等可以安装并使用内容社区应用(如快手)的设备，本公开对该终端的具体形态不作特殊限制。其可以与用户通过键盘、触摸板、触摸屏、遥控器、语音交互或手写设备等一种或多种方式进行人机交互。

可选地，上述图2所示的资源处理系统中，第一客户端120或者第二客户端130可以与至少一个服务端连接，服务端110也可以与更多的客户端连接。本公开对服务端110和客户端120的数量及类型均不作限制。

为了便于理解，本申请以服务端110分别与第一客户端120和第二客户端130连接为例进行说明。

本公开实施例提供的资源处理方法可以应用于前述图2所示的应用场景中的服务端110。

下面结合附图对本公开实施例提供的资源处理方法进行详细介绍。

如图3所示，当资源处理方法应用于服务端时，该资源处理方法可以包括：

S301、服务端获取并存储第一时间段的游戏增量资源。

其中，游戏增量资源可以是游戏中变化的游戏资源，例如游戏虚拟道具资源、游戏虚拟奖励资源等。

具体的，由于服务端为游戏资源平台对应的服务端，因此，当该游戏中的游戏资源在第一时间段发生变化时，服务端可以实时获取到第一时间段的游戏增量资源。

由于相关技术中，服务端和客户端之间基于长连接的通信协议会占用大量的服务端的资源，因此，为了降低服务端的资源，服务端可以断开与客户端的长连接。在这种情况下，服务端在获取到第一时间段的游戏增量资源后，可以先存储第一时间段的游戏增量资源。

也就是说，对于实时性要求较低的游戏，服务端可以先不给客户端发送第一时间段的游戏增量资源，以降低服务端的资源。

在一种可以实现的方式中，服务端可以将第一时间段的游戏增量资源存储到游戏应用数据库(Database，DB)中，也可以存储到缓存(Cache)中，本公开对此不作限定。在实际应用中，服务端通常可以将第一时间段的游戏增量资源存储到缓存中。这样，服务端后续向第一客户端发送第一时间段的游戏增量资源时，可以从缓存中快速获取到第一时间段的游戏增量资源，并在发送第一时间段的游戏增量资源后，周期性的删除已发送的游戏增量资源，提高服务端的存储空间的利用率。

S302、服务端接收第一客户端在第一时刻发送的请求消息。

其中，第一时刻位于第一时间段之后；请求消息用于请求更新游戏资源。

在一种可以实现的方式中，第一客户端可以周期性的向服务端发送查询消息，用于请求查询服务端是否更新了游戏资源。若服务端更新了游戏资源，则可以向第一客户端发送响应消息，用于通知第一客户端更新了游戏资源。在这种情况下，第一客户端可以在第一时刻向服务端发送请求消息。相应的，服务端可以接收第一客户端在第一时刻发送的请求消息。

在又一种可以实现的方式中，第一客户端可以直接在第一时刻向服务端发送请求消息，用于请求获取更新游戏资源。若服务端更新了游戏资源，则可以直接向第一客户端发送第一时间段的游戏增量资源。若服务端未更新游戏资源，则可以向第一客户端发送提示消息，提示服务端未更新游戏资源。

S303、服务端响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。

服务端在没有长连接做数据的主动推送时，若获取到了第一时间段的游戏增量资源，并根据第一时间段的游戏增量资源更新了游戏状态的话，由于第一客户端并没有获取到第一时间段的游戏增量资源，因此，这种方法可能导致前后端(即第一客户端与服务端)的游戏状态不一致，降低了用户体验。

本公开中，第一客户端可以在第一时间段之后的第一时刻向服务端发送请求消息。该请求消息用于请求更新游戏资源，即用于请求获取第一时间段的游戏增量资源。这样，对于实时性要求较低的游戏，服务端可以在接收到第一客户端在第一时刻发送的请求消息后，才响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。后续，第一客户端在接收到第一时间段的游戏增量资源后，服务端和第一客户端可以同时更新游戏状态，从而保证前后端(即第一客户端与服务端)的游戏状态一致，提高了用户体验。

在一种可以实现的方式中，第一客户端在接收到第一时间段的游戏增量资源后，还可以向服务端再次发起一次请求消息，请求使用游戏增量资源。后续，服务端响应成功后，服务端和第一客户端同时更新游戏状态。

在一种示例中，预设某塔防类的小游戏需要好友助力才能实现保护游戏成果的过程。在好友助力成功的情况下，第一客户端可以显示“守卫”的游戏道具资源，从而保护游戏成果。

在该游戏进行的过程中，用户A(即第一客户端)可以分享链接给用户B(即第二客户端)，用户B打开分享链接并为用户A助力后，服务端最先感知到用户A添加了一个“守卫”(即游戏增量资源)。

假如此时服务端将该“守卫”添加到该游戏中，由于第一客户端并没有获取到该“守卫”的游戏增量资源，并且服务端也不知道第一客户端什么时候可以获取到该“守卫”的游戏增量资源，所以这种方式会导致前后端(即第一客户端与服务端)的游戏状态的不一致。当用户A退出游戏页面重新进入或者刷新游戏页面后，第一客户端会出现页面上的元素出现跳变的情况。

本公开中，结合该游戏的场景(即实时性要求较低的游戏场景)，本公开提供的资源处理方法可以弱化该游戏的实时性。即当服务端感知到用户A新增了“守卫”这一游戏增量资源后，不会立即将该“守卫”这一游戏增量资源更新到游戏中，而是在接收到第一客户端发送的请求消息后，向第一客户端发送“守卫”这一游戏增量资源，并同步等待第一客户端的游戏更新结果。后续，服务端可以根据游戏更新结果，前后端(即第一客户端与服务端)各自开始重新模拟当前的游戏状态，从而达到游戏数据的一致性。

上述实施例提供的技术方案至少带来以下有益效果：由S301-S303可知，服务端在获取第一时间段的游戏增量资源后，可以先存储第一时间段的游戏增量资源。接着，服务端可以在接收第一客户端在第一时刻(位于第一时间段之后)发送的请求消息(用于请求更新游戏资源)后，再响应于该请求消息，向第一客户端发送第一时间段的游戏增量资源。这样一来，服务端无需与客户端保持长连接，也无需在获取到游戏增量资源后实时的向第一客户端发送该游戏增量资源，而是在在接收到请求消息后，才向第一客户端发送第一时间段的游戏增量资源。相比通用技术，本公开对于实时性要求较低的游戏，可以降低服务端的资源占有量，进而降低服务端的机器成本和维护成本，提高了服务端的开发效率。

在一种实施例中，结合图3，如图4所示，服务端接收第一客户端在第一时刻发送的请求消息之前，还包括：

S401、服务端接收第一客户端在第二时刻发送的查询消息。

其中，第二时刻位于第一时间段之后，且位于第一时刻之前。

具体的，为了提前确定服务端是否更新了游戏资源，第一客户端可以在第二时刻向服务端发送查询消息，用于请求查询服务端是否更新了游戏资源。相应的，服务端接收第一客户端在第二时刻发送的查询消息。

由于查询消息仅仅用于请求查询服务端是否更新了游戏资源，因此，查询消息的消息内容和资源占用率极低。通过查询消息可以准确的确定服务端是否更新了游戏资源。

在一些实施例中，该资源处理方法还包括：

服务端周期性的接收第一客户端发送的查询消息。

具体的，为了保证第一客户端能及时获取到游戏增量信息，第一客户端可以周期性的向服务端发送查询消息，即通过轮询的方式查询服务端是否更新了游戏增量资源，从而保证能够及时的获取到游戏增量信息。相应的，服务端可以周期性的接收第一客户端发送的查询消息。

在一种可以实现的方式中，上述周期可以是1分钟，也可以是5分钟，本公开对此不作限定。

在一些实施例中，上述第二时刻可以是某个周期下，服务端接收第一客户端发送查询消息的时刻。

S402、当第三时刻存储的游戏增量资源与第二时刻存储的游戏增量资源不同时，服务端向第一客户端发送响应消息。

其中，响应消息用于表示第三时刻存储的游戏增量资源已更新；第三时刻位于第一时间段之前。

具体的，服务端可以实时的获取到游戏增量资源，并存储该游戏增量资源。

在一种可以实现的方式中，当服务端接收到第一客户端上一次发送的请求消息后，服务端可以将上个时间段存储的游戏增量资源发送给第一客户端，并将数据库中的上个时间段存储的游戏增量资源删除。接着，当服务端接收第一客户端在当前时刻发送的查询消息后，服务端可以先确定：将数据库中的上个时间段存储的游戏增量资源删除后，是否有新的游戏增量资源。若有，则服务端向第一客户端发送响应消息。若无，则服务端向第一客户端发送提示消息，提示游戏增量资源未更新。

在一种可以实现的方式中，下述时间概念的先后顺序依次为：第三时间段、第三时刻、第一时间段、第二时刻、第一时刻。

在第三时刻时，服务端可以响应于第一客户端发送的第一个周期下的请求消息，将第三时间段存储的游戏增量资源发送给第一客户端，并将数据库中的第三时间段存储的游戏增量资源删除。接着，服务端可以获取到第一时间段的游戏增量资源。然后，当服务端接收第一客户端在第二时刻发送的查询消息后，服务端可以确定第三时刻存储的游戏增量资源与第二时刻存储的游戏增量资源不同(即服务端新获取到了第一时间段的游戏增量资源)。在这种情况下，服务端可以向第一客户端发送响应消息。后续，第一客户端可以在第一时刻向服务端发送第二个请求消息。相应的，服务端可以响应于第一客户端发送的第二个周期下的请求消息，向第一客户端发送第一时间段的游戏增量资源。

需要说明的是，每个时间段的时间长度可以是相同的，也可以是不同的，本公开对此不作限定。

在实际应用中，上述第一时间段和第三时间段一般为相邻的两个周期。该周期为服务端获取游戏增量资源的周期。

示例性的，预设第三时间段为2021年10月1日12:00-2021年10月1日12:10。第三时刻为2021年10月1日12:15。第一时间段为2021年10月1日12:20-2021年10月1日12:30。第二时刻为2021年10月1日12:35。第一时刻为2021年10月1日12:40。

在2021年10月1日12:15时，服务端可以将2021年10月1日12:00-2021年10月1日12:10存储的游戏增量资源发送给第一客户端，并将数据库中的存储的2021年10月1日12:00-2021年10月1日12:10游戏增量资源删除。

接着，服务端可以获取到第一时间段的游戏增量资源。然后，当服务端接收第一客户端在2021年10月1日12:35发送的查询消息后，服务端可以确定2021年10月1日12:15存储的游戏增量资源与2021年10月1日12:35存储的游戏增量资源不同(即服务端新获取到了2021年10月1日12:20-2021年10月1日12:30的游戏增量资源)。

在这种情况下，服务端可以向第一客户端发送响应消息。后续，第一客户端可以在2021年10月1日12:40向服务端发送请求消息。相应的，服务端可以响应于请求消息，向第一客户端发送2021年10月1日12:20-2021年10月1日12:30的游戏增量资源。

上述实施例提供的技术方案至少带来以下有益效果：由S401-S402可知，第一客户端可以在请求获取游戏增量资源之前，先向服务端发送查询消息，从而确定服务端是否有新更新的游戏增量资源。服务端在确定有新更新的游戏增量资源后，可以向第一客户端发送响应消息，提醒第一客户端存储的游戏增量资源已更新，从而保证了第一客户端可以及时的获取到游戏增量资源。

在一种实施例中，结合图4，如图5所示，上述S301中，服务端获取并存储第一时间段的游戏增量资源的方法具体包括：

S501、服务端接收第二客户端在第一时间段内的任意时刻发送的助力信息。

其中，助力信息为第二客户端响应于第一客户端发送的助力请求生成的。

具体的，对于某些实时性要求较低的游戏，通常需要好友助力才能实现保护游戏成果的过程。在这种情况下，第一客户端可以向第二客户端发送助力请求，请求第二客户端完成助力。在接收到第一客户端发送的助力请求后，第二客户端可以在第一时间段内的任意时刻响应于第一客户端发送的助力请求，生成助力信息，并向服务端发送该助力信息。相应的，服务端可以接收第二客户端在第一时间段内的任意时刻发送的助力信息。

S502、服务端响应于助力信息，生成并存储第一时间段的游戏增量资源。

在一种示例中，预设某塔防类的小游戏需要好友助力才能实现保护游戏成果的过程。在好友助力成功的情况下，第一客户端可以显示“守卫”的游戏道具资源，从而保护游戏成果。

在该游戏进行的过程中，用户A(即第一客户端)可以向用户B(即第二客户端)发送分享链接(即助力请求)，用户B打开分享链接并为用户A助力后，可以生成助力信息，并向服务端发送该助力信息。相应的，服务端可以接收第二客户端发送的助力信息，并响应于助力信息，生成并存储“守卫”的游戏道具资源(即游戏增量资源)。

上述实施例提供的技术方案至少带来以下有益效果：由S501-S502可知，给出了一种服务端生成并存储第一时间段的游戏增量资源的具体实现方式，以便于后续在接收到请求消息后，才向第一客户端发送第一时间段的游戏增量资源，无需保持实时的长连接，对于实时性要求较低的游戏，可以降低服务端的资源占有量，进而降低服务端的机器成本和维护成本，提高了服务端的开发效率。

在一种可以实现的示例中，结合图5，如图6所示，上述S502中，服务端存储所述第一时间段的游戏增量资源的方法具体包括：

S601、服务端以第一时间段为标识，存储第一时间段的游戏增量资源。

具体的，服务端中可能存储有大量的游戏增量资源。在这种情况下，服务端可以以第一时间段为标识，存储第一时间段的游戏增量资源。这样，服务端可以通过时间段的标识，区分不同的游戏增量资源。

在一种可以实现的方式中，服务端可以以键值(Key Value，KV)的形式存储第一时间段的游戏增量资源。在这种情况下，第一时间段的游戏增量资源键即为第一时间段，值即为第一时间段的游戏增量资源。

在一种可以实现的方式中，服务端在获取到第一时间段的游戏增量资源后，若当前时刻的游戏增量资源的资源量较小，或者网络资源的可用率较高时，服务端可以将获取到的第一时间段的游戏增量资源同步存储到数据库或者缓存中。

在又一种可以实现的方式中，服务端在获取到第一时间段的游戏增量资源后，若当前时刻的游戏增量资源的资源量较大，或者网络资源的可用率较低时，服务端可以将获取到的第一时间段的游戏增量资源先存储到一个单独的存储平台中。后续，待网络资源的可用率较高时，服务端再异步的从存储平台中获取第一时间段的游戏增量资源，并将获取到的第一时间段的游戏增量资源存储到数据库或者缓存中。

在又一种可以实现的方式中，服务端还可以针对当前的业务场景、存储所述第一时间段的游戏增量资源的存储方式、当前的网络流量等因素，以其他的唯一标识(例如存储空间的版本号等)，存储第一时间段的游戏增量资源，本公开对此不作限定。

上述实施例提供的技术方案至少带来以下有益效果：由S601可知，当游戏增量资源的数量较多时，为了区分开不同时间段的游戏增量资源，服务端可以以第一时间段为标识，存储第一时间段的游戏增量资源，以便于后续准确的向第一客户端发送第一时间段的游戏增量资源。

在一种可以实现的示例中，如图7所示，预设某塔防类的小游戏需要好友助力才能实现保护游戏成果的过程。在好友助力成功的情况下，第一客户端可以显示“守卫”的游戏道具资源，从而保护游戏成果。

在该游戏进行的过程中，用户A(即第一客户端)可以向用户B(即第二客户端)发送分享链接(即助力请求)，用户B打开分享链接并为用户A助力后，可以生成助力信息，并通过服务端提供的助力接口，向服务端发送该助力信息。

相应的，服务端可以接收用户B发送的助力信息，并响应于助力信息，生成并存储“守卫”的游戏道具资源(即游戏增量资源)。

服务端存储“守卫”的游戏道具资源(即游戏增量资源)时，若当前时刻的网络资源的可用率较高时，服务端可以将获取到的“守卫”的游戏道具资源(即游戏增量资源)同步存储到关系型数据库管理系统(MySQL)中。

若当前时刻的网络资源的可用率较低时，服务端可以将获取到的“守卫”的游戏道具资源(即游戏增量资源)先存储到一个单独的存储平台中。后续，待网络资源的可用率较高时，服务端再异步的从存储平台中获取“守卫”的游戏道具资源(即游戏增量资源)，并将获取到的“守卫”的游戏道具资源(即游戏增量资源)存储到MySQL中。

接着，第一客户端可以通过服务端提供的助力接口，向服务端周期性的发送查询消息。服务端可以调用存储“守卫”的游戏道具资源的MySQL中的缓存(cache)模块，查询二进制日志(binlog)，并根据binlog确定MySQL中是否包含新更新的“守卫”的游戏道具资源。

若MySQL中包含新更新的“守卫”的游戏道具资源，则服务端可以向第一客户端返回响应消息。后续，第一客户端可以向服务端发送提交使用新增的“守卫”的游戏道具资源的请求消息。相应的，服务端响应于该请求消息，向第一客户端发送“守卫”的游戏道具资源。接着，服务端和第一客户端各自开始重新模拟当前的游戏状态，从而达到游戏数据的一致性。

在一种实施例中，如图8所示，该资源处理方法还包括：

S801、服务端接收第一客户端在第四时刻发送的游戏退出消息。

具体的，对于用户使用游戏业务的体验而言，若想要提高用户的游戏体验，需要时刻保持游戏状态的逻辑变化。

示例性的，若使用第一客户端的用户在第四时刻退出了游戏，虽然第一客户端无需更新游戏资源(因为第一客户端已经退出了游戏界面)，但是服务端需要保证游戏内的资源或者元素应该按照预设的逻辑继续变更(例如用户离线时也自动恢复游戏体力，或者自动增加游戏道具数量等)。同时，当用户在第五时刻重新登录游戏时，也不会出现跳变(即第五时刻的游戏资源是第四时刻之前的游戏资源)的情况。

在这种情况下，当使用第一客户端的用户在第四时刻退出游戏时，第一客户端可以在第四时刻向服务端发送游戏退出消息。相应的，服务端接收第一客户端在第四时刻发送的游戏退出消息。

S802、服务端获取并存储游戏资源在第四时刻的资源信息，和游戏资源在第二时间段的变化信息。

其中，第二时间段位于第四时刻之后；资源信息包括：游戏资源的数量和状态；变化信息包括：游戏资源的变化量和变化状态。

在一种可以实现的方式中，游戏资源的状态可以是该游戏的战斗结束状态，例如战斗胜利或者战斗失败。

若第二时间段中包括多个战斗回合，则游戏资源的变化状态可以是多个战斗回合中，每次战斗结束后，游戏资源中随着战斗结束进行变化的游戏资源的状态。

在一种可以实现的方式中，游戏资源的变化量表示游戏资源在第二时间段的累积变化量。游戏资源的变化规则一般是游戏中设定的，例如按照时间线性增加或非线性增加等。根据不同的规则，计算游戏资源的方式也可能不同，本公开对此不做具体限定。

在一种可以实现的方式中，游戏资源的数量可以是某些游戏道具的数量。相应的，游戏资源的变化量则可以是游戏中设定的具有自增或自减属性的游戏道具的变化量，其数量随时间自动发生变化。

示例性的，每经过一分钟给用户增加一些游戏金币、每经过一天增加用户好友列表中好友的友好度等。

此外，游戏资源的变化可以发生在玩家在线状态，也可以发生在玩家离线状态，还可以发生在包含在用户在线和离线两种状态的时间段内，因此，在游戏资源的上一次更新时间到当前时间的时间段内，用户可以处于在线状态或离线状态。

S803、服务端接收第一客户端在第五时刻发送的游戏登录消息。

其中，第五时刻位于第二时间段之后。

S804、服务端根据游戏资源在第四时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在第五时刻的资源信息。

具体的，在接收第一客户端在第五时刻发送的游戏登录消息后，为了保证用户的游戏体验，服务端可以根据游戏资源在第四时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在第五时刻的资源信息。

上述实施例提供的技术方案至少带来以下有益效果：由上述S801-S804可知，用户在退出游戏后，服务端可以获取用户退出时刻的资源信息以及用户未登陆时间段内的变化信息，以便于用户在下次登陆游戏后，服务端可以快速的向客户端发送变化后的资源信息，丰富了用户体验。

在一种可以实现的示例中，如图9所示，第一客户端在T0时刻首次登陆游戏后，服务端可以向第一客户端发送初始化的游戏资源，其中包括：“道具”资源、“守卫”资源和“金币”资源。接着，第一客户端可以响应于用户的游戏操作，获取“金币”资源和“守卫”资源等游戏资源。该游戏系统也会定期的下发游戏任务，例如“年兽袭击”等。

随着时间的变化，服务端可以维护一个基于时间线的衰减策略：f(x)＝f(t)。

其中，t为时刻，x为游戏资源。

示例性的，每次“年兽袭击”可以使得用户丢失一定数量的“金币”资源。该衰减策略可以提高用户对该游戏的依赖性，进而提高游戏的可玩度。

接着，当用户在T1时刻退出游戏时，第一客户端可以向服务端发送游戏退出消息。相应的，服务端接收第一客户端在T1时刻发送的游戏退出消息。接着，服务端获取并存储游戏资源在T1时刻的资源信息，和游戏资源在第二时间段(T1时刻到T2时刻的时间段)的变化信息。

其中，该资源信息包括该游戏在T1时刻的“道具”资源、“守卫”资源和“金币”资源等游戏资源的数量，以及T1时刻，“年兽袭击”任务的战斗状态。第二时间段的变化信息包括：该游戏在第二时间段的“道具”资源、“守卫”资源和“金币”资源等游戏资源的变化量，以及每次“年兽袭击”任务后，该游戏的战斗变化状态和战斗结束后的结算时间。

后续，当用户在T2时刻登录游戏时，第一客户端可以向服务端发送游戏登录消息。相应的，服务端接收第一客户端在第五时刻发送的游戏登录消息。接着，服务端根据游戏资源在T1时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在T2时刻的资源信息，包括：该游戏在T1时刻的“道具”资源、“守卫”资源和“金币”资源等游戏资源的数量。

可以理解的，在实际实施时，本公开实施例所述的终端/服务器可以包含有用于实现前述对应资源处理方法的一个或多个硬件结构和/或软件模块，这些执行硬件结构和/或软件模块可以构成一个电子设备。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本公开能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

基于这样的理解，本公开实施例还对应提供一种资源处理装置，可以应用于服务端。图10示出了本公开实施例提供的资源处理装置的结构示意图。如图10所示，该资源处理装置可以包括：获取单元1001，接收单元1002和发送单元1003；

获取单元1001，用于获取并存储第一时间段的游戏增量资源；

接收单元1002，用于接收第一客户端在第一时刻发送的请求消息；第一时刻位于第一时间段之后；请求消息用于请求更新游戏资源；

发送单元1003，用于响应于请求消息，向第一客户端发送第一时间段的游戏增量资源。

可选地，接收单元1002，还用于接收第一客户端在第二时刻发送的查询消息；第二时刻位于第一时间段之后，且位于第一时刻之前；

发送单元1003，还用于当第三时刻存储的游戏增量资源与第二时刻存储的游戏增量资源不同时，向第一客户端发送响应消息；响应消息用于表示第三时刻存储的游戏增量资源已更新；第三时刻位于第一时间段之前。

可选地，接收单元1002，还用于周期性的接收第一客户端发送的查询消息。

可选地，获取单元1001，具体用于：

接收第二客户端在第一时间段内的任意时刻发送的助力信息；助力信息为第二客户端响应于第一客户端发送的助力请求生成的；

响应于助力信息，生成并存储第一时间段的游戏增量资源。

可选地，获取单元1001，具体用于：

以第一时间段为标识，存储第一时间段的游戏增量资源。

可选地，资源处理装置还包括：处理单元1004；

接收单元1002，还用于接收第一客户端在第四时刻发送的游戏退出消息；

获取单元1001，还用于获取并存储游戏资源在第四时刻的资源信息，和游戏资源在第二时间段的变化信息；第二时间段位于第四时刻之后；资源信息包括：游戏资源的数量和状态；变化信息包括：游戏资源的变化量和变化状态；

接收单元1002，还用于接收第一客户端在第五时刻发送的游戏登录消息；第五时刻位于第二时间段之后；

处理单元1004，用于根据游戏资源在第四时刻的资源信息和游戏资源在第二时间段的变化信息，更新游戏资源在第五时刻的资源信息。

如上所述，本公开实施例可以根据上述方法示例对服务端进行功能模块的划分。其中，上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。另外，还需要说明的是，本公开实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。

关于上述实施例中的资源处理装置，其中各个模块执行操作的具体方式、以及具备的有益效果，均已经在前述方法实施例中进行了详细描述，此处不再赘述。

本公开实施例还提供一种终端，终端可以是手机、电脑等用户终端。图11示出了本公开实施例提供的终端的结构示意图。该终端可以是资源处理装置可以包括至少一个处理器61，通信总线62，存储器63以及至少一个通信接口64。

处理器61可以是一个处理器(central processing units，CPU)，微处理单元，ASIC，或一个或多个用于控制本公开方案程序执行的集成电路。

通信总线62可包括一通路，在上述组件之间传送信息。

通信接口64，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如服务器、以太网，无线接入网(radio access network，RAN)，无线局域网(wireless localarea networks，WLAN)等。

存储器63可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理单元相连接。存储器也可以和处理单元集成在一起。

其中，存储器63用于存储执行本公开方案的应用程序代码，并由处理器61来控制执行。处理器61用于执行存储器63中存储的应用程序代码，从而实现本公开方法中的功能。

在具体实现中，作为一种实施例，处理器61可以包括一个或多个CPU，例如图11中的CPU0和CPU1。

在具体实现中，作为一种实施例，终端可以包括多个处理器，例如图11中的处理器61和处理器65。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，终端还可以包括输入设备66和输出设备67。输入设备66和输出设备67通信，可以以多种方式接受用户的输入。例如，输入设备66可以是鼠标、键盘、触摸屏设备或传感设备等。输出设备67和处理器61通信，可以以多种方式来显示信息。例如，输出设备61可以是液晶显示器(liquid crystal display，LCD)，发光二级管(light emitting diode，LED)显示设备等。

本领域技术人员可以理解，图11中示出的结构并不构成对终端的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本公开实施例还提供一种服务器。图12示出了本公开实施例提供的服务器的结构示意图。该服务器可以是资源处理装置。该服务器可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器71和一个或一个以上的存储器72。其中，存储器72中存储有至少一条指令，至少一条指令由处理器71加载并执行以实现上述各个方法实施例提供的资源处理方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。

本公开还提供了一种包括指令的计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述计算机可读存储介质中的指令由计算机设备的处理器执行时，使得计算机能够执行上述所示实施例提供的资源处理方法。例如，计算机可读存储介质可以为包括指令的存储器63，上述指令可由终端的处理器61执行以完成上述方法。又例如，计算机可读存储介质可以为包括指令的存储器72，上述指令可由服务器的处理器71执行以完成上述方法。可选地，计算机可读存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、RAM、CD-ROM、磁带、软盘和光数据存储设备等。

本公开还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行上述图1-图9任一附图所示的资源处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种资源处理方法，其特征在于，包括：

获取并存储第一时间段的游戏增量资源；

接收第一客户端在第一时刻发送的请求消息；所述第一时刻位于所述第一时间段之后；所述请求消息用于请求更新游戏资源；

响应于所述请求消息，向所述第一客户端发送所述第一时间段的游戏增量资源。

2.根据权利要求1所述的资源处理方法，其特征在于，所述接收第一客户端在第一时刻发送的请求消息之前，还包括：

接收所述第一客户端在第二时刻发送的查询消息；所述第二时刻位于所述第一时间段之后，且位于所述第一时刻之前；

当第三时刻存储的游戏增量资源与所述第二时刻存储的游戏增量资源不同时，向所述第一客户端发送响应消息；所述响应消息用于表示所述第三时刻存储的游戏增量资源已更新；所述第三时刻位于所述第一时间段之前。

3.根据权利要求2所述的资源处理方法，其特征在于，还包括：

周期性的接收所述第一客户端发送的所述查询消息。

4.根据权利要求1所述的资源处理方法，其特征在于，所述获取并存储第一时间段的游戏增量资源，包括：

接收第二客户端在所述第一时间段内的任意时刻发送的助力信息；所述助力信息为所述第二客户端响应于所述第一客户端发送的助力请求生成的；

响应于所述助力信息，生成并存储所述第一时间段的游戏增量资源。

5.根据权利要求1所述的资源处理方法，其特征在于，所述存储所述第一时间段的游戏增量资源，包括：

以所述第一时间段为标识，存储所述第一时间段的游戏增量资源。

6.根据权利要求1-5任一项所述的资源处理方法，其特征在于，还包括：

接收所述第一客户端在第四时刻发送的游戏退出消息；

获取并存储所述游戏资源在所述第四时刻的资源信息，和所述游戏资源在第二时间段的变化信息；所述第二时间段位于所述第四时刻之后；所述资源信息包括：所述游戏资源的数量和状态；所述变化信息包括：所述游戏资源的变化量和变化状态；

接收所述第一客户端在第五时刻发送的游戏登录消息；所述第五时刻位于所述第二时间段之后；

根据所述游戏资源在所述第四时刻的资源信息和所述游戏资源在所述第二时间段的变化信息，更新所述游戏资源在所述第五时刻的资源信息。

7.一种资源处理装置，其特征在于，包括：获取单元，接收单元和发送单元；

所述获取单元，用于获取并存储第一时间段的游戏增量资源；

所述接收单元，用于接收第一客户端在第一时刻发送的请求消息；所述第一时刻位于所述第一时间段之后；所述请求消息用于请求更新游戏资源；

所述发送单元，用于响应于所述请求消息，向所述第一客户端发送所述第一时间段的游戏增量资源。

8.根据权利要求7所述的资源处理装置，其特征在于，

所述接收单元，还用于接收所述第一客户端在第二时刻发送的查询消息；所述第二时刻位于所述第一时间段之后，且位于所述第一时刻之前；

所述发送单元，还用于当第三时刻存储的游戏增量资源与所述第二时刻存储的游戏增量资源不同时，向所述第一客户端发送响应消息；所述响应消息用于表示所述第三时刻存储的游戏增量资源已更新；所述第三时刻位于所述第一时间段之前。

9.一种电子设备，其特征在于，所述电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1-6中任一项所述的资源处理方法。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1-6中任一项所述的资源处理方法。

Images