Task processing method, electronic equipment, storage medium and program product

Abstract

The invention provides a task processing method, electronic equipment, a storage medium and a program product. The method comprises the steps of determining at least one resource operation task to be created, wherein the resource operation task is an operation task related to account resources; when the at least one resource operation task is created, allocating a task identifier to each resource operation task in the at least one resource operation task; the task identifier is determined based on the primary key and the creation time of the primary key; and executing the at least one resource operation task.

Description

Technical Field

[0001] This application relates to the technical field of account resource management, and more particularly to a task processing method, electronic device, storage medium, and program product. Background Technology

[0002] In scenarios involving suspending, resuming, or canceling user accounts, corresponding operations need to be performed on the account resources under the user's name. In related technologies, when managing operation tasks related to account resources, it is usually necessary to assign an ID to each operation task. However, the task ID allocation schemes used in these technologies are overly complex and lack simplicity and ease of use. Summary of the Invention

[0003] This application provides a task processing method, electronic device, storage medium, and program product that can reduce the complexity of assigning operation task IDs when managing operation tasks related to account resources.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a task processing method, the method comprising: Identify at least one resource operation task to be created, wherein the resource operation task is an operation task related to account resources; When creating the at least one resource operation task, a task identifier is assigned to each of the at least one resource operation tasks; the task identifier is determined based on the primary key and the creation time of the primary key; Execute the at least one resource operation task.

[0005] This application also provides an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor; wherein the processor is used to run the computer program to perform any of the above-described task processing methods.

[0006] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the above-described task processing methods.

[0007] This application also provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements any of the above-described task processing methods.

[0008] The embodiments of this application have the following beneficial effects: When creating resource operation tasks, the embodiments of this application do not require a complex mechanism to assign task identifiers to resource operation tasks. Instead, the task identifiers of resource operation tasks can be easily determined based on the primary key and the creation time of the primary key, which reduces the implementation complexity of the task identifier allocation scheme and is conducive to the efficient execution of resource operation tasks. Attached Figure Description

[0009] Figure 1 This is a flowchart of a task processing method according to an embodiment of this application; Figure 2 This is a structure diagram of the task ID generated in the embodiments of this application; Figure 3 This is a flowchart illustrating the creation of machine code in an embodiment of this application; Figure 4 This is a flowchart illustrating the real-time response to account operation instructions and the retrieval of order instances in an embodiment of this application. Figure 5 This is a schematic diagram of the structure of the task processing device according to an embodiment of this application; Figure 6 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] To address the operational needs of order resources under a user's name in scenarios involving changes in user status (such as pause, resume, or cancellation), some solutions for managing operation tasks related to account resources have been proposed in related technologies.

[0011] In the first technical solution related to this technology, account resource-related operation tasks can be managed based on an asynchronous processing mechanism. In this solution, by submitting order resource operation requests to the backend processing queue asynchronously, system blocking or response delays that may occur due to direct synchronous processing are avoided. The asynchronous processing mechanism not only significantly improves user experience but also optimizes resource allocation, making the system more stable and efficient when facing high concurrency or resource constraints. Under this mechanism, the system responds quickly to user operations and provides feedback to the user through notifications, log recordings, or interface updates, enhancing the immediacy and transparency of operations.

[0012] In the second technical solution related to this technology, account resource-related operation tasks can be managed based on a message listening mechanism. As another powerful processing method, the message listening mechanism relies on message queues (such as RabbitMQ, Kafka, etc.) to decouple and asynchronously process order resource operation requests. When a user's state changes, the system generates a corresponding message and delivers it to the message queue. The message listener is responsible for listening to these messages and executing the corresponding order resource operations based on the message content. This approach not only reduces the coupling between system components and improves the system's scalability and maintainability, but also effectively smooths out processing peaks through the buffering capacity of the message queue, enhancing the overall stability and processing capacity of the system.

[0013] In the third technical solution of the related technology, when managing operation tasks related to account resources, it is necessary to assign an ID to each operation task. However, the implementation process of the task ID allocation method used in this solution is too complicated and lacks simplicity and ease of use.

[0014] The technical solutions of related technologies have at least the following technical problems: 1) Universally Unique Identifier (UUID) generation schemes suffer from drawbacks such as being either overly random or overly complex. Related technologies offer UUID generation schemes that are too extreme, some utility classes generate UUIDs that are too random, and some open-source generators are overly complex. For example, while commonly used ID generators have a relatively sound mechanism for generating IDs, their implementation process is too complex, making them suitable for scenarios with extremely high concurrency but not for generating task IDs. Meanwhile, some utility classes that randomly generate UUIDs are too arbitrary, with a small probability of resulting in duplicate IDs.

[0015] 2) Limited Order Tracking and Ambiguous Status Transitions. For orders managing account resource-related tasks, the long-process order solutions employed in related technologies suffer from ambiguous tracking. A single status code cannot effectively record the order's lifecycle, and it's impossible to trace the order process later. Specifically, for orders managing account resource-related tasks, most order frameworks in related technologies typically use a "status identifier" approach. All operations within the order's lifecycle, including ordering, renewal, pause, and resumption, are identified using status codes. The drawback is that it cannot clearly record the order's lifecycle; it only indicates the current status of the order.

[0016] 3) The triggering conditions for account operations in the relevant technology are quite stringent. Account suspension, resumption, or cancellation is only permitted when there are no outstanding orders under the user's name; otherwise, internal processing is impossible. This is not applicable to cloud product orders. Since cloud products are long-term orders, it is unreasonable to prevent a user from suspending an order if the user is in arrears but has an outstanding order for an extended period.

[0017] 4) Insufficient persistence capabilities. Some message queue (MQ) based solutions are limited by the characteristics of MQ itself, and have potential risks such as insufficient persistence capabilities, duplicate consumption, and message backlog. If not optimized properly, it can easily lead to order failures.

[0018] To address the technical problems existing in related technologies, this application proposes a technical solution based on its embodiments. This application primarily addresses scenarios involving the suspension, restoration, and cancellation of user accounts, executing user account resource operation tasks. Since a user may have a large number of complex operation orders for account resources, it is highly likely that orders cannot be executed, affecting customer experience and billing accuracy. To address this scenario, this application proposes a task processing method, electronic device, storage medium, and program product, enabling account resource operation functions based on scheduled tasks.

[0019] 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 embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0020] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0021] The task processing method provided in this application includes a series of steps, but the task processing method provided in this application is not limited to the steps described. Similarly, the task processing device provided in this application includes a series of modules, but the device provided in this application is not limited to the modules explicitly described, and may also include modules that need to be set up for obtaining relevant information or processing based on information.

[0022] This application provides a task processing method. Figure 1 This is a flowchart of a task processing method according to an embodiment of this application, such as... Figure 1 As shown, the process includes: Step 101: Identify at least one resource operation task to be created. A resource operation task is an operation task related to account resources.

[0023] For example, account resource-related operation tasks include one or more of the following: account suspension, account recovery, and account cancellation. In practical applications, the customer management module can determine at least one resource operation task to be created.

[0024] In order to efficiently process resource operation tasks, in some embodiments, the order processing flow of account resources can be paused before at least one resource operation task to be created is determined, or when it is determined that an operation task needs to be performed on account resources.

[0025] In practical applications, when the customer management module determines that operations such as pausing, resuming, or canceling a user account need to be performed, it can call the order module in real time to pause all order processing flows in the user account. In other words, in this embodiment, resource operation tasks can be processed without waiting for all order processing flows in the user account to be completed; resource operation tasks can be processed even when in-transit orders are allowed, where in-transit orders represent unfinished order processing flows corresponding to the user account.

[0026] As can be seen, in this embodiment, resource operation tasks can be effectively processed without waiting for the order processing flow of account resources to complete. The solution in this embodiment no longer relies on the order processing flow form of the user account, but only on the user account status; the triggering conditions for account operations are relatively easy to determine. In real-world scenarios, once an account has outstanding fees or credit irregularities, account suspension and order resource suspension can be initiated immediately, without needing to overly monitor whether there are still order processing flows in the account. This simplifies the overall resource operation task processing flow, and suspending the order processing flow of account resources can improve the accuracy of resource operation task processing to a certain extent.

[0027] Step 102: When creating at least one resource operation task, assign a task identifier to each resource operation task in the at least one resource operation task; the task identifier is determined based on the primary key and the creation time of the primary key.

[0028] Here, the task identifier can be an ID, name, or other identifier. In practical applications, when creating at least one resource operation task, a primary key can be created and its creation time recorded. The task identifier is then assigned to the resource operation task based on the primary key and its creation time.

[0029] Step 103: Execute at least one resource operation task.

[0030] In practical applications, at least one resource operation task can be executed based on a scheduled task framework or other task frameworks.

[0031] In practical applications, steps 101 to 103 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0032] As can be seen, in the embodiments of this application, when creating resource operation tasks, there is no need to assign task identifiers to resource operation tasks through a complex mechanism. Instead, the task identifier of the resource operation task can be easily determined based on the primary key and the creation time of the primary key, which reduces the implementation complexity of the task identifier allocation scheme and is conducive to the efficient execution of resource operation tasks.

[0033] Based on the above description, the account resource-related operation tasks include one or more of the following: account suspension, account restoration, and account cancellation. It can be seen that the embodiments of this application can efficiently execute account suspension, account restoration, or account cancellation operations based on a simple and easy determination of the task identifier for the resource operation task.

[0034] In some embodiments, for the implementation of assigning a task identifier to each resource operation task in at least one resource operation task, a record may be added to a preset table when each resource operation task is created; the identifier of the primary key corresponding to the record and the creation time of the primary key may be determined; machine code may be constructed based on the identifier of the primary key and the creation time of the primary key; and the task identifier may be constructed based on the machine code.

[0035] Here, the preset table can be an auxiliary table, which can be denoted as the tb_worker_id table.

[0036] Based on the needs of real-world scenarios, a unique identifier needs to be assigned to each resource operation task during the task creation phase. For example, after constructing the machine code, a task ID can be built using the improved Snowflake ID algorithm and the machine code. The Snowflake ID algorithm can generate globally unique IDs, serving as the core identifier in the task processing flow. This algorithm, with its unique advantages in high-concurrency environments, ensures that each resource operation task has a unique identity code, greatly facilitating task tracking and backtracking within the system, and providing a solid data foundation for subsequent auditing and troubleshooting. The task ID generated by the Snowflake ID algorithm is 64 bits long, and the number of bits occupied by different parts can be flexibly allocated. The Snowflake ID algorithm used in related technologies has a high implementation complexity and is more suitable for scenarios with extremely high concurrency. For account resource-related operation tasks, due to the low trigger frequency and high latency tolerance, the aforementioned complex Snowflake ID algorithm is not required; that is, the aforementioned complex Snowflake ID algorithm is not suitable for the processing flow of account resource-related operation tasks.

[0037] To achieve simplicity and ease of use in the task ID generator, an efficient, use-and-destroy snowflake ID generator can be designed using an improved snowflake ID algorithm. (See reference...) Figure 2 The 64-bit ID generated by the Snowflake ID generator includes a 1-bit sign bit, a 29-bit timestamp, a 21-bit machine code, and a 13-bit serial number. The 21-bit machine code is determined based on the primary key and the primary key's creation time.

[0038] In the 64-bit ID generated by the Snowflake ID generator, the 1-bit sign bit is fixed at 0. The 29-bit timestamp is a second-level timestamp, with a value equal to the number of seconds from the current time to a certain base time (epoch). The 29-bit timestamp is used for approximately 12-16 years; for example, the base time is set to January 16, 2024. The 21-bit machine code is obtained based on the auto-incrementing primary key ID in the database. The 21-bit machine code supports approximately 2 million resource operation tasks. Each time a resource operation task is started, the next available primary key can be retrieved from the tb_worker_id table and stored in the context. The primary key is then immediately destroyed, and in this state, the tb_worker_id table does not store any data. The 13-bit sequence number is used to support the sequence of concurrent IDs, supporting the generation of 8192 IDs within the same second.

[0039] For example, the primary key identifier can be the ID of the record's auto-incrementing primary key. By designing this auto-incrementing primary key ID, it can support 2 million launches of resource operation tasks, and the machine code is globally unique and will never be repeated. The number of task launches supported by this auto-incrementing primary key ID can cover the design life of a large program.

[0040] For example, Table 1 is an example of the tb_worker_id table. The tb_worker_id table can include fields for worker_id and create_time, where worker_id is the primary key ID and create_time is the primary key creation time.

[0041] Table 1

[0042] As can be seen, the embodiments of this application can easily determine the identifier of the primary key corresponding to the record and the creation time of the primary key by adding records to the table. Thus, machine code can be easily constructed based on the identifier of the primary key and the creation time of the primary key, which helps to reduce the allocation complexity of task identifiers for resource operation tasks.

[0043] To effectively manage task identifiers, in some embodiments, after constructing the machine code based on the primary key identifier and the primary key creation time, the records can be deleted from a preset table. If constructing the machine code based on the primary key identifier and the primary key creation time fails, it is not necessary to delete the records from the preset table; instead, the records in the preset table can be retained.

[0044] Reference Figure 3 The process of creating machine code can include: Step 31: Initialization operation.

[0045] Step 32: Insert records into the table.

[0046] Each time machine code is created or redeployed, a meaningless record can be stored in the auxiliary table, along with the record's auto-incrementing primary key ID and the creation time of the auto-incrementing primary key.

[0047] Step 33: Delete the records in the table.

[0048] After successfully building the machine code based on the primary key ID and the primary key creation time, the previously inserted records can be deleted immediately even if the resource operation task has not yet fully started successfully.

[0049] Here, we can determine whether the resource operation task can start normally. If the resource operation task can start normally, no valid record will be stored in the auxiliary table. Conversely, if the resource operation task fails to start, a valid record can be stored in the auxiliary table. In this case, the problem can be investigated based on the creation time of the records in the auxiliary table.

[0050] It can be seen that if the machine code can be successfully constructed, the task identifier can be considered to have been successfully allocated. Conversely, if the machine code cannot be successfully constructed based on the primary key identifier and the primary key creation time, it indicates that there is an abnormality in the task identifier allocation process. In this case, the problem can be investigated based on the creation time of the records in the table, which is helpful in resolving the abnormality in the task identifier allocation process.

[0051] As can be seen from the foregoing description, considering the randomness of UUID utility classes and the complexity of common snowflake ID generators, this application proposes a simple and efficient snowflake ID generator based on an auto-incrementing primary key in the database. This auto-incrementing primary key snowflake ID generator can support generating 8192 globally unique random IDs per second, supports 2 million resource operation tasks, and has a simple and efficient implementation mechanism, operating with just a single database auxiliary table. Furthermore, the auxiliary table's use-and-destroy mechanism effectively records any abnormal situations of the ID generator, facilitating subsequent backtracking.

[0052] The snowflake ID generator in this application employs a highly optimized implementation mechanism. By simplifying the algorithm logic and improving execution efficiency, it achieves extreme simplification of ID generation. This mechanism not only reduces the consumption of system resources but also significantly improves the ID generation rate, providing each task or entity within the system with an immediate, unique, and efficient identity identifier, laying a solid foundation for the efficient operation of the overall business process.

[0053] In some embodiments, for the implementation of executing at least one resource operation task, at least one resource operation task can be added to a scheduled task buffer table; at set intervals, unexecuted resource operation tasks can be retrieved from the scheduled task buffer table; and the retrieved resource operation tasks can be executed.

[0054] The duration can be set according to actual needs, such as 2 minutes, 3 minutes, etc. Tasks in the scheduled task buffer table can be marked with task status flags. For example, when the task status flag is 0, it means that the task is in the ready state and has not been executed yet; when the task status flag is 1, it means that the task is in the processing state; and when the task status flag is 9, it means that the task has been completed.

[0055] In this embodiment, a scheduled task framework can be used to execute resource operation tasks. Based on the scheduled task framework, the triggering conditions for account operations can be reduced. For example, when a user is in arrears or has low credit, account suspension can be triggered immediately without repeatedly checking whether the user account has any pending orders.

[0056] Since the execution framework for resource operation tasks is typically a distributed framework, in some embodiments, the scheduled task framework can be XXL-job. The XXL-job distributed scheduled task framework, with its high reliability, flexible scheduling strategies, and good scalability, has been selected as the core engine for triggering and executing resource-level order operation tasks. XXL-job not only enables precise scheduling of scheduled tasks but also supports dynamic task management, including but not limited to task creation, modification, pause, and resumption, providing strong support for the automation and intelligence of task processing.

[0057] For example, every 2 minutes, the scheduled task buffer table is scanned using XXL-job to retrieve tasks in the ready state and set their status to "processing" to ensure that the task is not executed repeatedly. In an exemplary application scenario, a complete resource order operation may include the following stages: order assembly message -> sending to service development -> service development product department -> product department callback -> service development sending to billing system -> billing system callback -> service development callback order completion. Here, service development refers to the module in the e-commerce system that interfaces with external systems. It can be seen that a complete resource order operation can only end when the service development callback order completion stage is reached. Conversely, the resource operation task executed on a scheduled basis can only be considered successfully processed after the service development callback. As described above, during the service development callback stage, the scheduled task buffer table needs to be searched based on the ID of the resource operation task being executed. If a scheduled task that meets the conditions and is in the "processing" state exists, it needs to be set to the "execution completed" state. At this point, the resource operation task executed on a scheduled basis can be considered complete.

[0058] As can be seen, the embodiments of this application can effectively handle operation tasks related to account resources through task processing operations based on a timed task mechanism. For example, it can effectively handle account-level operations such as pausing, resuming, and canceling.

[0059] To effectively manage the task processing process, in some embodiments, the execution status and results of resource operation tasks can be recorded. It can be seen that by effectively recording the execution status and results during task processing, it is convenient to manage the state of the entire lifecycle of resource operation tasks and to facilitate subsequent backtracking of the execution status and results during task processing.

[0060] For example, by using a scheduled task-based approach, any operation performed by a user account can be recorded in a database table. Whether the operation is successful or an exception occurs, a trace will be left in the database, which will facilitate subsequent tracking and investigation.

[0061] In an exemplary application scenario, this application embodiment also provides a process for real-time response to account operation instructions and accurate retrieval of order instances. The following is an example illustrating the process for real-time response to account operation instructions and accurate retrieval of order instances. Unlike the ordering process for ordinary goods, long-process orders related to cloud products have a certain degree of complexity. First, the processes for users to subscribe to, cancel, modify, and renew cloud products are all long processes, thus there will be orders in effect and orders in transit simultaneously. Second, long-process orders related to cloud products are divided into main orders and sub-orders, and there are association and attachment relationships between main orders and sub-orders.

[0062] Taking a user's order for a combination of cloud hosting and system disk as an example, when the user is in arrears, all such products associated with the user's account need to be suspended, including resources and billing. In this case, real-time response to account operation commands and precise retrieval of order instances can be implemented first, referring to... Figure 4 In the process of real-time response to account operation instructions and accurate retrieval of order instances, a pre-verification can be performed first. For example, the pre-verification can determine whether user information is valid, whether customer information is valid, and so on.

[0063] Reference Figure 4 After pre-verification, order instances can be retrieved from the instance library. An order instance represents an active order corresponding to a user account. Once the processing flow of any order is completed, it will be archived and converted into an order instance in the instance library. Moreover, no matter what operation a product undergoes, the order instance will not change, thus it can be used to uniquely identify the order flow information of a product.

[0064] Reference Figure 4 After obtaining order instances, the obtained order instances can be aggregated. Then, work orders are retrieved from the work order database. The work orders in the work order database represent the order processing flow that is being processed for the user account. For example, for an order processing flow that is being processed, a scheduled task cannot be created normally, and the order processing flow needs to be marked as an order in transit. Taking an order in transit as an example, if there are still unfinished orders under the user's name, it is not allowed to create a scheduled task immediately, and a "task waiting flag" needs to be added to these orders. Even if the scheduled task scans the instance, it will not trigger the processing flow of the resource operation task. Only after the order is completed will the scheduled task be set to the ready state; otherwise, the scheduled task will be set to the blocked state.

[0065] Long-process orders related to cloud products associated with user accounts are divided into main orders and sub-orders. Given the complexity of these orders, to simplify the process, this solution adopts a "filter first, then supplement" approach, referring to... Figure 3To maintain internal consistency and accuracy, sub-orders can be filtered out during the scheduled task generation phase and then added back during the task trigger callback phase. Specifically, for each resource operation task, since the scheduled task buffer table only stores instance information of the main order, after obtaining the main order instance, it's necessary to retrieve the instance information of the sub-orders attached to the main order from the instance library to ensure that the main and sub-orders can be operated simultaneously. For example, in a scenario where a user orders a cloud server and a system disk in combination, there is a mounting relationship and a co-location relationship between the cloud server and the system disk, which cannot be processed separately. Therefore, during the task creation phase, the system disk is filtered out, and only the instance information corresponding to the cloud server is stored. Then, during the callback execution phase, the order's association relationship is queried, and the system disk is added to the request message for unified processing.

[0066] This application's embodiments establish a comprehensive anomaly tracing process. Through the design of auxiliary tables, order instances, and work order databases, it achieves comprehensive capture and accurate analysis of abnormal account operation situations. This process not only helps us quickly locate the root cause of problems but also provides detailed anomaly handling and maintenance solutions, ensuring that the system can quickly recover stability in the face of abnormal situations and guaranteeing business continuity.

[0067] In summary, this application provides an efficient, reliable, and easily scalable solution for resource operation tasks in user state change scenarios by cleverly integrating the Snowflake ID algorithm with the XXL-Job distributed scheduled task framework. This application has broad market application prospects and wide applicability, and can be applied to scenarios such as information technology (IT) support and infrastructure.

[0068] The solution in this application embodiment has at least the following advantages: 1) By using the Snowflake ID Generator, the ID generation mechanism is simplified to the extreme and enabled with high efficiency, directly solving the need for efficient generation of unique identifiers in distributed systems and big data environments.

[0069] 2) The triggering conditions for account operations have been reduced, making it more convenient for users and improving the efficiency of account and resource management. As order processing flows within accounts gradually increase, the system needs to manage more and more accounts, including user accounts, device accounts, and service accounts. The solution adopted in this application simplifies the operation process, optimizes the user experience, and makes account management easier and more efficient, helping enterprises improve operational efficiency and reduce costs.

[0070] 3) The anomaly tracing process has been improved, ensuring system stability and reliability and providing users with peace of mind regarding service. In today's competitive environment, system stability and reliability are among the most important factors users consider when choosing services. This technical solution, by providing comprehensive anomaly tracing capabilities, helps users to promptly identify and resolve problems, reduce business losses caused by system failures, and provide an efficient operation and maintenance solution.

[0071] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0072] Based on the task processing method proposed in the foregoing embodiments, this application also proposes a task processing device.

[0073] Figure 5 This is a schematic diagram of the structure of the task processing device according to an embodiment of this application, such as... Figure 5 As shown, the device includes: The first processing module 501 is used to determine at least one resource operation task to be created, wherein the resource operation task is an operation task related to account resources.

[0074] The second processing module 502 is used to assign a task identifier to each of the at least one resource operation tasks when creating the at least one resource operation task; and to execute the at least one resource operation task; wherein the task identifier is determined based on the primary key and the creation time of the primary key.

[0075] In some embodiments, the second processing module 502 is specifically configured to, when creating each resource operation task in the at least one resource operation task, add a record to a preset table; determine the identifier of the primary key corresponding to the record and the creation time of the primary key; construct machine code based on the identifier of the primary key and the creation time of the primary key; and construct the task identifier based on the machine code.

[0076] In some embodiments, the second processing module 502 is further configured to delete the record in the preset table after constructing machine code based on the identifier of the primary key and the creation time of the primary key.

[0077] In some embodiments, the second processing module 502 is specifically used to add the at least one resource operation task to a scheduled task buffer table; retrieve unexecuted resource operation tasks from the scheduled task buffer table at set intervals; and execute the retrieved resource operation tasks.

[0078] In some embodiments, the second processing module 502 is further configured to record the execution status and execution result of the resource operation task.

[0079] In some embodiments, the first processing module 501 is further configured to pause the order processing flow of the account resource before determining that an operation task needs to be performed on the account resource, before determining at least one resource operation task to be created.

[0080] In some embodiments, the operation tasks related to account resources include one or more of the following: account suspension, account recovery, and account cancellation.

[0081] In practical applications, the first processing module 501 and the second processing module 502 can be implemented based on a processor.

[0082] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0083] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0084] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the task processing methods provided in this application embodiment.

[0085] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the task processing methods provided in the above embodiments.

[0086] This application also provides an electronic device. Figure 6 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, as shown below. Figure 6 As shown, the electronic device 60 may include: Memory 601 is used to store executable instructions; The processor 602 is used to implement any of the above-described task processing methods when executing executable instructions stored in the memory 601.

[0087] The processor 602 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0088] The aforementioned computer-readable storage medium and memory 601 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it may also be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0089] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0090] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0091] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0092] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0093] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0095] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.

Claims

1. A task processing method, characterized in that, The method includes: Identify at least one resource operation task to be created, wherein the resource operation task is an operation task related to account resources; When creating the at least one resource operation task, a task identifier is assigned to each of the at least one resource operation tasks; the task identifier is determined based on the primary key and the creation time of the primary key; Execute the at least one resource operation task.

2. The method according to claim 1, characterized in that, Assigning a task identifier to each of the at least one resource operation tasks includes: When creating each of the at least one resource operation tasks, a record is added to a preset table; Determine the identifier of the primary key corresponding to the record and the creation time of the primary key; Machine code is constructed based on the identifier of the primary key and the creation time of the primary key; The task identifier is constructed based on the machine code.

3. The method according to claim 2, characterized in that, After constructing machine code based on the primary key identifier and the primary key creation time, the method further includes: deleting the record from the preset table.

4. The method according to claim 1, characterized in that, The execution of the at least one resource operation task includes: Add the at least one resource operation task to the scheduled task buffer table; At set intervals, retrieve unexecuted resource operation tasks from the scheduled task buffer table; Execute the resource operation tasks obtained.

5. The method according to claim 4, characterized in that, The method further includes recording the execution status and execution result of the resource operation task.

6. The method according to claim 1, characterized in that, Before determining at least one resource operation task to be created, the method further includes: When it is determined that an operation task needs to be performed on the account resource, the order processing flow of the account resource is suspended.

7. The method according to claim 1, characterized in that, The account resource-related operations include one or more of the following: account suspension, account recovery, and account cancellation.

8. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the method according to any one of claims 1 to 7.

9. A computer storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images