Method and apparatus for processing management record based on task identification multiplexing

Abstract

The embodiment of the application discloses a management record processing method based on task identification multiplexing, comprising: in the case of needing to change the state of a first record, querying a mapping record, the mapping record being a record with the same primary key and the same target time period as the first record, and the first record being a management record for recording the quantity information of virtual goods associated by a target object in a target time period; in the case of querying the mapping record, multiplexing the task identification corresponding to the mapping record, and changing the state of the first record based on the task identification; in the case of not querying the mapping record, communicating with a target node in an identification providing system to obtain a task identification, and changing the state of the first record based on the task identification. The application simultaneously reduces the risk of identification conflict, identification depletion, management confusion and virtual goods multiple delivery.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a management record processing method and apparatus based on task identifier reuse. Background Technology

[0002] Virtual item management platforms can provide users with virtual item management services across multiple time dimensions. Furthermore, as the number of users increases, the support for concurrent operations on management records by virtual item management platforms is also increasing. The more concurrent operations there are, the more identification information is needed, which may increase the risk of identification exhaustion and identification conflicts. Moreover, concurrent operations may also lead to management record conflicts. These management record conflicts, identification exhaustion and identification conflicts themselves, as well as the problems that follow, are becoming increasingly prominent in multi-time dimension management scenarios. Summary of the Invention

[0003] To address at least one of the aforementioned technical problems, embodiments of this application provide a management record processing method and apparatus based on task identifier reuse.

[0004] On one hand, embodiments of this application provide a management record processing method based on task identifier reuse, the method comprising:

[0005] When it is necessary to change the status of the first record, query the mapping record. The mapping record is a record that has the same primary key as the first record and has the same target time period. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0006] If the mapping record is found, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier;

[0007] If the mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier;

[0008] The target node is used to determine the target job identifier and generate the task identifier based on the target job identifier. The target job identifier is a valid job identifier occupied by any node other than the target node in the unidentified provision system.

[0009] In one embodiment, the step of changing the state of the first record based on the task identifier includes:

[0010] A first request exclusive lock is set on the first record. The first request exclusive lock is used to prevent other threads, except the thread that takes over the first request exclusive lock, from processing records that have the same primary key as the first record.

[0011] A target task is generated based on the task identifier, and the target task includes a subtask that changes the state of the first record;

[0012] The target task is executed asynchronously, and the first request exclusive lock is released upon receiving a notification that the target task has been successfully executed.

[0013] In one embodiment, the target node generates the task identifier using the following method:

[0014] If the target node holds a target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier, and the sequence identifier;

[0015] If the target node does not hold the target work identifier, the target database is connected. The target database is used to record the work identifiers currently occupied by each node in the system.

[0016] The target job identifier is determined by communicating with the target database. The target job identifier is a valid job identifier that is not occupied by any node.

[0017] Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

[0018] In one embodiment, when the mapping record is found, reusing the task identifier corresponding to the mapping record and changing the state of the first record based on the task identifier includes:

[0019] Query the second exclusive lock corresponding to the mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the mapping record.

[0020] If the second request exclusive lock exists, extract the task identifier corresponding to the mapping record;

[0021] Based on the task identifier, an asynchronous status query interface is called to obtain the task status of the task corresponding to the mapping record;

[0022] When the task status indicates that the task has been completed, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier.

[0023] In one embodiment, the step of reusing the task identifier corresponding to the mapping record and changing the state of the first record based on the task identifier when the mapping record is found further includes:

[0024] If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the second request for exclusive lock;

[0025] If the locking duration is less than the duration threshold, a message will be displayed indicating that the state change for the first record has failed.

[0026] If the locking duration is greater than or equal to the duration threshold, the second requested exclusive lock is forcibly unlocked;

[0027] The task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

[0028] In one embodiment, the step of reusing the task identifier corresponding to the mapping record and changing the state of the first record based on the task identifier when the mapping record is found further includes:

[0029] In the absence of the second request exclusive lock, the task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

[0030] In one embodiment, the target database records the remaining usage time of the target job identifier, and the target node further performs the following operations:

[0031] Execute a scheduled task, which is used to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero;

[0032] The target database is used to delete the target job identifier when the remaining usage time reaches zero.

[0033] On the other hand, embodiments of this application provide a management record processing device based on task identifier reuse, the device comprising:

[0034] The mapping record query module is used to query the mapping record when it is necessary to change the status of the first record. The mapping record is a record that has the same primary key and the same target time period as the first record. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0035] The record processing module is used to reuse the task identifier corresponding to the mapping record when the mapping record is found, and to change the status of the first record based on the task identifier;

[0036] And, when the mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier;

[0037] The target node is used to determine the target job identifier and generate the task identifier based on the target job identifier. The target job identifier is a valid job identifier occupied by any node other than the target node in the unidentified provision system.

[0038] In one embodiment, the recording processing module is configured to perform the following operations:

[0039] A first request exclusive lock is set on the first record. The first request exclusive lock is used to prevent other threads, except the thread that takes over the first request exclusive lock, from processing records that have the same primary key as the first record.

[0040] A target task is generated based on the task identifier, and the target task includes a subtask that changes the state of the first record;

[0041] The target task is executed asynchronously, and the first request exclusive lock is released upon receiving a notification that the target task has been successfully executed.

[0042] In one embodiment, the recording processing module is configured to perform the following operations:

[0043] If the target node holds a target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier, and the sequence identifier;

[0044] If the target node does not hold the target work identifier, the target database is connected. The target database is used to record the work identifiers currently occupied by each node in the system.

[0045] The target job identifier is determined by communicating with the target database. The target job identifier is a valid job identifier that is not occupied by any node.

[0046] Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

[0047] In one embodiment, the recording processing module is configured to perform the following operations:

[0048] Query the second exclusive lock corresponding to the mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the mapping record.

[0049] If the second request exclusive lock exists, extract the task identifier corresponding to the mapping record;

[0050] Based on the task identifier, an asynchronous status query interface is called to obtain the task status of the task corresponding to the mapping record;

[0051] When the task status indicates that the task has been completed, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier.

[0052] In one embodiment, the recording processing module is configured to perform the following operations:

[0053] If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the second request for exclusive lock;

[0054] If the locking duration is less than the duration threshold, a message will be displayed indicating that the state change for the first record has failed.

[0055] If the locking duration is greater than or equal to the duration threshold, the second requested exclusive lock is forcibly unlocked;

[0056] The task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

[0057] In one embodiment, the recording processing module is configured to perform the following operations:

[0058] In the absence of the second request exclusive lock, the task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

[0059] In one embodiment, the recording processing module is configured to perform the following operations:

[0060] Execute a scheduled task, which is used to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero;

[0061] The target database is used to delete the target job identifier when the remaining usage time reaches zero.

[0062] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described management record processing method based on task identifier reuse.

[0063] On the other hand, embodiments of this application provide an electronic device, including at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the above-described management record processing method based on task identifier reuse by executing the instructions stored in the memory.

[0064] On the other hand, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the aforementioned management record processing method based on task identifier reuse.

[0065] This application provides a management record processing method based on task identifier reuse. When processing management records, reusing the task identifiers corresponding to mapping records reduces the demand for identifier information, saves identifier information, and reduces the risk of identifier exhaustion. In the specific processing, setting a request-exclusive lock avoids management chaos caused by concurrent operations, further ensuring the rigor of management task state changes from a concurrency control perspective, thereby preventing the proliferation of virtual items. In the management record processing, the task state of the task corresponding to the mapping record is considered first, followed by the locking duration corresponding to the request-exclusive lock of the mapping record. Different variables are considered at different stages, making the solution simple to implement and logically clear. There is no situation where the same variable is repeatedly considered at different stages, resulting in a more reasonable logical architecture. This greatly reduces management chaos caused by forced unlocking, while ensuring that reasonable state changes can be implemented smoothly. This application simultaneously reduces the risks of identifier conflicts, identifier exhaustion, management chaos, and the proliferation of virtual items. Attached Figure Description

[0066] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 This is a schematic diagram of the management record processing based on task identifier reuse provided in the embodiments of this specification;

[0068] Figure 2 This is a schematic diagram of the task identifier generation method provided in the embodiments of this specification;

[0069] Figure 3 This is a schematic diagram of the state change execution logic provided in the embodiments of this specification;

[0070] Figure 4 This is a block diagram of a management record processing device based on task identifier reuse provided in an embodiment of this application;

[0071] Figure 5 This is a schematic diagram of the hardware structure of a device for implementing the method provided in the embodiments of this application. Detailed Implementation

[0072] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0073] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0074] To make the objectives, technical solutions, and advantages disclosed in the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application.

[0075] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0076] This application provides a management record processing method based on task identifier reuse. This management record processing method based on task identifier reuse is applied to a virtual item management terminal. The application scenario of the virtual item management terminal is described in the following embodiments.

[0077] As an intermediate management platform, the virtual item management terminal can communicate with the user's electronic devices (including the client that logs into the user's account) and the task publishing platform, thereby decoupling the functions of the task publishing platform and eliminating the need for the task publishing platform to manage virtual items.

[0078] This application does not limit the task publishing platform; it can be considered any task publishing platform connected to the aforementioned virtual item management terminal, or any task publishing platform that subscribes to the virtual item management service of the aforementioned virtual item management terminal. For example, the task publishing platform can be a game program server, which can publish game tasks to users, but users can obtain virtual item rewards from the game tasks through the virtual item management terminal in this application embodiment, and the server can decouple the management functions related to virtual item rewards in the game tasks. As another example, the task publishing platform can be a live streaming program server, which can publish live streaming tasks to users, but users can obtain virtual item rewards from the live streaming tasks through the virtual item management terminal in this application embodiment, and the server can decouple the management functions related to virtual item rewards in the live streaming tasks. This application does not limit the type or number of task publishing platforms connected.

[0079] The target object in this application embodiment can be understood as the virtual object corresponding to a user who performs a task on any of the aforementioned task publishing platforms. The target object should receive virtual items issued by the task publishing platform as a reward for performing the task. However, the virtual items in this application embodiment can be issued by the virtual item management terminal. That is, the task publishing platform can entrust the virtual item management terminal to issue the virtual items by signing a service agreement.

[0080] It should be noted that the virtual item management terminal in this application embodiment can provide delivery services for the target object at different time dimensions. For example, it can deliver virtual items on a weekly or monthly basis according to the target object's behavior on the task publishing platform, thereby supporting the delivery of virtual items at multiple time dimensions and meeting the user's needs for obtaining virtual items at multiple time dimensions. For example, the virtual item management terminal can deliver a portion of virtual items to the user weekly and another portion of virtual items to the user monthly, thereby meeting the user's needs for obtaining virtual items at multiple time dimensions.

[0081] However, satisfying the demand for virtual items across multiple time dimensions brings challenges to virtual item management; specifically, this feature introduces difficulties in managing the status of virtual item management records. Inaccurate management of the status of virtual item management records could lead to the proliferation of virtual items.

[0082] For example, based on the behavior information of an object A from August 7th to August 13th, a virtual item worth 500 virtual coins is issued to it in the corresponding "week". Of course, there is a corresponding record in the virtual item management terminal, namely record 1. Assuming that the state of record 1 is state 1 at this time, it means that the virtual item in record 1 has been issued.

[0083] When distributing virtual items monthly, based on the behavior of object A in August, virtual items worth 5000 virtual coins should be distributed to them. Of course, there is a corresponding record in the virtual item management terminal, namely record 2. Assuming that the status of record 2 is state 2 at this time, it means that the virtual items in record 2 have not yet been distributed.

[0084] When determining the virtual items to be distributed in August based on Record 1 and Record 2 and their respective states, normally 5000-500=4500 virtual items should be distributed. However, because the order in which Record 1 and Record 2 are generated is not unique, and the order in which the states of Record 1 and Record 2 change cannot be preset, the final total amount of virtual items to be distributed monthly based on Record 1 and Record 2 and their respective states may be inaccurate, resulting in over-distribution issues.

[0085] For example, suppose record 1 is generated first, but because the virtual item worth 500 virtual coins has not yet been issued, the state of record 1 is not state 1. In this case, if record 2 is generated, the virtual item requested in both record 1 and record 2 may be issued, that is, 5000 + 500 = 5500 virtual items will be issued, resulting in over-issuance.

[0086] To address the challenges of managing the status of virtual item acquisition records across multiple time dimensions, and to ensure accurate circulation of virtual items by preventing multiple acquisitions, strict control over the status of related management records is necessary. This application provides a status control method that avoids the problem of multiple acquisitions. This method can also be considered the foundational solution for management record processing based on task identifier reuse in this application, including:

[0087] S101. Upon receiving a status change request for the first record, determine the target time period information of the first record, wherein the first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0088] This application embodiment supports the state transition of management records under multiple time dimensions. For example, it can support weekly and monthly dimensions. If the target time period information represents the weekly dimension, then the first record records the quantity information of virtual items within a week; if the target time period information represents the monthly dimension, then the first record records the quantity information of virtual items within a month.

[0089] S102. When the target time period information represents the first type of time period, the status of the first record is changed, and the first type of time period is the minimum time period for generating management records.

[0090] In this embodiment, the first type of time period is the minimum time period for generating management records. Taking the virtual item management terminal as supporting weekly and monthly dimensions as an example, the first type of time period is "week". For this type of time period-related first record, the status of the first record can be directly changed. This is because this embodiment avoids the problem of multiple issuances in the virtual item issuance process under non-minimum time periods, while not limiting the issuance of virtual items under the minimum time period. The issuance of items under the minimum time period can be carried out directly. This solution reduces the impact of status management on the issuance process under the minimum time period, and ensures that virtual item issuance can be carried out in all time periods without the technical effect of multiple issuances.

[0091] S103. When the target time period information represents the second type of time period, query all the second records associated with the first record. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0092] The second type of time period is obviously not the minimum time period. Taking the virtual item management terminal as an example, which supports weekly and monthly dimensions, the second type of time period is "month". First, you can query the records related to each "week" in that month, that is, all the second records mentioned above.

[0093] S104. If the first record is not associated with any second record, change the status of the first record.

[0094] If the first record is not associated with any second record, it means that there are no virtual items paid out weekly that month. Therefore, there will be no over-issuance due to the weekly payment of virtual items. Virtual items can be distributed directly based on the first record on a monthly basis without over-issuance.

[0095] In this embodiment, the state change of the first record is considered to be made only after fully considering that it will not lead to multiple issuances. This is because the state change of the first record in this embodiment is directly related to the issuance of virtual items. Therefore, in this embodiment, the state change is strictly managed to ensure that multiple issuances of virtual items do not occur.

[0096] S105. When all the second records associated with the first record are in the first state, the state of the first record is changed; the first state indicates that the virtual item associated with the corresponding second record has been sent to the target object.

[0097] If there are situations in the month where virtual items may need to be issued weekly, i.e. there are second records, and if these second records are all in the first state, that is, the virtual items in these second records have been settled weekly, then when settling virtual items monthly, it is only necessary to deduct these pre-settled virtual items, and there will be no over-issuance. In this case, the state of the first record mentioned above can also be changed.

[0098] S106. If a target second record exists, no state change is performed on the first record. The target second record is a second record that is not in the first state.

[0099] If there is a second record (target second record) that is not in the first state, it means that the virtual items in the target second record are ready to be distributed on a weekly basis. However, this action has not yet been implemented. In this case, it is possible that after the virtual items are distributed monthly, the virtual items in the target second record will be settled again, resulting in multiple distributions. In this case, the embodiments of this application directly do not allow the state change of the first record. Preventing the state change of the first record prevents the distribution of virtual items in the first record, thereby avoiding the occurrence of multiple distributions. Only after the target second record is properly handled can the state change of the first record be carried out again to ensure that multiple distributions will not occur.

[0100] In the above technical solution, multiple occurrences are avoided through strict state change control. However, this method does not take into account the situation of multiple concurrency. For example, if two administrators trigger state change requests for the first record one after the other, if the two management records targeting the same target object and the same time period are not intervened, the triggering operations of the two administrators may affect each other. The first record seen by the second administrator is not the management record uploaded by itself, but the management record uploaded by the first administrator, causing management confusion. Management confusion may also lead to the recurrence of multiple occurrence problems.

[0101] To ensure the avoidance of multiple occurrences of the problem, this application embodiment further strengthens concurrency control while maintaining strict state change control. It avoids the problem of multiple virtual items arising due to concurrency issues, while supporting high concurrency, thus proposing a management record processing method based on task identifier reuse. Figure 2 This document illustrates a flowchart of a management record processing method based on task identifier reuse, provided in an embodiment of this application. This method also operates on a virtual item management terminal. While the embodiments and flowcharts describe the method's operational steps, more or fewer steps may be included based on conventional or non-inventive methods. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual systems, terminal devices, or server products, the method can be executed sequentially or in parallel (e.g., using parallel processors or multi-threaded processing environments) as shown in the embodiments or accompanying drawings. The above method may include:

[0102] S201. When it is necessary to change the status of the first record, query the mapping record. The mapping record is a record that has the same primary key as the first record and has the same target time period. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0103] This application embodiment can receive a status change request for a first record, determine whether a status change is required upon receiving the request, and execute step S201 if it is determined that a status change is required. For details on how to determine whether a status change is required upon receiving a status change request for a first record, please refer to the preceding text, which will not be repeated here.

[0104] In this embodiment, the aforementioned status change request can be a preview request or an entry request. A preview request provides the client with a preview function for management records. An entry request provides the client with both preview and entry functions for management records. In this embodiment, only virtual items in management records that have been entered into the database and set to the first state can be distributed to their corresponding objects.

[0105] In this embodiment, the state of the management record after the preview request is implemented is referred to as the second state, in which the management record has not been entered into the database. In this embodiment, the state of the management record after the entry request is implemented is referred to as the third state, in which the management record has been entered into the database but has not yet taken effect. This is the difference between the third state and the first state.

[0106] For the first record, if a preview request is received, the client can view the content related to the first record by accessing the virtual item management terminal. However, the content of the first record has not yet been entered into the database of the virtual item management terminal, meaning the first record can be set to the second state. If an entry request is received for the first record, the client can view the content related to the first record by accessing the virtual item management terminal and enter the content of the first record into the database of the virtual item management terminal, meaning the first record can be set to the third state.

[0107] Taking the aforementioned status change request as a preview request as an example, before determining the target time period information of the first record upon receiving the status change request for the first record, the process further includes:

[0108] S301. Obtain behavioral performance information, wherein the behavioral performance information is the performance information of the target object in the target time period related to the virtual item.

[0109] For example, if a target receives virtual items by completing a game task on task publishing platform 1, then the behavioral information refers to the target's game task execution status during the target time period. If a target receives virtual items by completing a media resource editing task on task publishing platform 2, then the behavioral information refers to the target's media resource editing task execution status during the target time period.

[0110] S302. Based on the first identifier, the second identifier, and the aforementioned behavioral performance information, generate a first record, wherein the first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0111] The first identifier can be the identifier of task publishing platform 1 or task publishing platform 2, and the second identifier can be the identifier of an administrator belonging to the virtual item management terminal. The virtual item management terminal can be configured with multiple administrators, each of whom is responsible for managing the task execution status of multiple users on various task publishing platforms, as well as managing the corresponding management records for these multiple users on the virtual item management terminal. In this case, the primary key of the generated first record is "first identifier and second identifier".

[0112] S303. Generate the above preview request based on the first record mentioned above.

[0113] Taking the aforementioned status change request as an inbound request as an example, the inbound request is used to change the aforementioned first record to the third status. Before determining the target time period information of the aforementioned first record upon receiving the status change request for the first record, the process further includes:

[0114] S401. Obtain behavioral performance information, which is the performance information of the target object related to virtual items during the target time period.

[0115] S402. Based on the first identifier, the second identifier, and the aforementioned behavioral performance information, generate a first record, wherein the first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0116] S403. Generate the above-mentioned inbound request based on the first record.

[0117] The generation method for the inbound request is similar to that of the preview request, and will not be repeated in this embodiment. Both the inbound request and the preview request can be triggered and generated by the administrator of the virtual item management terminal and transmitted to the virtual item management terminal. In a specific embodiment, generating a first record based on the first identifier, the second identifier, and the aforementioned behavioral information can specifically include: generating the first record based on the first identifier, the second identifier, the third identifier, and the aforementioned behavioral information, where the third identifier is the identity identifier of the target object. In this case, the primary key of the generated first record is "first identifier and second identifier and third identifier". The primary key setting is more granular than that described above, enabling more refined management of the record's status.

[0118] S202. If the above mapping record is found, reuse the task identifier corresponding to the above mapping record, and change the status of the above first record based on the above task identifier.

[0119] This application does not limit the task corresponding to the mapping record; it may include subtasks that modify the state of the mapping record. By reusing the task identifier corresponding to the mapping record, the task identifier can be used to its fullest potential, eliminating the need to generate new identifiers and reducing the risk of identifier exhaustion.

[0120] In some embodiments, the above-mentioned state change of the first record based on the task identifier includes: setting a first request exclusive lock on the first record, the first request exclusive lock being used to prevent other threads, except the takeover thread of the first request exclusive lock, from processing records that have the same primary key as the first record; generating a target task based on the task identifier, the target task including a subtask of changing the state of the first record; asynchronously executing the target task, and releasing the first request exclusive lock after receiving a notification that the target task has been successfully executed.

[0121] Specifically, the status of the first record can be changed to the second or third status. If the status change is successful, the exclusive lock of the first request is deleted. Specifically, if it is a preview request, it is changed to the second status; if it is an inbound request, it is changed to the third status. Of course, an inbound operation also needs to be performed, but the inbound operation is not the focus of this application and will not be elaborated on.

[0122] In this embodiment, a locking mechanism is required to ensure the uniqueness of the state change operation on the first record. The first request-exclusive lock used in this embodiment is a request-exclusive lock, or a thread-exclusive lock, designed to prevent threads other than the thread that takes over the first request-exclusive lock from processing records with the same primary key as the first record. If the virtual item management terminal receives a state change request for another record with the same primary key as the first record after the first record, then other threads, except for the thread that takes over the first request-exclusive lock, cannot operate on the first record or the other record. This ensures that the state change of the first record is unaffected and proceeds smoothly without being interfered with by concurrency.

[0123] The state change of the first record is implemented by a specific task. This task can perform the state change, and at least one of the following operations: managing record entry, managing record verification, etc. This task is executed asynchronously, thus making full use of the concurrent resources of the virtual item management terminal. The task identifier of this task is obtained through the task identifier corresponding to the reused mapping task. After the task is completed, a notification is sent so that the virtual item management terminal can release the exclusive lock of the first request after receiving the notification that the target task has been successfully executed.

[0124] S203. If the above mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier.

[0125] The aforementioned target node is used to determine the target job identifier and generate the aforementioned task identifier based on the aforementioned target job identifier. The aforementioned target job identifier is a valid job identifier occupied by any node other than the aforementioned target node in the unidentified provision system.

[0126] The state change method in step S203 can be referred to step S202, and will not be repeated here.

[0127] The ability to autonomously generate high-quality, highly unique identifiers is essential for almost any system requiring high throughput. In this embodiment, the virtual item management terminal needs to process management records with high concurrency, and the uniqueness of each management record must be guaranteed by a corresponding identifier. In this embodiment, based on functional decoupling considerations, a dedicated component—an identifier providing system—is set up. This identifier providing system includes multiple nodes, each with the independent ability to provide identifiers, and ensures that each identifier generated by each node is highly unique.

[0128] In this embodiment, the identifier providing system uses the snowflake algorithm to generate identifiers. For details of the snowflake algorithm, please refer to related technologies; this embodiment will not elaborate further. Currently, the snowflake algorithm in related technologies can ultimately generate identifiers based on work identifier information, timestamp identifier information, and sequence identifier information. However, because related technologies cannot guarantee the strong uniqueness of work identifier information, the identifiers obtained based on the snowflake algorithm can only achieve probabilistic uniqueness, not absolute uniqueness. Therefore, this embodiment sets up a target work identifier based on a target node, and limits this target work identifier to a valid work identifier that is not occupied by any node in the identifier providing system other than the target node. This ensures that the target work identifier will not be used by other nodes in the identifier providing system other than the target node. Naturally, the identifiers generated by other nodes cannot be the same as the identifier generated by the target node, thus ensuring that the identifier generated by the target node has strong uniqueness rather than probabilistic uniqueness. This embodiment does not limit the target node; it can be understood as any node.

[0129] Specifically, the target node generates the task identifier using the following method:

[0130] S501. If the target node holds the target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier and the sequence identifier.

[0131] For the meaning and acquisition method of timestamp and sequence identifiers, please refer to the relevant technologies of the Snowflake Algorithm, which will not be elaborated here.

[0132] S502. If the target node does not hold the target work identifier, connect to the target database, which is used to record the work identifiers currently occupied by each node in the system;

[0133] S503. Determine the target working identifier by communicating with the aforementioned target database. The aforementioned target working identifier is a valid working identifier that is not occupied by any node.

[0134] In this embodiment of the application, a valid work identifier is a work identifier that is located within the work identifier range defined by the snowflake algorithm.

[0135] S504. Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

[0136] In some embodiments, the target database records the remaining usage time of the target job identifier, and the target node further performs the following operations: executing a scheduled task to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero; and the target database is used to delete the target job identifier when the remaining usage time reaches zero.

[0137] By using scheduled tasks, it can be ensured that new identifiers are continuously provided to the virtual item management terminal by holding the target working identifier, as long as the target node does not crash. The new identifiers will never overlap with the old identifiers. If the target node crashes, the target working identifier will be released in the target database, and then the target working identifier can be used by other nodes to continue to provide new identifiers to the virtual item management terminal. This will not cause the risk of working identifier exhaustion due to the target node crash, which largely avoids the exhaustion of identifiers.

[0138] In some embodiments, the state change execution logic may refer to Figure 3 Specifically, this includes the following operations:

[0139] S601. Query the second exclusive lock corresponding to the above mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the above mapping record.

[0140] In this embodiment, the purpose of setting the second exclusive lock is to prevent threads other than the thread that takes over the second exclusive lock from processing records that have the same primary key as the mapping record. Since the first record and the mapping record have the same primary key, threads other than the thread that takes over the second exclusive lock cannot operate on the first record and the mapping record. The currently running thread is the response thread for the first record, and obviously is not the thread that takes over the second exclusive lock, so it cannot change the state of the first record. In other words, if the second exclusive lock is valid, it may prevent the currently running thread from performing a state change operation.

[0141] S602. If the aforementioned second request exclusive lock exists, extract the task identifier corresponding to the aforementioned mapping record.

[0142] S603. Based on the above task identifier, call the asynchronous status query interface to obtain the task status of the task corresponding to the above mapping record.

[0143] This application embodiment considers the task status of the task corresponding to the mapping record as the decisive factor in whether the second request-exclusive lock should exist. Simply put, if the task has already been completed, even if the second request-exclusive lock still exists, it's due to some program defect or network fluctuation. In this case, the second request-exclusive lock should not exist, and therefore can be forcibly unlocked. Conversely, the second request-exclusive lock may still have a reason to exist, and other factors need to be considered before deciding whether to forcibly unlock it. This step is the key to this application embodiment, directly identifying the fundamental reason why the second request-exclusive lock should not exist. Prioritizing the primary reason allows for a quicker and more reasonable conclusion on whether to forcibly unlock it.

[0144] S604. When the task status indicates that the task has been completed, reuse the task identifier corresponding to the mapping record and change the status of the first record based on the task identifier.

[0145] S605. If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the exclusive lock requested above.

[0146] S606. If the above locking duration is less than the duration threshold, a message will be displayed indicating that the status change for the first record failed.

[0147] S607. If the above-mentioned locking duration is greater than or equal to the above-mentioned duration threshold, the above-mentioned second request exclusive lock is forcibly unlocked; the task identifier corresponding to the above-mentioned mapping record is reused, and the state of the above-mentioned first record is changed based on the above-mentioned task identifier.

[0148] In this embodiment, the duration threshold can be set slightly longer, for example, 20 minutes. If the second request exclusive lock is not released before the duration threshold is reached, it can be determined that the task corresponding to the mapping record is likely dead and will not cause the result of multiple virtual items. In this case, it is okay to forcibly release the second request exclusive lock. Conversely, it can be assumed that the task corresponding to the mapping record is likely not dead and the second request exclusive lock cannot be released. In this case, the state of the first record cannot be changed rashly. Therefore, the state change of the first record is prompted as failed.

[0149] S608. In the absence of the aforementioned second request exclusive lock, reuse the task identifier corresponding to the aforementioned mapping record, and perform a state change on the aforementioned first record based on the aforementioned task identifier.

[0150] This application provides a management record processing method based on task identifier reuse. When processing management records, reusing the task identifiers corresponding to mapping records reduces the demand for identifier information, saving identifier information and reducing the risk of identifier exhaustion. In the specific processing, setting a request-exclusive lock avoids management chaos caused by concurrent operations, further ensuring the rigor of management task state changes from a concurrency control perspective, thereby preventing the proliferation of virtual items. In the management record processing, the task state of the task corresponding to the mapping record is considered first, followed by the locking duration corresponding to the request-exclusive lock of the mapping record. Different variables are considered at different stages, making the solution simple to implement and logically clear. There is no situation where the same variable is repeatedly considered at different stages, resulting in a more reasonable logical architecture. This greatly reduces management chaos caused by forced unlocking, while ensuring that reasonable state changes can be implemented smoothly. This application simultaneously reduces the risks of identifier conflicts, identifier exhaustion, management chaos, and the proliferation of virtual items.

[0151] Please refer to Figure 4 The diagram illustrates a block diagram of a management record processing device based on task identifier reuse in this embodiment. The device includes:

[0152] The mapping record query module 401 is used to query the mapping record when it is necessary to change the status of the first record. The mapping record is a record that has the same primary key and the same target time period as the first record. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0153] The record processing module 402 is used to reuse the task identifier corresponding to the above-mentioned mapping record when the above-mentioned mapping record is found, and to change the status of the above-mentioned first record based on the above-mentioned task identifier.

[0154] And, when the above mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and make a status change on the above first record based on the task identifier;

[0155] The aforementioned target node is used to determine the target job identifier and generate the aforementioned task identifier based on the aforementioned target job identifier. The aforementioned target job identifier is a valid job identifier occupied by any node other than the aforementioned target node in the unidentified provision system.

[0156] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0157] A first request exclusive lock is set on the first record mentioned above. The first request exclusive lock is used to prevent other threads, except the thread that takes over the first request exclusive lock, from processing records that have the same primary key as the first record.

[0158] A target task is generated based on the above task identifier, and the target task includes a subtask that changes the state of the above first record.

[0159] The target task described above is executed asynchronously, and the exclusive lock for the first request is released upon receiving notification that the target task has been successfully executed.

[0160] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0161] If the target node holds the target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier and the sequence identifier.

[0162] If the target node does not hold the target work identifier, connect to the target database, which is used to record the work identifiers currently occupied by each node in the system.

[0163] The target working identifier is determined by communicating with the aforementioned target database. The aforementioned target working identifier is a valid working identifier that is not occupied by any node.

[0164] Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

[0165] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0166] Query the second exclusive lock corresponding to the above mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the above mapping record.

[0167] If the aforementioned second request exclusive lock exists, extract the task identifier corresponding to the aforementioned mapping record;

[0168] Based on the above task identifier, call the asynchronous status query interface to obtain the task status of the task corresponding to the above mapping record;

[0169] When the task status indicates that the task has been completed, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier.

[0170] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0171] If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the exclusive lock requested above.

[0172] If the locking duration is less than the duration threshold, a message will be displayed indicating that the status change for the first record failed.

[0173] If the above-mentioned locking duration is greater than or equal to the above-mentioned duration threshold, the above-mentioned second request exclusive lock shall be forcibly unlocked;

[0174] The task identifier corresponding to the above mapping record is reused, and the state of the above first record is changed based on the above task identifier.

[0175] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0176] In the absence of the aforementioned second exclusive lock, the task identifier corresponding to the aforementioned mapping record is reused, and the state of the aforementioned first record is changed based on the aforementioned task identifier.

[0177] In one embodiment, the above-mentioned recording processing module is used to perform the following operations:

[0178] Execute a scheduled task to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero.

[0179] The aforementioned target database is used to delete the aforementioned target job identifier when the remaining usage time reaches zero.

[0180] The device embodiments and method embodiments are based on the same inventive concept, and will not be described in detail.

[0181] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described management record processing method based on task identifier reuse.

[0182] The apparatus portion of the embodiments in this application is based on the same inventive concept as the method embodiment, and will not be described in detail here.

[0183] Furthermore, Figure 5 A schematic diagram of a hardware structure for implementing the method provided in the embodiments of this application is shown. This device can participate in or include the apparatus or system provided in the embodiments of this application. Figure 5As shown, device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown.

[0184] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element within device 10 (or mobile device). As involved in the embodiments of this application, this data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0185] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-described management record processing method based on task identifier reuse. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0186] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0187] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0188] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0189] The embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0190] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0191] The instructions in the aforementioned storage medium can execute a management record processing method based on task identifier multiplexing, the method including:

[0192] When it is necessary to change the status of the first record, query the mapping record. The mapping record is a record that has the same primary key and the same target time period as the first record. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0193] If the above mapping record is found, the task identifier corresponding to the above mapping record is reused, and the status of the above first record is changed based on the above task identifier.

[0194] If the above mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier.

[0195] The aforementioned target node is used to determine the target job identifier and generate the aforementioned task identifier based on the aforementioned target job identifier. The aforementioned target job identifier is a valid job identifier occupied by any node other than the aforementioned target node in the unidentified provision system.

[0196] In one embodiment, the above-mentioned state change of the first record based on the task identifier includes:

[0197] A first request exclusive lock is set on the first record mentioned above. The first request exclusive lock is used to prevent other threads, except the thread that takes over the first request exclusive lock, from processing records that have the same primary key as the first record.

[0198] A target task is generated based on the above task identifier, and the target task includes a subtask that changes the state of the above first record.

[0199] The target task described above is executed asynchronously, and the exclusive lock for the first request is released upon receiving notification that the target task has been successfully executed.

[0200] In one embodiment, the target node generates the task identifier using the following method:

[0201] If the target node holds the target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier and the sequence identifier.

[0202] If the target node does not hold the target work identifier, connect to the target database, which is used to record the work identifiers currently occupied by each node in the system.

[0203] The target working identifier is determined by communicating with the aforementioned target database. The aforementioned target working identifier is a valid working identifier that is not occupied by any node.

[0204] Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

[0205] In one embodiment, when the mapping record is found, reusing the task identifier corresponding to the mapping record and changing the state of the first record based on the task identifier includes:

[0206] Query the second exclusive lock corresponding to the above mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the above mapping record.

[0207] If the aforementioned second request exclusive lock exists, extract the task identifier corresponding to the aforementioned mapping record;

[0208] Based on the above task identifier, call the asynchronous status query interface to obtain the task status of the task corresponding to the above mapping record;

[0209] When the task status indicates that the task has been completed, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier.

[0210] In one embodiment, the method of reusing the task identifier corresponding to the mapping record and changing the status of the first record based on the task identifier when the mapping record is found further includes:

[0211] If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the exclusive lock requested above.

[0212] If the locking duration is less than the duration threshold, a message will be displayed indicating that the status change for the first record failed.

[0213] If the above-mentioned locking duration is greater than or equal to the above-mentioned duration threshold, the above-mentioned second request exclusive lock shall be forcibly unlocked;

[0214] The task identifier corresponding to the above mapping record is reused, and the state of the above first record is changed based on the above task identifier.

[0215] In one embodiment, the method of reusing the task identifier corresponding to the mapping record and changing the status of the first record based on the task identifier when the mapping record is found further includes:

[0216] In the absence of the aforementioned second exclusive lock, the task identifier corresponding to the aforementioned mapping record is reused, and the state of the aforementioned first record is changed based on the aforementioned task identifier.

[0217] In one embodiment, the target database records the remaining usage time of the target job identifier, and the target node further performs the following operations:

[0218] Execute a scheduled task to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero.

[0219] The aforementioned target database is used to delete the aforementioned target job identifier when the remaining usage time reaches zero.

[0220] The above are merely preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present application should be included within the protection scope of the present application.

Claims

1. A management record processing method based on task identifier reuse, characterized in that, The method includes: When it is necessary to change the status of the first record, query the mapping record. The mapping record is a record that has the same primary key as the first record and has the same target time period. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period. If the mapping record is found, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier; If the mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier; The target node is used to determine the target job identifier and generate the task identifier based on the target job identifier. The target job identifier is a valid job identifier occupied by any node other than the target node in the system that is not identified. The step of changing the state of the first record based on the task identifier includes: setting a first request exclusive lock on the first record, the first request exclusive lock being used to prevent other threads, except the takeover thread of the first request exclusive lock, from processing records that have the same primary key as the first record; generating a target task based on the task identifier, the target task including a subtask of changing the state of the first record; asynchronously executing the target task, and releasing the first request exclusive lock after receiving a notification that the target task has been successfully executed.

2. The method according to claim 1, characterized in that, The target node generates the task identifier using the following method: If the target node holds a target work identifier, obtain the timestamp identifier and the sequence identifier, and generate the task identifier based on the target work identifier, the timestamp identifier, and the sequence identifier; If the target node does not hold the target work identifier, the target database is connected. The target database is used to record the work identifiers currently occupied by each node in the system. The target job identifier is determined by communicating with the target database. The target job identifier is a valid job identifier that is not occupied by any node. Obtain the timestamp identifier and sequence identifier, and generate the task identifier based on the target task identifier, the timestamp identifier, and the sequence identifier.

3. The method according to claim 1, characterized in that, When the mapping record is found, reusing the task identifier corresponding to the mapping record and changing the status of the first record based on the task identifier includes: Query the second exclusive lock corresponding to the mapping record. The second exclusive lock is used to prevent other threads, except the thread that takes over the second exclusive lock, from processing records that have the same primary key as the mapping record. If the second request exclusive lock exists, extract the task identifier corresponding to the mapping record; Based on the task identifier, an asynchronous status query interface is called to obtain the task status of the task corresponding to the mapping record; When the task status indicates that the task has been completed, the task identifier corresponding to the mapping record is reused, and the status of the first record is changed based on the task identifier.

4. The method according to claim 3, characterized in that, The step of reusing the task identifier corresponding to the mapping record and changing the status of the first record based on the task identifier when the mapping record is found further includes: If the task status indicates that the task has not been completed, obtain the locking duration corresponding to the second request for exclusive lock; If the locking duration is less than the duration threshold, a message will be displayed indicating that the state change for the first record has failed. If the lock duration is greater than or equal to the duration threshold, the second request exclusive lock is forcibly unlocked, the task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

5. The method according to claim 3, characterized in that, The step of reusing the task identifier corresponding to the mapping record and changing the status of the first record based on the task identifier when the mapping record is found further includes: In the absence of the second request exclusive lock, the task identifier corresponding to the mapping record is reused, and the state of the first record is changed based on the task identifier.

6. The method according to claim 3, characterized in that, The target database records the remaining usage time of the target job identifier, and the target node also performs the following operations: Execute a scheduled task, which is used to reset the remaining usage time of the target job identifier before the remaining usage time reaches zero; The target database is used to delete the target job identifier when the remaining usage time reaches zero.

7. A management record processing device based on task identifier reuse, characterized in that, The device includes: The mapping record query module is used to query the mapping record when it is necessary to change the status of the first record. The mapping record is a record that has the same primary key and the same target time period as the first record. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period. The record processing module is used to reuse the task identifier corresponding to the mapping record when the mapping record is found, and to change the status of the first record based on the task identifier; And, when the mapping record is not found, communicate with the target node in the identifier providing system to obtain the task identifier, and change the status of the first record based on the task identifier; The target node is used to determine the target job identifier and generate the task identifier based on the target job identifier. The target job identifier is a valid job identifier occupied by any node other than the target node in the system that is not identified. The step of changing the state of the first record based on the task identifier includes: setting a first request exclusive lock on the first record, the first request exclusive lock being used to prevent other threads, except the takeover thread of the first request exclusive lock, from processing records that have the same primary key as the first record; generating a target task based on the task identifier, the target task including a subtask of changing the state of the first record; asynchronously executing the target task, and releasing the first request exclusive lock after receiving a notification that the target task has been successfully executed.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement a management record processing method based on task identifier reuse as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, The system includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements a management record processing method based on task identifier reuse as described in any one of claims 1 to 6 by executing the instructions stored in the memory.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the management record processing method based on task identifier reuse as described in any one of claims 1 to 6.

Images