管理记录控制方法、装置、存储介质及电子设备与流程

1.本技术实施例涉及计算机技术领域，尤其涉及管理记录控制方法、装置、存储介质及电子设备。


背景技术：

2.随着网络世界的不断发展，虚拟物品的流通管理变得越来越重要，虚拟物品的管理平台可以为用户提供多时间维度下的虚拟物品管理服务，但是这也导致了虚拟物品管理难度显著上升，并且也导致了虚拟物品少发、多发等问题，并且，在虚拟物品管理过程中，对于管理记录的并发操作的支持力度也日渐提升，但是多并发也可能导致管理记录冲突，而这种管理记录冲突产生的问题在多时间维度管理场景中日渐凸显，进一步加剧了虚拟物品少发、多发等问题。


技术实现要素：

3.为了解决上述至少一个技术问题，本技术实施例提供管理记录控制方法、装置、存储介质及电子设备。
4.一方面，本技术实施例提供了一种管理记录控制方法，所述方法包括：
5.在需要对第一记录进行状态变更的情况下，查询映射记录，所述映射记录为与所述第一记录具备相同主键并且具备相同目标时间段的记录，所述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录；
6.在查询到所述映射记录的情况下，查询所述映射记录对应的请求排他锁，所述请求排他锁用于阻止除去所述请求排他锁的接管线程之外的其他线程对与所述映射记录具备相同主键的记录进行处理；
7.在存在所述请求排他锁并且所述请求排他锁的加锁时长大于第一时长阈值的情况下，获取所述映射记录所对应的记录状态；
8.根据所述记录状态，控制所述第一记录进行状态变更。
9.在一个实施例中，所述获取所述映射记录所对应的记录状态之前，所述方法还包括：
10.在所述映射记录所对应的任务创建成功的情况下，生成任务标识；
11.建立所述任务标识与所述映射记录之间的关联关系；
12.所述获取所述映射记录所对应的记录状态，包括：
13.根据所述关联关系确定所述映射记录所对应的所述任务标识；
14.基于所述任务标识调用异步状态查询接口，得到所述映射记录所对应的任务的任务状态；
15.将所述任务状态作为所述映射记录所对应的记录状态。
16.在一个实施例中，所述根据所述记录状态，控制所述第一记录进行状态变更，包括：
17.在所述记录状态表征任务执行完毕的情况下，基于加锁交互机制对所述第一记录进行状态变更；
18.在所述记录状态表征任务未执行完毕的情况下，判断加锁时长是否大于第二时长阈值，根据判断结果控制所述第一记录进行状态变更。
19.在一个实施例中，所述根据判断结果控制所述第一记录进行状态变更，包括：
20.在所述加锁时长小于或等于所述第二时长阈值的情况下，提示针对所述第一记录的状态变更失败；
21.在所述加锁时长大于所述第二时长阈值的情况下，基于加锁交互机制对所述第一记录进行状态变更。
22.在一个实施例中，所述基于加锁交互机制对所述第一记录进行状态变更，包括：
23.对所述请求排他锁进行接管，并且对所述请求排他锁对应的加锁时间进行重置；
24.在所述请求排他锁重置完毕的情况下，对所述第一记录进行状态变更；
25.在状态变更成功的情况下，删除所述请求排他锁。
26.在一个实施例中，所述方法还包括：
27.在存在所述请求排他锁并且所述请求排他锁的加锁时长小于或者等于所述第一时长阈值的情况下，提示针对所述第一记录的状态变更失败。
28.在一个实施例中，所述方法还包括：
29.在未查询到所述映射记录的情况下，对所述第一记录添加请求排他锁，对所述第一记录进行状态变更，并且在状态变更成功的情况下，删除所述请求排他锁。
30.另一方面，本技术实施例提供一种管理记录控制装置，所述装置包括：
31.映射记录查询模块，用于在需要对第一记录进行状态变更的情况下，查询映射记录，所述映射记录为与所述第一记录具备相同主键并且具备相同目标时间段的记录，所述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录；
32.请求排他锁查询模块，用于在查询到所述映射记录的情况下，查询所述映射记录对应的请求排他锁，所述请求排他锁用于阻止除去所述请求排他锁的接管线程之外的其他线程对与所述映射记录具备相同主键的记录进行处理；
33.记录控制模块，用于在存在所述请求排他锁并且所述请求排他锁的加锁时长大于第一时长阈值的情况下，获取所述映射记录所对应的记录状态；根据所述记录状态，控制所述第一记录进行状态变更。
34.在一个实施例中，所述记录控制模块，用于执行下述操作：
35.在所述映射记录所对应的任务创建成功的情况下，生成任务标识；
36.建立所述任务标识与所述映射记录之间的关联关系；
37.根据所述关联关系确定所述映射记录所对应的所述任务标识；
38.基于所述任务标识调用异步状态查询接口，得到所述映射记录所对应的任务的任务状态；
39.将所述任务状态作为所述映射记录所对应的记录状态。
40.在一个实施例中，所述记录控制模块，用于执行下述操作：
41.在所述记录状态表征任务执行完毕的情况下，基于加锁交互机制对所述第一记录进行状态变更；
42.在所述记录状态表征任务未执行完毕的情况下，判断加锁时长是否大于第二时长阈值，根据判断结果控制所述第一记录进行状态变更。
43.在一个实施例中，所述记录控制模块，用于执行下述操作：
44.在所述加锁时长小于或等于所述第二时长阈值的情况下，提示针对所述第一记录的状态变更失败；
45.在所述加锁时长大于所述第二时长阈值的情况下，基于加锁交互机制对所述第一记录进行状态变更。
46.在一个实施例中，所述记录控制模块，用于执行下述操作：
47.对所述请求排他锁进行接管，并且对所述请求排他锁对应的加锁时间进行重置；
48.在所述请求排他锁重置完毕的情况下，对所述第一记录进行状态变更；
49.在状态变更成功的情况下，删除所述请求排他锁。
50.在一个实施例中，所述记录控制模块，用于执行下述操作：
51.在存在所述请求排他锁并且所述请求排他锁的加锁时长小于或者等于所述第一时长阈值的情况下，提示针对所述第一记录的状态变更失败。
52.在一个实施例中，所述记录控制模块，用于执行下述操作：
53.在未查询到所述映射记录的情况下，对所述第一记录添加请求排他锁，对所述第一记录进行状态变更，并且在状态变更成功的情况下，删除所述请求排他锁。
54.另一方面，本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现上述的一种管理记录控制方法。
55.另一方面，本技术实施例提供了一种电子设备，包括至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现上述的一种管理记录控制方法。
56.另一方面，本技术实施例提供了一种计算机程序产品，包括计算机程序或指令，该计算机程序或指令被处理器执行时实现上述的一种管理记录控制方法。
57.本技术实施例提供一种管理记录控制方法，在进行管理记录状态控制的情况下，通过设置请求排他锁的方式避免由于并发操作导致的管理混乱，从并发控制角度进一步确保了管理记录状态变更的严谨性，从而避免虚拟物品多发。具体来说，在基于请求排他锁进行管理记录控制的过程中，不仅考虑到请求排他锁的设置时间，还需要考虑到该请求排他锁关联的任务的任务状态，从而极大减少由于强行解锁导致的管理混乱，同时保证合理的状态变更可以平滑实施。
附图说明
58.为了更清楚地说明本技术实施例或相关技术中的技术方案和优点，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术实施例的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
59.图1是本说明书实施例提供的管理记录控制的基础方案的流程示意图；
60.图2是本说明书实施例提供的管理记录控制方法流程示意图；
61.图3是本说明书实施例提供的基于加锁交互机制对上述第一记录进行状态变更流程示意图；
62.图4是本技术实施例提供的管理记录控制装置的框图；
63.图5是本技术实施例提供的一种用于实现本技术实施例所提供的方法的设备的硬件结构示意图。
具体实施方式
64.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术实施例一部分实施例，而不是全部的实施例。基于本技术实施例中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术实施例保护的范围。
65.需要说明的是，本技术实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术实施例的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
66.为了使本技术实施例公开的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术实施例进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术实施例，并不用于限定本技术实施例。
67.以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
68.本技术实施例提供了一种管理记录控制方法，该管理记录控制方法应用于虚拟物品管理端，对于虚拟物品管理端的应用场景，本技术实施例进行下述介绍。
69.虚拟物品管理端作为一个中间管理平台，可以与用户所持有的电子设备(包括登录用户账户的客户端)以及任务发布平台分别进行通信，从而将任务发布平台的功能解耦，使得任务发布平台无需进行虚拟物品的管理。
70.本技术实施例并不限定任务发布平台，其可以被认为是任一接入上述虚拟物品管理端的任务发布平台，也可以被认为是任意订购上述虚拟物品管理端的虚拟物品管理服务的任务发布平台。比如，任务发布平台可以为游戏程序的服务器，该服务器可以向用户发布游戏任务，但是用户可以通过本技术实施例中的虚拟物品管理端获得游戏任务中的虚拟物品奖励，而该服务器可以将游戏任务中的虚拟物品奖励有关的管理功能解耦。再比如，任务发布平台可以为直播程序的服务器，该服务器可以向用户发布直播任务，但是用户可以通过本技术实施例中的虚拟物品管理端获得直播任务中的虚拟物品奖励，而该服务器可以将直播任务中的虚拟物品奖励有关的管理功能解耦。本技术实施例并不限定接入的任务发布
平台的类型与数量。
71.本技术实施例中的目标对象可以被理解为在任一上述任务发布平台执行任务的用户所对应的虚拟对象，该目标对象通过执行任务理应得到任务发布平台所发布的虚拟物品作为奖励，但是，本技术实施例中的虚拟物品可以由虚拟物品管理端代发，也就是说，任务发布平台可以通过签订服务协议的方式交由虚拟物品管理端来进行代发。
72.需要注意的是，本技术实施例中虚拟物品管理端可以为目标对象提供不同时间维度的代发服务，比如，可以根据该目标对象在任务发布平台的行为表现按周或者按月进行虚拟物品的代发服务，从而支持多时间维度下的虚拟物品发放，满足用户的多时间维度的虚拟物品获取需求，比如，该虚拟物品管理端可以按周为用户发放一部分的虚拟物品，并且同时也按月为该用户发放另一部分的虚拟物品，从而满足用户多时间维度下的虚拟物品获取需求。
73.但是，多时间维度下的虚拟物品获取需求的满足带来了虚拟物品管理上的困难，也就是说，这一功能带来了虚拟物品管理记录的状态管理上的困难。如果不能精准管理虚拟物品管理记录的状态，可能会导致虚拟物品的多发。
74.举个例子，基于某对象a在8月7日至8月13日的行为表现信息，为其在对应的“周”发放价值500虚拟币的虚拟物品，当然，虚拟物品管理端对应存在一条记录，即为记录1，假设此时记录1的状态为状态1，表征该记录1中的虚拟物品已经被发放,。
75.在当月按月发放虚拟物品时，综合该对象a在8月的行为表现信息，应当为其发放价值5000虚拟币的虚拟物品，当然，虚拟物品管理端对应存在一条记录，即为记录2，假设此时记录2的状态为状态2，表征记录2中的虚拟物品尚未发放。
76.基于记录1和记录2及其各自的状态来确定8月应当发放的虚拟物品时，正常情况下应当发放5000-500＝4500的虚拟物品。但是，在由于记录1和记录2生成的先后顺序不唯一、记录1和记录2各自的状态的变更先后顺序也无法提前预设，这就导致基于记录1和记录2及其各自的状态所确定出的最终按月发放的虚拟物品的总量可能不准确，从而产生多发问题。
77.比如，假设首先生成记录1，但是由于价值500虚拟币的虚拟物品还没发，导致记录1的状态并不是状态1，这情况下再得到记录2，则可能记录1中要求的虚拟物品和记录2中要求的虚拟物品都会被发放，即发放了5000+500＝5500的虚拟物品，造成多发。
78.为了解决多时间维度下的虚拟物品获取功能所带来的虚拟物品管理记录的状态管理上的困难，确保虚拟物品不出现多发，实现虚拟物品的准确流通，可以对于相关的管理记录的状态进行严格的控制。本技术实施例提供一种状态控制方法，该方法控制下可以避免产生多发问题。该方法也可以视为本技术实施例中管理记录控制的基础方案，该基础方案如图1所示，包括：
79.s101.在接收到针对第一记录的状态变更请求的情况下，确定上述第一记录的目标时段信息，上述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录。
80.本技术实施例支持多时间维度下的管理记录的状态转换，举个例子，可以支持周维度和月维度，如果目标时段信息表征周维度，则该第一记录就是记录了一个周内虚拟物品的数量信息；如果目标时段信息表征月维度，则该第一记录就是记录了一个月内虚拟物
品的数量信息。
81.s102.在上述目标时段信息表征第一类时段的情况下，对上述第一记录进行状态变更，上述第一类时段为生成管理记录的最小时间段。
82.本技术实施例中第一类时段就是生成管理记录的最小时间段。以虚拟物品管理端可以支持周维度和月维度为例，第一类时段就是“周”。对于这种时段相关的第一记录，可以直接对上述第一记录进行状态变更，因为，本技术实施例从非最小时段下的虚拟物品发放环节规避多发问题，而对于最小时间段下的虚拟物品发放不进行限定，最小时段下的物品发放可以直接进行，这一方案既降低了状态管理对于最小时段下的物品发放环节的影响，又保证了各个时段下都可以进行虚拟物品发放并且最终不出现多发的技术效果。
83.s103.在上述目标时段信息表征第二类时段的情况下，查询上述第一记录关联的全部第二记录，每一上述第二记录对应的时间段位于上述目标时间段，并且每一上述第二记录对应的时段信息为上述第一类时段，上述第二类时段包括多个上述第一类时段。
84.第二类时段显然是非最小时间段，以虚拟物品管理端可以支持周维度和月维度为例，第二类时段就是“月”。首先，可以查询出该月中的各“周”有关的记录，即上述全部第二记录。
85.s104.在上述第一记录并未关联任何第二记录的情况下，对上述第一记录进行状态变更。
86.如果上述第一记录并未关联任何第二记录，说明该月并没有按周结付虚拟物品，那么也就不会出现因为按周结付虚拟物品导致的多发，可以直接基于该第一记录按月维度发放虚拟物品，而不出现多发。
87.本技术实施例中对上述第一记录进行状态变更，可以认为是在充分考虑到确保不会导致多发的情况下，才对第一记录进行的状态变更，因为本技术实施例中第一记录的状态变更与虚拟物品发放是直接相关的，因此，本技术实施例中通过进行状态变更严谨管理的方式确保不出现虚拟物品多发。
88.s105.在上述第一记录关联的全部第二记录均位于第一状态的情况下，对上述第一记录进行状态变更；上述第一状态表征对应的第二记录中关联的虚拟物品已经被发送至上述目标对象。
89.如果该月存在可能需要按周发虚拟物品的情况，即存在第二记录，如果这些第二记录都是位于第一状态，也就是说，这些第二记录中的虚拟物品都被以按周维度结付掉了，则在按月结付虚拟物品的时候，只需要将这些提前结付的虚拟物品扣除即可，不会产生多发，这种情况下也可以对上述第一记录进行状态变更。
90.s106.在存在目标第二记录的情况下，不进行针对第一记录的状态变更，上述目标第二记录为不处于上述第一状态的第二记录。
91.如果存在并非位于第一状态的第二记录(目标第二记录)，就表示准备按周维度发放目标第二记录中的虚拟物品，但是这一动作还没有实施，那么就有可能在按月发放虚拟物品之后，该目标第二记录中的虚拟物品再一次被结付，从而造成了多发，这种情况下，本技术实施例直接不允许进行第一记录的状态变更，阻止第一记录的状态变更就阻止了第一记录中虚拟物品的发放，从而避免多发的产生，只有对于目标第二记录妥善处理之后才能再次进行第一记录的状态变更，确保不会出现多发。
92.在上述技术方案中，通过严格的状态变更控制避免了多发，但是该方法并没有考虑到多并发的情况，举例来说，如果两个管理员分别先后触发了针对该第一记录的状态变更请求，如果不对这两个针对同一目标对象同一目标时间段的管理记录进行干预，可能导致两个管理员的触发操作互相影响，后一个管理员看到的第一记录不是自己上传的管理记录，而是前一个管理员上传的管理记录，引起管理混乱，而管理混乱也可能导致多发问题的再次出现。
93.为了确保避免多发问题，本技术实施例在保持严格的状态变更控制的基础上进一步强化了并发控制，在支持高并发的前提下避免因为并发原因导致的虚拟物品多发问题，从而提出一种管理记录控制方法，图2示出了本技术实施例提供的一种管理记录控制方法的流程示意图，该方法同样运行于虚拟物品管理端。本技术实施例提供了如实施例或流程图上述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统、终端设备或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)，上述方法可以包括：
94.s201.在需要对第一记录进行状态变更的情况下，查询映射记录，上述映射记录为与上述第一记录具备相同主键并且具备相同目标时间段的记录，上述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录。
95.本技术实施例可以接收针对第一记录的状态变更请求，在接收到该请求的情况下判断是否需要进行状态变更，并在判定需要的情况下执行步骤s201，而如何在接收到针对第一记录的状态变更请求的情况下判断是否需要进行状态变更的细节请参考前文，在此不做赘述。
96.本技术实施例中上述状态变更请求可以为预览请求或者入库请求。预览请求下可以为客户端提供针对管理记录的预览功能。入库请求可以为客户端提供针对管理记录的预览以及入库的功能。本技术实施例中只有被录入数据库并且被设定为第一状态的管理记录中的虚拟物品才可以被发放至其对应的对象。
97.本技术实施例中将预览请求实施后的管理记录的状态称之为第二状态，第二状态下管理记录未被录入数据库。本技术实施例中将入库请求实施后的管理记录的状态称之为第三状态，第三状态下管理记录已经被录入数据库但是尚未生效，这是第三状态与第一状态的区别。
98.对于第一记录而言，如果接收到针对第一记录的预览请求，客户端可以通过访问虚拟物品管理端查看到与该第一记录有关的内容，但是该第一记录中的内容尚未录入上述虚拟物品管理端的数据库，即该第一记录可以被置为第二状态。如果接收到针对第一记录的入库请求，客户端可以通过访问虚拟物品管理端查看到与该第一记录有关的内容，并且将该第一记录中的内容录入上述虚拟物品管理端的数据库，即该第一记录可以被置为第三状态。
99.以上述状态变更请求为预览请求为例，上述在接收到针对第一记录的状态变更请求的情况下，确定上述第一记录的目标时段信息之前，还包括：
100.s301.获取行为表现信息，上述行为表现信息为上述目标对象在上述目标时间段的、与虚拟物品相关的行为对应的表现信息。
101.比如，目标对象通过在任务发布平台1执行游戏任务领取虚拟物品，则该行为表现信息指目标对象在目标时间段的游戏任务执行情况。目标对象通过在任务发布平台2执行媒体资源编辑任务领取虚拟物品，则该行为表现信息指目标对象在目标时间段的媒体资源编辑任务的执行情况。
102.s302.根据第一标识、第二标识和上述行为表现信息，生成第一记录，上述第一标识为上述目标对象对应的虚拟物品提供者的标识，上述第二标识为上述目标对象对应的虚拟物品管理者的标识。
103.该第一标识可以为该任务发布平台1或任务发布平台2的标识，第二标识可以为属于虚拟物品管理端的管理员的标识，该虚拟物品管理端可以配置多个管理员，每个管理员用于管理多个用户在各个任务发布平台的任务执行情况，以及为该多个用户在该虚拟物品管理端进行对应的管理记录的管理。这种情况下生成的第一记录的主键就是“第一标识and第二标识”。
104.s303.根据上述第一记录生成上述预览请求。
105.以上述状态变更请求为入库请求为例，上述入库请求用于将上述第一记录变更至第三状态，上述在接收到针对第一记录的状态变更请求的情况下，确定上述第一记录的目标时段信息之前，还包括：
106.s401.获取行为表现信息，上述行为表现信息为上述目标对象在上述目标时间段的、与虚拟物品相关的行为对应的表现信息。
107.s402.根据第一标识、第二标识和上述行为表现信息，生成第一记录，上述第一标识为上述目标对象对应的虚拟物品提供者的标识，上述第二标识为上述目标对象对应的虚拟物品管理者的标识。
108.s403.根据上述第一记录生成上述入库请求。
109.入库请求的生成方式与预览请求相似，本技术实施例不再赘述。入库请求和预览请求都可以由虚拟物品管理端的管理员触发生成，并传输至虚拟物品管理端。在一个具体的实施例中，根据第一标识、第二标识和上述行为表现信息，生成第一记录，可以具体包括：根据上述第一标识、上述第二标识、第三标识和上述行为表现信息，生成上述第一记录，上述第三标识为上述目标对象的身份标识。这种情况下生成的第一记录的主键就是“第一标识and第二标识and第三标识”。主键的设置相较于前文粒度更细，可以实现更为精细化的管理记录的状态管理。
110.s202.在查询到上述映射记录的情况下，查询上述映射记录对应的请求排他锁，上述请求排他锁用于阻止除去上述请求排他锁的接管线程之外的其他线程对与上述映射记录具备相同主键的记录进行处理。
111.本技术实施例中，为了确保对第一记录的状态变更操作的唯一性，需要设计加锁交互机制。本技术实施例中加的锁为一种请求排他锁，或者说线程排他锁，目的在于阻止除去上述请求排他锁的接管线程之外的其他线程对与上述映射记录具备相同主键的记录进行处理。第一记录与映射记录具备相同主键，则除了接管映射记录的请求排他锁的线程外，其他线程无法操作第一记录和映射记录，当前正在运行的线程是针对第一记录的响应线程，显然并不是映射记录的请求排他锁的接管线程，自然也无法对第一记录进行状态变更。也就是说，如果该请求排他锁有效，则可能会阻止当前正在运行的线程即将进行的状态变
更处理操作。
112.s203.在存在上述请求排他锁并且上述请求排他锁的加锁时长大于第一时长阈值的情况下，获取上述映射记录所对应的记录状态。
113.本技术实施例不仅考虑到请求排他锁是否存在，还需要考虑到请求排他锁的加锁时长。在一个实施例中，可以在加锁时长大于第一时长阈值的情况下强制解锁，便于进行针对第一记录的状态变更，但是本技术实施例并未采用这一方法，原因在于，该请求排他锁并未解除的情况说明申请该请求排他锁的线程所对应的任务很可能并未执行完毕，即针对映射记录的任务并未执行完毕，比如该针对该映射记录的任务是与状态变更或者入库有关的任务，这些任务都可能对于数据库中的管理记录产生影响，在任务并未执行完毕的情况下强行解锁固然可以推进对于第一记录的状态变更的顺利实施，但是也会导致之前并未执行完毕的任务被强行挂起，在第一记录的状态变更完毕之后，之前被挂起的任务会继续执行，这仍然会导致管理记录的管理混乱，造成虚拟物品多发，因此，本技术实施例中并未在加锁时长大于第一时长阈值的情况下直接、盲目地强制解锁，而是首先需要获取到映射记录所对应的记录状态。
114.在一个实施例中，在上述获取上述映射记录所对应的记录状态之前，上述方法还包括：在上述映射记录所对应的任务创建成功的情况下，生成任务标识；建立上述任务标识与上述映射记录之间的关联关系。
115.虚拟物品管理端在接收到针对该映射记录的状态变更请求的情况下，可以触发针对该映射记录的状态变更，针对该映射记录的状态变更请求显然先于针对第一记录的状态变更请求被虚拟物品管理端所接收到。
116.针对该映射记录的状态变更由具体的任务来实施，该任务可以实施状态变更，同时还可以实施管理记录入库、管理记录校验等操作中的至少一种，该任务执行完毕的情况下针对该映射记录的状态变更请求才可以被视为响应成功。该任务异步实施，在创建成功的情况下会生成任务标识，该任务标识与该映射记录具备一一对应关系，通过该任务标识异步调用虚拟物品管理端所提供的异步状态查询接口即可查询到该任务的任务状态。
117.相应的，上述获取上述映射记录所对应的记录状态，包括：根据上述关联关系确定上述映射记录所对应的上述任务标识；基于上述任务标识调用异步状态查询接口，得到上述映射记录所对应的任务的任务状态；将上述任务状态作为上述映射记录所对应的记录状态。
118.s204.根据上述记录状态，控制上述第一记录进行状态变更。
119.在上述记录状态表征任务执行完毕的情况下，基于加锁交互机制对上述第一记录进行状态变更。在上述记录状态表征任务执行完毕的情况下，表征映射记录对应的任务已经被执行完毕了，本就应该解除请求排他锁，可能因为程序缺陷、网络波动、消息延时等客观原因导致请求排他锁尚未被解除，这种情况下强行解锁不会导致虚拟物品多发，所以这种情况下可以控制上述第一记录进行状态变更。
120.在上述记录状态表征任务未执行完毕的情况下，判断加锁时长是否大于第二时长阈值，根据判断结果控制上述第一记录进行状态变更。在上述记录状态表征任务未执行完毕的情况下，表征映射记录对应的任务正在进行，贸然解除请求排他锁，可能导致该任务被挂起，并且在合适的时机该任务会被继续执行直至执行完毕，这种情况下强行解锁很可能
会导致虚拟物品多发，所以这种情况下需要进一步判断该请求排他锁的状态。
121.具体来说，在上述加锁时长小于或等于上述第二时长阈值的情况下，提示针对上述第一记录的状态变更失败。在上述加锁时长大于上述第二时长阈值的情况下，基于加锁交互机制对上述第一记录进行状态变更。
122.本技术实施例中第二时长阈值显著高于第一时长阈值，比如，第一时长阈值可以是5分钟，第二时长阈值可以是30分钟，如果达到第二时长阈值请求排他锁还没有被接触，可以判定映射记录所对应的任务大概率已经死亡，不会造成虚拟物品多发的后果，这种情况下强行解除请求排他锁也没有关系，反之，可以认为映射记录所对应的任务很可能尚未死亡，不能解除请求排他锁，这种情况下不能贸然变更第一记录的状态，因此，提示针对上述第一记录的状态变更失败。
123.在一个实施例中，前文上述的基于加锁交互机制对上述第一记录进行状态变更，如图3所示，包括：
124.s501.对上述请求排他锁进行接管，并且对上述请求排他锁对应的加锁时间进行重置。
125.当前处理第一记录的线程接管该请求排他锁并对上述请求排他锁对应的加锁时间进行重置，使得该请求排他锁在第一记录之上重新生效，在第一记录上设置该请求排他锁的原因在于，对晚于第一记录的状态变更请求后，被接收到其他记录的状态变更请求进行排他阻止，这种情况下相对于该其他记录，第一记录成为了前文的“映射记录”。
126.s502.在上述请求排他锁重置完毕的情况下，对上述第一记录进行状态变更。
127.s503.在状态变更成功的情况下，删除上述请求排他锁。
128.请求排他锁的及时删除有利于虚拟物品管理端平滑、顺利地处理后来的状态变更请求。
129.s205.在存在上述请求排他锁并且上述请求排他锁的加锁时长小于或者等于上述第一时长阈值的情况下，提示针对上述第一记录的状态变更失败。
130.这种情况下请求排他锁是有效的，那么当前线程即将进行的状态变更处理操作被阻止，响应失败，成功避免了可能造成的预览或者入库混乱。
131.s206.在未查询到上述映射记录的情况下，对上述第一记录添加请求排他锁，对上述第一记录进行状态变更，并且在状态变更成功的情况下，删除上述请求排他锁。
132.如果不存在映射记录，说明之前没有管理员上传过针对该目标对象、该目标时间段的记录，也就是说，第一记录为全新记录，这种情况下可以直接触发状态变更。具体来说，可以将上述第一记录的状态变更至上述第二状态或第三状态；在上述状态变更成功的情况下，删除上述请求排他锁。具体来说，如果是预览请求，就变更至第二状态，如果是入库请求，就变更至第三状态，当然，还需要执行入库操作，入库操作不是本技术重点，不做赘述。
133.本技术实施例在进行管理记录状态控制的情况下，通过设置请求排他锁的方式避免由于并发操作导致的管理混乱，从并发控制角度进一步确保了管理记录状态变更的严谨性，从而避免虚拟物品多发。具体来说，在基于请求排他锁进行管理记录控制的过程中，不仅考虑到请求排他锁的设置时间，还需要考虑到该请求排他锁关联的任务的任务状态，从而极大减少由于强行解锁导致的管理混乱，同时保证合理的状态变更可以平滑实施。
134.请参考图4，其示出本实施例中一种管理记录控制装置的框图，上述装置包括：
135.映射记录查询模块401，用于在需要对第一记录进行状态变更的情况下，查询映射记录，上述映射记录为与上述第一记录具备相同主键并且具备相同目标时间段的记录，上述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录；
136.请求排他锁查询模块402，用于在查询到上述映射记录的情况下，查询上述映射记录对应的请求排他锁，上述请求排他锁用于阻止除去上述请求排他锁的接管线程之外的其他线程对与上述映射记录具备相同主键的记录进行处理；
137.记录控制模块403，用于在存在上述请求排他锁并且上述请求排他锁的加锁时长大于第一时长阈值的情况下，获取上述映射记录所对应的记录状态；根据上述记录状态，控制上述第一记录进行状态变更。
138.在一个实施例中，上述记录控制模块，用于执行下述操作：
139.在上述映射记录所对应的任务创建成功的情况下，生成任务标识；
140.建立上述任务标识与上述映射记录之间的关联关系；
141.根据上述关联关系确定上述映射记录所对应的上述任务标识；
142.基于上述任务标识调用异步状态查询接口，得到上述映射记录所对应的任务的任务状态；
143.将上述任务状态作为上述映射记录所对应的记录状态。
144.在一个实施例中，上述记录控制模块，用于执行下述操作：
145.在上述记录状态表征任务执行完毕的情况下，基于加锁交互机制对上述第一记录进行状态变更；
146.在上述记录状态表征任务未执行完毕的情况下，判断加锁时长是否大于第二时长阈值，根据判断结果控制上述第一记录进行状态变更。
147.在一个实施例中，上述记录控制模块，用于执行下述操作：
148.在上述加锁时长小于或等于上述第二时长阈值的情况下，提示针对上述第一记录的状态变更失败；
149.在上述加锁时长大于上述第二时长阈值的情况下，基于加锁交互机制对上述第一记录进行状态变更。
150.在一个实施例中，上述记录控制模块，用于执行下述操作：
151.对上述请求排他锁进行接管，并且对上述请求排他锁对应的加锁时间进行重置；
152.在上述请求排他锁重置完毕的情况下，对上述第一记录进行状态变更；
153.在状态变更成功的情况下，删除上述请求排他锁。
154.在一个实施例中，上述记录控制模块，用于执行下述操作：
155.在存在上述请求排他锁并且上述请求排他锁的加锁时长小于或者等于上述第一时长阈值的情况下，提示针对上述第一记录的状态变更失败。
156.在一个实施例中，上述记录控制模块，用于执行下述操作：
157.在未查询到上述映射记录的情况下，对上述第一记录添加请求排他锁，对上述第一记录进行状态变更，并且在状态变更成功的情况下，删除上述请求排他锁。
158.装置实施例与方法实施例基于相同发明构思，不做赘述。
159.另一方面，本技术实施例提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有至少一条指令或至少一段程序，上述至少一条指令或至少一段程序由处理器
加载并执行以实现上述的一种管理记录控制方法。
160.本技术实施例中装置部分与方法实施例基于相同发明构思，在此不做赘述。
161.进一步地，图5示出了一种用于实现本技术实施例所提供的方法的设备的硬件结构示意图，上述设备可以参与构成或包含本技术实施例所提供的装置或系统。如图5所示，设备10可以包括一个或多个(图中采用102a、102b，
……
，102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图5所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。
162.应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分地体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
163.存储器104可用于存储应用软件的软件程序以及模块，如本技术实施例中上述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种管理记录控制方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
164.传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。
165.显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。
166.需要说明的是：上述本技术实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本技术实施例特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
167.本技术实施例中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和服务器实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参
见方法实施例的部分说明即可。
168.本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
169.上述存储介质中的指令可以执行一种管理记录控制方法，上述方法包括：
170.在需要对第一记录进行状态变更的情况下，查询映射记录，上述映射记录为与上述第一记录具备相同主键并且具备相同目标时间段的记录，上述第一记录为用于记录目标对象在目标时间段内关联的虚拟物品的数量信息的管理记录；
171.在查询到上述映射记录的情况下，查询上述映射记录对应的请求排他锁，上述请求排他锁用于阻止除去上述请求排他锁的接管线程之外的其他线程对与上述映射记录具备相同主键的记录进行处理；
172.在存在上述请求排他锁并且上述请求排他锁的加锁时长大于第一时长阈值的情况下，获取上述映射记录所对应的记录状态；
173.根据上述记录状态，控制上述第一记录进行状态变更。
174.在一个实施例中，上述获取上述映射记录所对应的记录状态之前，上述方法还包括：
175.在上述映射记录所对应的任务创建成功的情况下，生成任务标识；
176.建立上述任务标识与上述映射记录之间的关联关系；
177.上述获取上述映射记录所对应的记录状态，包括：
178.根据上述关联关系确定上述映射记录所对应的上述任务标识；
179.基于上述任务标识调用异步状态查询接口，得到上述映射记录所对应的任务的任务状态；
180.将上述任务状态作为上述映射记录所对应的记录状态。
181.在一个实施例中，上述根据上述记录状态，控制上述第一记录进行状态变更，包括：
182.在上述记录状态表征任务执行完毕的情况下，基于加锁交互机制对上述第一记录进行状态变更；
183.在上述记录状态表征任务未执行完毕的情况下，判断加锁时长是否大于第二时长阈值，根据判断结果控制上述第一记录进行状态变更。
184.在一个实施例中，上述根据判断结果控制上述第一记录进行状态变更，包括：
185.在上述加锁时长小于或等于上述第二时长阈值的情况下，提示针对上述第一记录的状态变更失败；
186.在上述加锁时长大于上述第二时长阈值的情况下，基于加锁交互机制对上述第一记录进行状态变更。
187.在一个实施例中，上述基于加锁交互机制对上述第一记录进行状态变更，包括：
188.对上述请求排他锁进行接管，并且对上述请求排他锁对应的加锁时间进行重置；
189.在上述请求排他锁重置完毕的情况下，对上述第一记录进行状态变更；
190.在状态变更成功的情况下，删除上述请求排他锁。
191.在一个实施例中，上述方法还包括：
192.在存在上述请求排他锁并且上述请求排他锁的加锁时长小于或者等于上述第一时长阈值的情况下，提示针对上述第一记录的状态变更失败。
193.在一个实施例中，上述方法还包括：
194.在未查询到上述映射记录的情况下，对上述第一记录添加请求排他锁，对上述第一记录进行状态变更，并且在状态变更成功的情况下，删除上述请求排他锁。
195.以上仅为本技术实施例的较佳实施例，并不用以限制本技术实施例，凡在本技术实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术实施例的保护范围之内。