发明内容
有鉴于此,本申请实施例至少提供一种虚拟资源处理方法及装置。
第一方面,本申请实施例提供了一种虚拟资源的处理方法,所述处理方法应用于服务器,所述服务器的内存数据库中预先存储有多个用户的余额信息;所述方法包括:
响应预设处理条件的触发,基于目标时段从内存数据库中读取目标余额信息;其中,所述目标余额信息包括:用户身份标识、以及所述目标时段对应的虚拟资源余额;
基于所述目标余额信息中的虚拟资源余额、以及所述用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
一种可能的实施方式中,根据以下步骤存储所述目标余额信息:
响应用户的操作行为,为用户分配与所述操作行为对应的虚拟资源;
基于为所述用户分配的所述虚拟资源,更新与所述用户对应的虚拟资源余额,并基于更新后的虚拟资源余额、以及所述操作行为的行为时间,更新所述内存数据库中所述用户在所述行为时间所属时段的余额信息。
一种可能的实施方式中,所述基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,还包括:
基于所述虚拟资源处理的结果,更新与用户身份标识对应的虚拟资源余额;
基于更新后的所述虚拟资源余额,更新内存数据库中所述用户在晚于所述目标时段的其他时段的余额信息。
一种可能的实施方式中,所述索引信息中还包括:索引信息;
所述基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理,包括:
基于多个所述目标余额信息中每个目标余额信息的索引信息,将所述多个目标余额信息划分至多个处理分组中;
基于所述多个处理分组中每个处理分组中目标余额信息的虚拟资源余额、以及用户身份标识,对所述多个处理分组执行虚拟资源的并行处理。
一种可能的实施方式中,采用下述方法生成所述索引信息:
基于所述用户的用户身份标识、以及预先设置的分组数量,确定分组索引;将所述分组索引与所述余额信息对应的时段进行拼接,生成所述索引信息。
一种可能的实施方式中,所述预设处理条件,包括下述至少一种:
当前时刻到达预设处理时刻;
当前不存在所述目标余额信息在所述目标时段的成功处理记录。
一种可能的实施方式中,所述基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,还包括:
基于所述目标余额信息中的用户身份标识,生成成功处理记录,并将所述成功处理记录、以及所述目标时段关联存储在目标数据库中。
一种可能的实施方式中,还包括:
响应用户进入目标页面的操作请求,检测所述操作请求中是否携带有与所述目标时段对应的成功处理标识;
若所述操作请求中并未携带所述成功处理标识,则基于用户的用户身份标识,检测所述目标数据库中是否存在与所述用户对应的所述成功处理记录;
若所述目标数据库中不存在与所述用户对应的成功处理记录,则基于用户在所述目标时段的虚拟资源余额,处理所述用户的虚拟资源。
一种可能的实施方式中,还包括:
若所述目标数据库中存在与所述用户对应的成功处理记录,则生成与所述用户对应的所述成功处理标识,并将所述成功处理标识反馈给所述用户。
第二方面,本申请实施例还提供一种虚拟资源的处理装置,所述处理装置应用于服务器;所述服务器的内存数据库中预先存储有多个用户的余额信息;所述处理装置包括:
第一响应模块,用于响应预设处理条件的触发,基于目标时段从内存数据库中读取目标余额信息;其中,所述目标余额信息包括:用户身份标识、以及所述目标时段对应的虚拟资源余额;
处理模块,用于基于所述目标余额信息中的虚拟资源余额、以及所述用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
一种可选实施方式中,还包括:生成模块,用于根据以下步骤存储所述余额信息:
响应用户的操作行为,为用户分配与所述操作行为对应的虚拟资源;
基于为所述用户分配的所述虚拟资源,更新与所述用户对应的虚拟资源余额,并基于更新后的虚拟资源余额、以及所述操作行为的行为时间,更新所述内存数据库中所述用户在所述行为时间所属时段的余额信息。
一种可选实施方式中,还包括:更新模块,用于在所述处理模块基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,基于所述虚拟资源处理的结果,更新与用户身份标识对应的虚拟资源余额;基于更新后的所述虚拟资源余额,更新内存数据库中所述用户在晚于所述目标时段的其他时段的余额信息。
一种可选实施方式中,所述目标余额信息中还包括:索引信息;
所述处理模块,在基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理时,用于:
基于多个所述目标余额信息中每个目标余额信息的索引信息,将所述多个目标余额信息划分至多个处理分组中;
基于所述多个处理分组中每个处理分组中目标余额信息的虚拟资源余额、以及用户身份标识,对所述多个处理分组执行虚拟资源的并行处理。
一种可选实施方式中,所述生成模块,用于采用下述方法生成所述索引信息:
基于所述用户的用户身份标识、以及预先设置的分组数量,确定分组索引;将所述分组索引与所述余额信息对应的时段信息进行拼接,生成所述索引信息。
一种可选实施方式中,所述预设处理条件,包括下述至少一种:
当前时刻到达预设处理时刻;
当前不存在所述目标余额信息在所述目标时段的成功处理记录。
一种可选实施方式中,还包括:记录模块,用于在所述处理模块基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,基于所述目标余额信息中的用户身份标识,生成成功处理记录,并将所述成功处理记录、以及所述目标时段关联存储在目标数据库中。
一种可选实施方式中,还包括:第二响应模块,用于:
响应用户进入目标页面的操作请求,检测所述操作请求中是否携带有与所述目标时段对应的成功处理标识;
若所述操作请求中并未携带所述成功处理标识,则基于用户的用户身份标识,检测所述目标数据库中是否存在与所述用户对应的成功处理记录;
若所述目标数据库中不存在与所述用户对应的成功处理记录,则基于用户在所述目标时段的虚拟资源余额,处理所述用户的虚拟资源。
一种可选实施方式中,所述第二响应模块,还用于:
若所述目标数据库中存在与所述用户对应的成功处理记录,则生成与所述用户对应的成功处理标识,并将所述成功处理标识反馈给所述用户。
第三方面,本申请实施例还提供一种电子设备,包括:包括:处理器、存储器,所述存储器存储有所述处理器可执行的机器可读指令,所述处理器用于执行所述存储器中存储的机器可读指令,所述机器可读指令被所述处理器执行时,所述处理器执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
第四方面,本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤。
本申请实施例通过响应预设处理条件的触发,基于处理的目标时段,从内存数据库中读取目标余额信息,然后根据目标余额信息中的虚拟资源余额以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理;在该过程中,在服务器的内存数据库中预先存储有多个用户的余额信息,从而读取目标余额信息的过程是对内存数据库的进行直接操作得到,读取速度更快,因而具有更快的处理速度和更高的处理效率。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
经研究发现,与应用程序对应的服务器通常通过关系型数据库管理***MySQL来存储用户有关虚拟资源的收益余额数据和用户收益记录;以将第一虚拟资源转换为第二虚拟资源为例,现有的将第一虚拟资源转换成第二虚拟资源的方式一般为:从用户收益记录中读取完成预设任务的用户身份标识(Identity,ID),然后将用户ID导入数据库redis缓存;处理脚本在每日零点开始执行下述处理流程:从redis中读取所有待处理的用户ID,根据读取到的用户ID从MySQL中存储的用户收益记录中查询计算用户的昨日第一虚拟资源收入总额;如果昨日第一虚拟资源收入总额大于0,则按照预设的汇率将第一虚拟资源转换为第二虚拟资源,并增加用户的收益余额数据中第二虚拟资源的数值,相应的减少收益余额数据中第一虚拟资源的数量;完成处理操作后,通过与用户ID对应的用户钱包为用户展示完成处理后的第一虚拟资源数值和第二虚拟资源数值,并在用户收益记录中增加相应的处理记录。
由于MySQL读写的每秒查询率(Queries-per-second,QPS)不能过高,该种处理方式受限于MySQL读写的每秒查寻率,若用户量过多,例如在用户量在千万级别时,很难在短时间内从MySQL读取到所有用户的用户收益记录,进而造成处理速度慢、效率低的问题。
同时,每日待处理的用户ID通过读取用户收益记录中的用户ID以导入redis缓存,将待处理用户ID的写入redis的成功率并非百分百,且基于用户ID读取待处理用户的所有用户收益记录的成功率也并非百分百,因此存在部分用户的第一虚拟资源漏处理的问题。
另外,当处理脚本运行失败后,会重新运行,这可能会导致部分用户处理多次的问题,无法保证处理脚本多次运行的数据幂等性。
基于上述研究,本申请提供了一种虚拟资源的处理方法及装置,通过响应预设处理条件的触发,基于处理的目标时段,从内存数据库中读取目标余额信息,然后根据目标余额信息中的虚拟资源余额以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理;在该过程中,在服务器的内存数据库中预先存储有多个用户的余额信息,从而读取目标余额信息的过程是对内存数据库进行操作,读取速度更快,因而具有更快的处理速度和更高的处理效率。
针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本申请针对上述问题所提出的解决方案,都应该是发明人在本申请过程中对本申请做出的贡献。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解,首先对本申请实施例所公开的一种虚拟资源的处理方法进行详细介绍,本申请实施例所提供的虚拟资源的处理方法的执行主体一般为服务器。
下面对本申请实施例提供的虚拟资源的处理方法加以说明。
参见图1所示,为本申请实施例提供的虚拟资源的处理方法的流程图,所述方法包括步骤S101~S102,其中:
S101:响应预设处理条件的触发,基于目标时段从内存数据库中读取目标余额信息;其中,所述目标余额信息包括:用户身份标识、以及所述目标时段对应的虚拟资源余额;
S102:基于所述目标余额信息中的虚拟资源余额、以及所述用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
本申请实施例通过响应预设处理条件的触发,基于处理的目标时段,从内存数据库中读取目标余额信息,然后根据目标余额信息中的虚拟资源余额以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理;在该过程中,在服务器的内存数据库中预先存储有多个用户的余额信息,从而读取目标余额信息的过程是基对内存数据库进行操作,读取速度更快,因而具有更快的处理速度和更高的处理效率。
在具体实施中,内存数据库是指将数据放在内存中直接操作的数据库。内存数据库例如包括:远程字典服务器(REmote DIctionary Server,redis)数据库、结构化查询语言类(Structured Query Language Lite,SQLite)数据库、Altibase数据库等;
以内存数据库为redis为例,余额信息例如以余额快照的形式存储在redis中;而余额快照能够以哈希数据链的数据形式存储在redis中。这样,保证了余额信息的快速读取。
在服务器的内存数据库中预先存储有多个活动用户的余额信息;其中,这里的活动用户,是指在一定时间段内执行过使得虚拟资源发生变更的操作的用户;针对在一定时间段内未执行过使得其虚拟资源发生变更的操作的用户,内存数据库中不存在该用户的余额信息;或者,内存数据库中虽然存在该用户的余额信息,但余额信息中的信息例如为空。
每个用户的余额信息包括以下信息:用户身份标识、索引信息、以及虚拟资源余额。
其中:
(1)索引信息是基于余额信息所属的时段生成的。
此处,索引信息的作用是将要进行处理的目标时段,对应的目标余额信息,从多个时段分别对应的目标余额信息中筛选出来。
一种可能的实施方式中,可以直接将余额信息所属的时段作为该余额信息的索引信息。
在另一种可能的实施方式中,还可以采用另一种方式生成余额信息的索引信息,具体参见下述实施例,在此不再赘述。
(2)用户身份标识,例如用户在注册时,服务器为用户分配的用于识别该用户的身份标识;又例如,还可以将用户的注册账号作为该用户的用户身份标识。
(3)虚拟资源余额,是指用户在余额信息多个时段分别对应的虚拟资源的余额。
示例性的,例如,在每天执行一次虚拟资源处理过程的情况下,则每一个自然日对应一个余额信息;用户在某自然日内执行过多次使得虚拟资源余额发生变更的操作,每一次操作后,服务器都会根据用户的具体操作,增加用户的虚拟资源余额,或者减少用户的虚拟资源余额;虚拟资源余额每次发生变化,服务器都会根据新的虚拟资源余额更新内存数据库中用户在该自然日的余额信息。
又例如,每隔12小时执行一次虚拟资源处理过程的情况下,则每日的0:00~12:00作为一个时段,对应一个余额信息,12:00~23:59作为一个时段,对应一个余额信息。用户在某日的0:00~12:00执行多次使得虚拟资源余额发生变更的操作,每一次操作后,服务器都会根据用户的具体操作,增加用户的虚拟资源余额,或者减少用户的虚拟资源余额;虚拟资源余额每次发生变化,服务器都会根据新的虚拟资源余额更新内存数据库中用户在该日0:00~12:00对应的余额信息。
又例如,在每周执行一次虚拟资源处理过程的情况下,用户在一周内执行过多次使得虚拟资源余额发生变更的操作,每一次操作后,服务器都会根据用户的具体操作增加用户的虚拟资源余额,或者减少用户的虚拟资源余额;虚拟资源余额每次发生变化,服务器都会根据新的虚拟资源余额更新内存数据库中用户在该周的余额信息。
另外,为了保证内存数据库中所保存的余额信息的数量不会无限增加,例如可以为每个余额信息都设置一生命周期;当任一余额信息的生命周期结束时,将该余额信息从内存数据库中删除。该生命周期的长短与对与所述虚拟资源余额对应的虚拟资源进行处理过程的周期有关;该生命周期一般比执行虚拟处理过程的周期持续时间更长。
例如,若对与所述虚拟资源余额对应的虚拟资源进行处理过程的周期为1天,则余额信息的生命周期例如为3天;若对与所述虚拟资源余额对应的虚拟资源进行处理过程的周期为1周,则余额信息的生命周期例如为2周等。具体可以根据实际的情况设定。
在本申请另一实施例中,不同余额信息的生命周期可以相同,也可以不同。
在不同余额信息的生命周期相同的情况下,例如可以周期性的遍历内存数据库中的余额信息,在遍历到某个余额信息时,若该余额信息的生命周期已经结束,则删除该余额信息;这里,遍历的周期较短,例如10分钟遍历一次、30分钟遍历一次、一小时遍历一次等。此处,可以根据余额信息的生成时间来确定余额信息的生命周期是否已经结束。
在不同余额信息的生命周期不同的情况下,例如每个余额信息生成后,都会在该余额信息生成日期后的第三天被删除;在该种情况下,也可以周期性的遍历余额信息,在遍历到某个余额信息时,检测该余额信息的生成日期,与当前时刻对应的日期之间的差值是否等于预设的天数,如果相等,则将遍历到的余额信息删除。这里,遍历的周期一般较长,例如24小时遍历一次,也即,每一天执行一次过期余额信息的统一删除,这样可以有效减少服务器的工作量,减轻对服务器的压力。
每个活动用户的余额信息至少有一个;在某活动用户有多个余额信息的情况下,多个余额信息分别对应多个不同的时段,例如该时段的时长为1个自然日,且余额信息的生存周期为72小时,若该用户在过去三个自然日的每一自然日都执行过使得虚拟资源余额发生变更的操作,则该用户的余额信息就有3个。若该用户在过去三个自然日中,只有两个自然日执行过使得虚拟资源余额发生变更的操作,则该用户的余额信息有2个;若该用户在过去的三个自然日中只有一个自然日执行过使得虚拟资源余额发生变更的操作,则该用户的余额信息为1个。
具体地,参见图2所示,本申请实施例还提供一种存储余额信息的具体方法,包括:
S201:响应用户的操作行为,为用户分配与所述操作行为对应的虚拟资源。
这里,操作行为具体可以根据实际的需要进行设定。
若操作行为为增加虚拟资源的行为,则分配给用户的虚拟资源为正值,使得用户的虚拟资源余额增加;若操作行为为减少虚拟资源的行为,则分配给用户的虚拟资源为负值,使得用户的虚拟资源余额减少。
S202:基于为所述用户分配的所述虚拟资源,更新与所述用户对应的虚拟资源余额,并基于更新后的虚拟资源余额、以及所述操作行为的行为时间,更新所述内存数据库中所述用户在所述行为时间所属时段的余额信息。
这里,若内存数据库中存储有用户在某个时段的余额信息,且用户的某个操作行为的行为时间属于该时段,则基于为所述用户分配的所述虚拟资源,更新已经存储的用户在该时段的余额信息中的虚拟资源余额。
若内存数据库中并未存储用户在某个时段的余额信息,但用户的某个操作行为的行为时间属于该时段,则基于为所述用户分配的所述虚拟资源,生成用户在该时段的余额信息。
在具体实施中,本申请实施例还提供一种生成余额信息的具体示例:
用户每完成一次操作行为,响应该次操作行为,在与该用户对应的用户收益记录表中增加一条收益记录,并在该用户对应的用户余额表中更新虚拟资源余额,并响应的产生一条与该收益记录对应的mysql-binlog记录;其中,mysql-binlog是MySQL数据库的二进制日志,用于记录用户对数据库操作的SQL语句。利用用户余额表对应的mysql-binlog记录,生成该用户的余额信息;该余额信息包括:索引信息、用户身份标识、以及虚拟资源余额value。根据该余额信息的索引信息、以及用户身份信息,从redis中查询是否已经保存有索引信息、用户身份标识一致的余额信息;若存在,则使用新生成的余额信息的虚拟资源余额,替换已经保存的余额信息中的虚拟资源余额。若不存在,则将新生成的余额信息存储到redis中。
另外,用户余额表还可以存储于卡夫卡Kafka中,其中,Kafka是一种高吞吐量的分布式发布订阅消息***,在这里的作用主要是用于binlog产生失败的时候的备选,将用户收益记录的kafka写入redis中。
下面对本申请实施例中的S101~S102加以详细说明。
I:在上述S101中,预设处理条件例如包括:当前时刻到达预设处理时刻;
示例性的,针对不同的情况可以设置不同的预设处理时刻;以每个自然日执行一次虚拟资源处理过程为例,可以将每天的00:00作为预设处理时刻,在当前时刻到达00:00时,即触发虚拟资源的处理过程;又例如,针对每周进行一次处理的情况,可以将每周一的00:05作为预设处理时刻;在当前时间到达周一的00:00时,即触发虚拟资源的处理过程;又例如,针对每月进行一次处理的情况,可以将每月一号的8:00作为预设处理时刻;在当前时间到达一号的8:00时,及触发虚拟资源的处理过程。
在本申请另一实施例中,预设处理条件还可以包括:当前不存在所述目标余额信息在所述目标时段的成功处理记录。
这里,在对任一目标余额信息对与所述虚拟资源余额对应的虚拟资源进行处理成功后,都可以生成与目标余额信息在目标时段的成功处理记录;若当前存在该成功处理记录,则不需再对其执行一次虚拟资源处理过程。
目标时段根据实际的处理周期来进行确定;目标时段例如为当前时刻对应日期的前一天。
当预设处理条件触发后,要确定处理的目标时段;然后基于目标时段,从内存数据库中读取目标余额信息。
在从内存数据库中读取目标余额信息时,例如根据目标时段生成索引关键词,然后遍历内存数据库中各个余额信息;将遍历到的余额信息的索引信息,与索引关键词进行匹配;若两者匹配成功,则将遍历到的余额信息确定为目标余额信息。
如此,通过对内存数据库中各余额信息的遍历,从目标数据库中读取到所有的目标余额信息。
II:在上述S102中,在基于目标余额信息中的虚拟资源余额、以及用户身份标识进行虚拟资源处理时,根据余额信息中的虚拟资源余额,按照一定的处理比例,将第一虚拟资源转换成另一种第二虚拟资源,然后根据用户的身份标识,为与用户身份标识对应的用户增加第二虚拟资源的量,并相应减少与用户身份标识对应的用户的虚拟资源量。
在本申请另一实施例中,在对与所述虚拟资源余额对应的虚拟资源进行处理后,还包括:
基于所述虚拟资源处理的结果,更新与用户身份标识对应的虚拟资源余额;基于更新后的所述虚拟资源余额,更新内存数据库中所述用户在晚于所述目标时段的其他时段的余额信息。
例如,当前时刻为XX年XX月25日00:05,触发了预设处理条件,并以XX年XX月24日为目标时段,对各个用户的目标余额信息对与所述虚拟资源余额对应的虚拟资源进行处理;用户甲某在为XX年XX月24日的第一余额信息为目标余额信息。
若甲某于XX年XX月25日00:04执行了使得用户资源余额发生变化的操作行为,因而在内存数据库中存储了与XX年XX月25日对应的第二余额信息;由于第二余额信息的生成时间第一余额信息对应的处理时间,因此在第二余额信息中的虚拟资源余额中,实际上包括了XX年XX月24日所产生的虚拟资源;则对第一余额信息执行了虚拟资源处理后,要更新甲某的第二余额信息中的虚拟资源余额。
在本申请另一实施例中,为了提升虚拟资源处理的速度,可以将多个用户分别对应的目标余额信息分配至不同的处理进程来并行对与所述虚拟资源余额对应的虚拟资源进行处理过程。示例性的,处理脚本在运行时可以开启一个处理进程。
在一种可能的实施方式中,例如可以随机的将多个目标余额信息分成多个分组,然后将各个分组分配至不同的处理进程;各个处理进程接收目标余额信息后,根据目标余额信息中的虚拟资源余额以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
在另一种可能的实施方式中,例如还可以按照用户的用户身份标识,将多个目标余额信息分成多个分组,然后将各个分组分配至不同的处理进程。
此处,例如可以在余额信息生成时,为每个余额信息的索引信息中增加分组索引;该分组索引基于用户身份标识生成。
例如,将用户身份标识中的末位的N位数字作为分组索引,或者将用户身份标识除以预设分片数的余数作为分组索引。
在将多个目标余额信息划分成多个分组时,遍历各个目标余额信息的分组索引,根据各个目标余额信息的分组索引,将目标余额信息划分成多个分组。其中,每个分组对应至少一个分组索引。
这里,在将目标余额信息划分成多个分组的时候,由于分组索引可以预先确定;例如若以用户身份标识的末尾两位作为分组索引,则分组索引包括:00-99的正整数。若以用户身份标识除以预设分片数的余数作为分组索引,则分组索引包括:0~N-1的正整数;其中,N为预设分片数。
因此,可以预先确定多个分组中每个分组中包括的分组索引,然后根据各个目标余额信息中的分组索引,将多个目标余额信息分成多个分组。
这里,虚拟资源处理过程例如包括:基于多个所述目标余额信息中每个目标余额信息的分组索引,将所述多个目标余额信息划分至多个处理分组中;基于所述多个处理分组中每个处理分组中目标余额信息的虚拟资源余额、以及用户身份标识,对所述多个处理分组执行虚拟资源的并行处理。
在本申请另一实施例中,还可以在从内存数据库中获取目标余额信息时,直接实现对目标余额信息的分组,该过程例如包括:
(1)根据多个分组索引中的每个分组索引,以及目标时段,生成与多个分组索引分别对应的目标索引信息。
(2)遍历内存数据库中的各个余额信息,将遍历到的余额信息的索引信息与多个目标索引信息进行匹配。
(3)将匹配成功的余额信息,确定为目标索引信息对应分组中的目标余额信息。
此处,各个余额信息中的索引信息例如采用下述方式生成:基于所述用户的用户身份标识、以及预先设置的分组数量,确定分组索引;将所述分组索引与所述余额信息对应的时段信息进行拼接,生成所述索引信息。
示例性的,例如可以将用户身份标识的数值除以分组数量的余数,作为分组索引,例如分组数量为100,则余数可能为0~99中的人一个;若某用户对应的分组索引为23,且余额信息对应的时段信息例如为:09年03月22日,则将两者进行拼接,得到的索引信息为:23090322。
在本申请另一实施例中,在对与所述虚拟资源余额对应的虚拟资源进行处理后,例如还包括:
基于所述目标余额信息中的用户身份标识,生成成功处理记录,并将所述成功处理记录、以及所述目标时段关联存储在目标数据库中。
此处,目标数据库例如包括abase数据库。
具体地,将成功处理记录以及目标时段关联存储在目标数据库中。首先方便多个处理分别进行访问;其次,将成功处理记录、以及目标时段关联存储在abase数据库中,保证abase中的信息和用户收益余额表中的信息在不对等的情况下,撤销abase中的该成功处理记录,从而将成功处理记录和存储余额信息的数据库分隔开,不会对余额信息的存储造成任何的影响。
在该种情况下,若某个处理进程在虚拟资源处理过程中出现处理失败、或者进程崩溃等影响处理过程的情况后,处理进程重启;处理进程重启后,向服务器主进程发送目标余额信息的传输指令;服务器的主进程在接收到该传输指令后,根据该重启的处理进程对应的分组,重新从内存数据库中获取该处理进程需要处理的目标余额信息。在该过程中,为了防止对同一用户发生多次处理,主进程会检测在目标数据库中是否存储有该处理进程需要处理的目标余额信息的成功处理记录;若存在该处理进程需要处理的任一目标余额信息的成功处理记录,则不再将该任一目标余额信息发送给重启的处理进程对与所述虚拟资源余额对应的虚拟资源进行处理过程。
示例性的,处理进程包括A0~A49共50个处理进程;若处理进程A33在对与所述虚拟资源余额对应的虚拟资源进行处理过程中崩溃重启,重启后的处理进程记为A33’。
若处理进程A33需要处理的目标余额信息包括b1~b1000,且在处理进程A33崩溃前,已经执行了目标余额信息b1~b500的虚拟资源处理;则A33’向服务器主进程发送目标余额信息的传输指令后,服务器的主进程从目标数据库中检测,是否存在目标余额信息b1~b1000中任一目标余额信息对应的成功处理记录;
由于A33已经执行了目标余额信息b1~b500的虚拟资源处理,因此在目标数据库中已经存储了目标余额信息b1~b500分别对应的成功处理记录。因此,目标余额信息b1~b500将不再作为A33’的虚拟资源处理目标;服务器的主进程将目标余额信息b501~b1000发送至处理进程A33’;处理进程A33’实现对目标余额信息b501~b1000的虚拟资源处理。
这样,通过上述过程,能够有效保证每个目标余额信息只被执行一次虚拟资源处理过程,进而保证了处理进程多次运行的数据幂等性。
在本申请另一实施例中,在某些情况下,可能会造成对部分用户的漏处理。因此,参见图3所示,在本申请另一实施例还提供另一种处理方法,包括:
S301:响应用户进入目标页面的操作请求,检测所述操作请求中是否携带有与所述目标时段对应的成功处理标识。
此处,成功处理标识例如是以目标时段为命名的cookie的形式保存在用户终端;当用户通过用户终端进入目标页面时,会向服务器发送统一资源定位符(UniformResource Identifier,URL)请求;在该URL请求中携带有该cookie。
这里,目标页面例如为应用程序的首页、钱包页面等。具体可以根据实际需要进行设置。
S302:若所述操作请求中并未携带所述成功处理标识,则基于用户的用户身份标识,检测所述目标数据库中是否存在与所述用户对应的所述成功处理记录。
S303:若所述目标数据库中不存在与所述用户对应的成功处理记录,则基于用户在所述目标时段的虚拟资源余额,处理所述用户的虚拟资源。
之后,例如还可以更新该用户的用户收益余额表,并将用户收益余额表中的最新第一虚拟资源余额和第二虚拟资源余额携带在页面信息中反馈给用户设备;
用户设备进入钱包页面后,在钱包页面为用户显示最新第一虚拟资源余额,和第二虚拟资源余额。
S304:若所述目标数据库中存在与所述用户对应的成功处理记录,则生成与所述用户对应的成功处理标识,并将所述成功处理标识反馈给所述用户。
这样,用户在下一次向服务器发送进入目标页面的操作请求后,该操作请求中即携带有成功处理标识。
通过上述实施例能够保证部分用户在统一的虚拟资源处理过程中被漏掉的时候,可以通过该过程实现这些被漏掉的用户的虚拟资源的兜底处理。
基于同一发明构思,本申请实施例中还提供了与虚拟资源的处理方法对应的虚拟资源的处理装置,由于本申请实施例中的装置解决问题的原理与本申请实施例上述虚拟资源的处理方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
参照图4所示,为本申请实施例提供的一种虚拟资源的处理装置的示意图,所述处理装置应用于服务器;所述服务器的内存数据库中预先存储有多个用户的余额信息;所述处理装置包括:第一响应模块41、以及处理模块42;其中:
第一响应模块41,用于响应预设处理条件的触发,基于处理的目标时段,从内存数据库中读取包括的索引信息与该目标时段匹配的目标余额信息;其中,所述目标余额信息包括:用户身份标识、索引信息、以及与所述目标时段对应的虚拟资源余额;所述索引信息基于目标余额信息的生成日期生成;
处理模块42,用于基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
一种可选实施方式中,还包括:生成模块43,用于根据以下步骤存储所述余额信息:
响应用户的操作行为,为用户分配与所述操作行为对应的虚拟资源;
基于为所述用户分配的所述虚拟资源,更新与所述用户对应的虚拟资源余额,并基于更新后的虚拟资源余额、以及所述操作行为的行为日期,更新内存数据库中所述用户在所述行为日期的余额信息。
一种可选实施方式中,还包括:更新模块44,用于在所述处理模块42基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,基于所述虚拟资源处理的结果,更新与用户身份标识对应的虚拟资源余额;基于更新后的所述虚拟资源余额,更新内存数据库中所述用户在所述目标时段之后的余额信息。
一种可选实施方式中,所述述索引信息中还包括:分组索引;
所述处理模块42,在基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理时,用于:
基于多个所述目标余额信息中每个目标余额信息的分组索引,将所述多个目标余额信息划分至多个处理分组中;
基于所述多个处理分组中每个处理分组中目标余额信息的虚拟资源余额、以及用户身份标识,对所述多个处理分组执行虚拟资源的并行处理。
一种可选实施方式中,所述生成模块43,用于采用下述方法生成所述索引信息:
基于所述用户的用户身份标识、以及预先设置的分组数量,确定分组索引;以及
将所述分组索引与所述余额信息的生成日期进行拼接,生成所述索引信息。
一种可选实施方式中,所述预设处理条件,包括下述至少一种:
当前时刻到达预设处理时刻;
当前不存在所述目标余额信息在所述目标时段的成功处理记录。
一种可选实施方式中,还包括:记录模块,用于在所述处理模块42基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理后,基于所述目标余额信息中的用户身份标识,生成成功处理记录,并将所述成功处理记录存储在目标数据库中。
一种可选实施方式中,还包括:第二响应模块45,用于:
响应用户进入目标页面的操作请求,检测所述操作请求中是否携带有与所述目标时段对应的成功处理标识;
若所述操作请求中并未携带所述成功处理标识,则基于用户的用户身份标识,检测所述目标数据库中是否存在与所述用户对应的成功处理记录;
若所述目标数据库中不存在与所述用户对应的成功处理记录,则基于用户在所述目标时段的虚拟资源余额,对所述用户对与所述虚拟资源余额对应的虚拟资源进行处理。
一种可选实施方式中,所述第二响应模块45,还用于:
若所述目标数据库中存在与所述用户对应的成功处理记录,则生成与所述用户对应的成功处理标识,并将所述成功处理标识反馈给所述用户。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
本申请实施例还提供了一种电子设备10,如图5所示,为本申请实施例提供的电子设备10结构示意图,包括:
处理器11和存储器12;所述存储器12存储有所述处理器11可执行的机器可读指令,所述机器可读指令被所述处理器执行时,所述处理器执行下述步骤:
响应预设处理条件的触发,基于处理的目标时段,从内存数据库中读取目标余额信息;其中,所述目标余额信息包括:用户身份标识、索引信息、以及与所述目标时段对应的虚拟资源余额;所述索引信息基于目标余额信息的生成日期生成;所述目标余额信息的索引信息与所述目标时段匹配;
基于所述目标余额信息中的虚拟资源余额、以及用户身份标识,对与所述虚拟资源余额对应的虚拟资源进行处理。
上述指令的具体执行过程可以参考本申请实施例中所述的虚拟资源的处理方法的步骤,此处不再赘述。
本申请实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的虚拟资源的处理方法的步骤。
本申请实施例所提供的虚拟资源的处理方法的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行上述方法实施例中所述的虚拟资源的处理方法的步骤,具体可参见上述方法实施例,在此不再赘述。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本申请所提供的几个实施例中,应该理解到,所揭露的***、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本申请的具体实施方式,用以说明本申请的技术方案,而非对其限制,本申请的保护范围并不局限于此,尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。