Task request processing method and device and storage medium

Abstract

The embodiment of the invention provides a task request processing method and device and a storage medium. In the method, after a server receives a task request for requesting to execute a target task from a request device, a local transaction corresponding to a target database is started, and a pre-verification link and a task execution link of the target task are sequentially executed in the local transaction; and when an execution result of the target task is obtained in the pre-verification link or the task execution link, submitting the local transaction to write the execution result of the target task into the target database. And then, the server sends an execution result of the target task to request equipment.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511039629.1 (22) Application Date 2025.07.25 (71) Applicant Ant International Business (Shanghai) Co., Ltd. Address Room 1408, No. 447, Nanquan North Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai 200120, China (72) Inventor Huo Yuanliang (74) Patent Agency Beijing Liuli Intellectual Property Agency (General Partnership) 16049 Patent Attorney Li Zhe (51) Int.Cl. H04L 67 / 60 (2022.01) H04L 67 / 02 (2022.01) H04L 9 / 40 (2022.01) (54) Invention Title: Method, Apparatus, and Storage Medium for Processing Task Requests (57) Abstract: Embodiments of this specification provide a method, apparatus, and storage medium for processing task requests. In this method, after receiving a task request from a requesting device for requesting the execution of a target task, the server initiates a local transaction corresponding to the target database. Within the local transaction, the server sequentially executes a pre-verification step and a task execution step of the target task. When the execution result of the target task is obtained in the pre-verification step or the task execution step, the server submits the local transaction to write the execution result of the target task into the target database. Subsequently, the server sends the execution result of the target task to the requesting device. Claims (2 pages), Description (14 pages), Drawings (3 pages), CN 121567781 A, 2026.02.24, CN 1 21 56 77 81 A. 1. A method for processing a task request, comprising: receiving a task request for executing a target task, the execution process of the target task including: a pre-verification step and a task execution step, the pre-verification step being configured to verify whether the target task meets execution conditions based on reference information, at least a portion of the information in the reference information being variables; opening a local transaction corresponding to a target database, sequentially executing the pre-verification step and the task execution step within the local transaction, and when the execution result of the target task is obtained in the pre-verification step or the task execution step, submitting the local transaction to write the execution result of the target task to the target database; and sending the execution result of the target task. 2. The method according to claim 1, wherein, before performing the pre-verification step within the local transaction, the method further comprises: identifying whether the task request is a duplicate request within the local transaction; and if the task request is a duplicate request, reading the execution result of the target task from the target database, sending the execution result of the target task, and disconnecting the local transaction.3. The method according to claim 2, wherein executing the pre-verification step and the task execution step sequentially within the local transaction includes: executing the pre-verification step and the task execution step sequentially within the local transaction if the task request is not a duplicate request. 4. The method according to claim 2, wherein identifying whether the task request is a duplicate request includes: obtaining idempotency information corresponding to the target task; and identifying whether the task request is a duplicate request based on the idempotency information. 5. The method according to claim 4, wherein identifying whether the task request is a duplicate request based on the idempotency information includes: determining that the task request is a duplicate request if the target database contains idempotency information corresponding to the target task; or determining that the task request is not a duplicate request if the target database does not contain idempotency information corresponding to the target task. 6. The method according to claim 4, wherein identifying whether the task request is a duplicate request based on the idempotency information includes: performing an insert operation on the target database based on the idempotency information corresponding to the target task; determining that the task request is a duplicate request if the insert operation fails, or determining that the task request is not a duplicate request if the insert operation succeeds. 7. The method according to claim 4, wherein obtaining the idempotency information corresponding to the target task includes: parsing the field value of at least one idempotency field from the task request; and generating the idempotency information corresponding to the target task based on the field value of the at least one idempotency field. 8. The method according to claim 1, wherein the pre-verification step includes multiple sub-verification steps, and the execution process of the pre-verification step includes: traversing the multiple sub-verification steps, and for each current sub-verification step in the traversal: obtaining the reference information required by the current sub-verification step, and obtaining the verification rule corresponding to the current sub-verification step, determining whether the reference information satisfies the verification rule, and, if not, generating the execution result of the target task, wherein the execution result at least indicates that the target task has failed. 9. The method according to claim 8, wherein the execution result further indicates that the reason for the failure is that the current sub-verification step failed verification. 10. The method according to claim 1, wherein the method is applied to a server, the server comprising a plurality of distributed computing devices, and the task execution phase is interactively executed by at least two of the plurality of computing devices; before executing the task execution phase, the method further comprises: initiating a distributed transaction;After executing the task execution phase, the method further includes: submitting the distributed transaction. 11. A server, comprising: at least one storage medium storing at least one instruction set for processing task requests; and at least one processor communicatively connected to the at least one storage medium, wherein, when the server is running, the at least one processor reads the at least one instruction set and executes the method as described in any one of claims 1-10 according to the instructions of the at least one instruction set. 12. A computer-readable non-transitory storage medium storing at least one instruction set for processing task requests, wherein, when the at least one instruction set is executed by the at least one processor, it implements the method as described in any one of claims 1-10. Claims 2 / 2 Page 3 CN 121567781 A Task Request Processing Method, Device, and Storage Medium Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a task request processing method, device, and storage medium. Background Art

[0002] In the Internet field, a requesting device can access a server through a network and initiate a task request to the server. The task request is used to request the server to execute a target task. For example, the target task can be a data query task, a fund transfer task, or other tasks. After receiving a task request, the server executes the target task and returns the execution result to the requesting device.

[0003] However, in practical applications, due to network jitter, system anomalies, or repeated user operations, the requesting device may initiate repeated task requests for the same target task multiple times in a short period of time. In this case, if the server fails to handle the repeated task requests properly, the target task may be executed multiple times. When the parameters on which the execution process of the target task depends are variables (such as account balance), multiple executions of the target task may cause the requesting device to receive multiple inconsistent execution results. In addition, in fund transfer tasks, multiple executions of the target task may also lead to problems such as duplicate fund transfers and incorrect account balances, resulting in financial losses. Summary of the Invention

[0004] This specification provides a method, device, and storage medium for processing task requests. In the case where the requesting device initiates repeated task requests to the server multiple times for the same target task, this solution can ensure that the task execution results received by the requesting device multiple times are consistent.

[0005] In a first aspect, this specification provides a method for processing a task request, comprising: receiving a task request for requesting the execution of a target task, wherein the execution process of the target task includes: a pre-verification step and a task execution step, the pre-verification step being configured to verify whether the target task meets execution conditions based on reference information, wherein at least a portion of the information in the reference information is a variable; starting a local transaction corresponding to the target database, and sequentially executing the task request within the local transaction.The method includes a pre-verification step and a task execution step. When the execution result of the target task is obtained in the pre-verification step or the task execution step, the local transaction is submitted to write the execution result of the target task to the target database; and the execution result of the target task is sent.

[0006] In some embodiments, before executing the pre-verification step in the local transaction, the method further includes: identifying whether the task request is a duplicate request in the local transaction; and if the task request is a duplicate request, reading the execution result of the target task from the target database, sending the execution result of the target task, and disconnecting the local transaction.

[0007] In some embodiments, executing the pre-verification step and the task execution step sequentially in the local transaction includes: if the task request is not a duplicate request, executing the pre-verification step and the task execution step sequentially in the local transaction.

[0008] In some embodiments, identifying whether the task request is a duplicate request includes: obtaining idempotency information corresponding to the target task; and identifying whether the task request is a duplicate request based on the idempotency information. Specification 1 / 14 Page 4 CN 121567781 A

[0009] In some embodiments, identifying whether the task request is a duplicate request based on the idempotency information includes: determining that the task request is a duplicate request if the target database contains idempotency information corresponding to the target task; or determining that the task request is not a duplicate request if the target database does not contain idempotency information corresponding to the target task.

[0010] In some embodiments, identifying whether the task request is a duplicate request based on the idempotency information includes: performing an insertion operation on the target database based on the idempotency information corresponding to the target task; determining that the task request is a duplicate request if the insertion operation fails, or determining that the task request is not a duplicate request if the insertion operation succeeds.

[0011] In some embodiments, obtaining the idempotency information corresponding to the target task includes: parsing the field value of at least one idempotency field from the task request; and generating the idempotency information corresponding to the target task based on the field value of the at least one idempotency field.

[0012] In some embodiments, the pre-verification step includes multiple sub-verification steps, and the execution process of the pre-verification step includes: traversing the multiple sub-verification steps, and for each current sub-verification step in the traversal: obtaining the reference information required by the current sub-verification step, obtaining the verification rule corresponding to the current sub-verification step, determining whether the reference information satisfies the verification rule, and if not, generating the execution result of the target task.The execution result at least indicates that the target task execution failed.

[0013] In some embodiments, the execution result further indicates that the reason for the failure is that the current sub-verification step failed the verification.

[0014] In some embodiments, the method is applied to a server, the server includes multiple computing devices deployed in a distributed manner, and the task execution step is interactively executed by at least two of the multiple computing devices; before executing the task execution step, the method further includes: starting a distributed transaction; after executing the task execution step, the method further includes: committing the distributed transaction.

[0015] In a second aspect, this specification also provides a server, including: at least one storage medium storing at least one instruction set for processing task requests; and at least one processor communicatively connected to the at least one storage medium, wherein when the server runs, the at least one processor reads the at least one instruction set and executes the method as described in any one aspect according to the instructions of the at least one instruction set.

[0016] In a third aspect, this specification also provides a computer-readable non-transitory storage medium storing at least one instruction set for processing task requests, wherein when the at least one instruction set is executed by the at least one processor, it implements the method as described in any one aspect.

[0017] Other functions of the task request processing method, apparatus, and storage medium provided in this specification will be partially listed in the following description. The inventive aspects of the task request processing method, apparatus, and storage medium provided in this specification can be fully explained by practice or use of the methods, apparatus, and combinations described in the detailed examples below. Brief Description of the Drawings

[0018] In order to more clearly illustrate the technical solutions in the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] FIG1 shows a schematic diagram of an application scenario provided according to an embodiment of this specification; Specification 2 / 14 pages 5 CN 121567781 A

[0020] FIG2 shows a hardware structure diagram of a computing device provided according to an embodiment of this specification;

[0021] FIG3 shows a flowchart of a task request processing method provided according to an embodiment of this specification; and

[0022] FIG4 shows an interactive flowchart of a task request processing method provided according to an embodiment of this specification. Detailed Description of Embodiments

[0023] The following description provides specific application scenarios and requirements for this specification, with the aim of enabling those skilled in the art to...Manufacture and use of the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but is the widest scope consistent with the claims.

[0024] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean the presence of the associated integers, steps, operations, elements, and / or components, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or the addition of other features, integers, steps, operations, elements, components, and / or groups to the system / method.

[0025] These and other features of this specification, as well as the operation and function of the associated elements of the structure, and the economy of combination and manufacture of components, can be significantly improved in consideration of the following description. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the accompanying drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0026] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0027] For ease of description, the terms that will appear later in this specification will first be explained.

[0028] A local transaction refers to a set of operations performed within a single database or a single resource manager (such as a relational database) that satisfy atomicity, consistency, isolation, and durability. Local transactions are typically managed directly by the database management system (DBMS), and the commit or rollback of a transaction only affects the current database instance and does not involve cross-system or cross-network coordination.

[0029] A distributed transaction refers to a transaction that spans multiple independent data stores, services, or systems, requiring that all participating nodes either all successfully commit or all roll back. This involves cross-network communication.With multiple resource managers, distributed transactions typically rely on protocols such as Two-Phase Commit (2PC), Three-Phase Commit (3PC), or compensatory transactions to ensure global consistency. Typical application scenarios include cross-service data updates or cross-database transactions in a microservice architecture.

[0030] Starting a local transaction (Begin Local Transaction) refers to explicitly or implicitly starting a transaction within a single database session, allowing subsequent operations to be executed within a transaction context. In Structured Query Language (SQL), transactions are typically started using BEGIN TRANSACTION, START TRANSACTION, or the database default setting (e.g., SET autocommit=0). In this case, the database will assign an isolation level to the transaction and record transaction logs to support subsequent commits or rollbacks.

[0031] Commit Local Transaction refers to persisting all operations in the current transaction to the database and releasing the resources occupied by the transaction. After executing the COMMIT command, the database ensures that the atomicity, consistency, isolation, and durability of the transaction take effect, including writing data changes to disk (durability), releasing locks (isolation), and making the changes visible to other sessions (consistency). If the commit fails (e.g., due to constraint violation), the transaction will automatically roll back to ensure that the data is not in a partially committed state.

[0032] Begin Distributed Transaction refers to initiating a transaction coordination process across multiple services or databases in a distributed system. Typically, the transaction manager identifies the transaction using a global transaction ID (XID) and notifies each participant (such as a microservice or database) to enter a ready state. For example, in the Extended Architecture (XA) protocol, the transaction coordinator sends an XA START command to start a distributed transaction, ensuring that subsequent operations can be included in global transaction management.

[0033] Committing a distributed transaction refers to the process of ensuring data consistency in cross-system operations involving multiple independent resources (such as databases, message queues, and microservices) through a coordination mechanism, ensuring that all participants either successfully commit or roll back. For example, in the first phase (preparation phase), the transaction manager queries each participant to see if they can commit; if all return ready, a COMMIT command is sent in the second phase (commit phase).Persist all changes. If any participant fails, a global rollback is triggered. This process needs to handle exceptions such as network partitions and timeouts, and usually relies on compensation mechanisms or eventual consistency schemes to improve reliability.

[0034] Hypertext Transfer Protocol (HTTP): is an application layer communication protocol based on the request-response model, used to transfer data between clients (such as browsers, mobile applications) and servers, especially web page content, images, text and other resources.

[0035] Idempotence is a core concept in computer science, which means that multiple executions of the same operation have the same effect as a single execution. No matter how many times the operation is executed, the final state of the system remains consistent. This characteristic is crucial in the design of distributed systems, network communication and application programming interfaces (APIs), especially in scenarios where retries or duplicate requests may occur.

[0036] The following describes the application scenarios applicable to the embodiments of this specification.

[0037] Figure 1 shows a schematic diagram of an application scenario provided according to an embodiment of this specification. As shown in Figure 1, the application scenario 100 may include a requesting device 120, a network 130, and a server 140.

[0038] The requesting device 120 is a device used to request the server 140 to execute a target task. Referring to Figure 1, the requesting device 120 can send a task request to the server 140 through the network 130 to request the server 140 to execute the target task.

[0039] In some embodiments, the requesting device 120 may include a mobile device, a tablet computer, a laptop computer, a built-in device in a motor vehicle, or similar content, or any combination thereof. In some embodiments, the mobile device may include a smart home device, a smart mobile device, a virtual reality device, an augmented reality device, or similar devices, or any combination thereof. In some embodiments, the smart home device may include a smart TV, a desktop computer, or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, a personal digital assistant, a gaming device, a navigation device, or any combination thereof.

[0040] In some embodiments, the requesting device 120 may have one or more applications (APPs) installed. The APP can provide the ability and interface to interact with the outside world through the network 130. The apps mentioned include, but are not limited to: web browser apps, search apps, chat apps, shopping apps, video apps, financial apps, instant messaging tools, email request devices 120, social media platform software, etc. In some embodiments, the request device 120 may have... (The text abruptly ends here, likely due to an incomplete translation or source material.)The target APP is installed. The requesting device 120 can initiate a task request to the server 140 through the target APP.

[0041] The server 140 is a device or system for providing specific services to the requesting device 120. The server 140 can receive the task request initiated by the requesting device 120 through the network 130, and execute the target task based on the task request to obtain the execution result of the target task. Furthermore, the server 140 can also send the execution result of the target task to the requesting device 120. In some embodiments, the server 140 may include a computing device. In some embodiments, the server 140 may also include multiple computing devices deployed in a distributed manner.

[0042] The network 130 is a transmission medium for facilitating the exchange of information and / or data. As shown in FIG1, the requesting device 120 and the server 140 can be connected to the network 130 and transmit information and / or data to each other through the network 130. In some embodiments, the network 130 can be any type of wired or wireless network, or a combination thereof. For example, network 130 may include a cable network, wired network, fiber optic network, telecommunications network, intranet, Internet, local area network (LAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), public switched telephone network (PSTN), Bluetooth network, ZigBee network, near field communication (NFC) network, or similar network. In some embodiments, network 130 may include one or more network access points. For example, network 130 may include wired or wireless network access points, such as base stations and / or Internet switching points, through which requesting device 120 and server 140 can connect to network 130 to exchange data and / or information.

[0043] It should be understood that the number of requesting device 120, network 130, and server 140 in FIG1 is merely illustrative. Any number of requesting devices 120, network 130, and server 140 may be used depending on implementation needs.

[0044] It should be noted that the server 140 shown in Figure 1 can be a server for providing any type of service, such as: fund management service, computing service, data query service, etc., and this specification does not limit it. For ease of understanding, the following is an example of fund management service.

[0045] When the server 140 is responsible for providing fund management services, the server 140 can also be called a fund management server. For example, the server 140 provides users with efficient and secure cross-border collection, payment, fund management, and fund exchange services by cooperating with the financial systems of one or more countries or regions around the world. For example, users can access the server 140 through terminal devices, register on the server 140, and be logged into the server 140 after being authenticated. After the user registers, the service...Server 140 can create a target account for a user. This target account can be used to store the user's funds. Thus, the user can manage funds through this target account. It should be noted that the user can be an individual user or a business user.

[0046] A user can initiate a task request to server 140 through a terminal device (which can be considered as requesting device 120) to request server 140 to execute a target task. For example, a user can transfer funds from the target account to another person through the terminal device. In this case, server 140 receives a transfer request from the terminal device, and server 140 needs to execute a transfer task. Another example is that a user can also withdraw funds from the target account to their bank card or other account through the terminal device. In this case, server 140 receives a withdrawal request from the terminal device, and server 140 needs to execute a withdrawal task. Yet another example is that a user can also convert foreign currency funds in the target account into local currency through the terminal device. In this case, server 140 receives a conversion request from the terminal device, and server 140 needs to execute a conversion task. For example, a user can also exchange a certain currency in a target account for another currency through a terminal device. In this case, the server 140 receives a currency exchange request from the terminal device, and the server 140 needs to execute a currency exchange task.

[0047] In practical applications, due to network jitter, system abnormalities, or repeated user operations, the requesting device 120 may repeatedly initiate task requests for the same target task in a short period of time. In this case, if the server 140 cannot handle it properly, the target task may be executed multiple times. When the parameters on which the execution process of the target task depends (such as account balance, etc.) are variables, multiple executions of the target task may produce multiple inconsistent execution results. In addition, in scenarios involving fund transfers, multiple executions of the target task may also result in multiple deductions, incorrect account balances, etc., thereby causing financial losses.

[0048] For example, suppose the target task is a transfer task. The server 140 involves multiple stages in the process of executing the transfer task: a pre-verification stage and a task execution stage. The pre-verification step verifies whether the transfer conditions are met, such as whether the account balance is sufficient or whether risk control requirements are met. The task execution step executes the transfer operation. After receiving the task request, server 140 first executes the pre-verification step, and only executes the transfer operation if the verification result shows that the transfer conditions are met. Therefore, in practical applications, the following situation may occur: When server 140 receives the task request for the first time, it detects in the pre-verification step that the account balance is sufficient and the risk control requirements are met, and therefore executes the transfer operation (transferring the user's specified funds).The server 140 attempts to transfer funds to another party and sends a successful transfer notification to the requesting device 120. However, due to network issues, the requesting device 120 does not receive the transfer result. In this case, the requesting device 120 resends the task request corresponding to the transfer task. When the server 140 receives the task request for the second time, it detects in the pre-verification stage that the transfer conditions are not met, such as insufficient balance or risk control rejection. In this case, the server 140 sends a transfer failure notification to the requesting device 120, and the requesting device 120 receives the transfer failure result. Because the server 140 successfully executed the transfer operation, but the requesting device 120 receives a transfer failure result, there is a data inconsistency between the two. Alternatively, after receiving the transfer failure result, the requesting device 120 may then receive the transfer result (successful transfer) corresponding to the first task request, resulting in two inconsistent execution results received by the requesting device 120.

[0049] As can be seen from the above examples, when a task request is sent repeatedly, the server will execute the pre-verification step multiple times. Since the reference information relied upon for verification is a variable, the results obtained from multiple executions of the pre-verification step may be different, leading to inconsistent processing results for multiple duplicate requests.

[0050] In addition, in high-concurrency request scenarios, the requester usually sets a retry strategy to quickly obtain results (e.g., retrying if no result is obtained within 3 seconds). In this scenario, the server executes the pre-verification step every time it receives a task request. Since the reference information relied upon for verification is a variable, the results obtained from multiple executions of the pre-verification step may be different, which also leads to inconsistent processing results for multiple duplicate requests.

[0051] It is understood that the above examples are only some possible examples of data inconsistency in the scenario of task request resending. In practical applications, task request resending may lead to various data inconsistency problems, which will not be illustrated in detail in this specification.

[0052] To solve the above problems, this specification provides a task request processing method that can be applied to the application scenario shown in Figure 1. This scheme can prevent the target task from being executed multiple times in the case of task request resending, thereby avoiding data inconsistency caused by different results from multiple executions of the target task.

[0053] The task request processing method provided in this specification can be executed by the server 140 in FIG1. ​​The server 140 may store data or instructions for executing the above-described task request processing method, and may execute or be used to execute the data and / or instructions. In some embodiments, the server 140 may include a hardware device with data information processing function and the necessary programs required to drive the hardware device to work. The task request processing method provided in this specification will be described in detail below, and will not be repeated here.

[0054] Figure 2 shows a hardware structure diagram of a computing device 200 provided according to an embodiment of this specification. The computing device 200 can act as the server 140 in Figure 1, executing the task request processing method described in this specification.

[0055] As shown in Figure 2, the computing device 200 may include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 200 may also include a communication port 250 and an internal communication bus 210. The computing device 200 specification 6 / 14 pages 9 CN 121567781 A may also include an I / O component 260.

[0056] The internal communication bus 210 can connect different system components. For example, the internal communication bus 210 can connect the storage medium 230, the processor 220, the communication port 250, and the I / O component 260, etc.

[0057] The I / O component 260 supports input / output between the computing device 200 and other components.

[0058] The communication port 250 is used for data communication between the computing device 200 and the outside world. For example, communication port 250 can be used for data communication between computing device 200 and network 130. Communication port 250 can be a wired communication port or a wireless communication port.

[0059] Storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of disk 232, read-only storage medium (ROM) 234 or random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc.

[0060] At least one processor 220 may be communicatively connected to at least one storage medium 230. When computing device 200 is running, at least one processor 220 reads the at least one instruction set and executes the task request processing method provided in this specification according to the instructions of the at least one instruction set. Processor 220 may be in the form of one or more processors. In some embodiments, processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuitry or processor capable of performing one or more functions, etc., or any combination thereof.

[0061] For illustrative purposes only, the accompanying drawings show only one processor 220 for the computing device 200. However, it should be noted that the computing device 200 may also include multiple processors, and therefore, the operations and / or method steps disclosed herein may be executed by one processor or by multiple processors in combination. For example, if the processor 220 of the computing device 200 described in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 220 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0062] FIG3 shows a flowchart of a task request processing method P300 provided according to an embodiment of this specification. The task request processing method P300 may be executed by a server 140. As shown in FIG3, the task request processing method P300 may include S310-S330.

[0063] S310: Receive a task request for requesting the execution of a target task. The execution process of the target task includes a pre-verification step and a task execution step. The pre-verification step is configured to verify whether the target task meets the execution conditions based on reference information. At least part of the information in the reference information is a variable.

[0064] Referring to Figure 1, the server can receive a task request from the requesting device. The task request is used to request the server to execute a target task. The target task can be any type of task, including but not limited to: data query task, fund transfer task, calculation task, etc.

[0065] In this specification, the server's execution process of the target task involves multiple steps. The multiple steps include at least a pre-verification step and a task execution step.

[0066] The pre-verification step is configured to verify whether the target task meets the execution conditions based on reference information. For example, assuming the target task is to transfer money to user X, the pre-verification step is used to verify whether the transfer conditions are met. The verification specification 7 / 14 pages 10 CN 121567781 A includes, but is not limited to, whether the balance is sufficient and whether the risk control requirements are met.

[0067] The reference information used in the pre-verification process may include, but is not limited to, account balance, transfer amount, and transfer time. Among these reference information, account balance and transfer time are variables, meaning they are quantities that may change at any time. It is easy to understand that since at least some of the information in the reference is variable, the verification results obtained by the server performing the pre-verification process multiple times for the same target task may be different.

[0068] The task execution phase is configured to execute the target task. For example, assuming the target task is to transfer funds to user X, the server will execute the operation of transferring funds to user X in the task execution phase.

[0069] It is understandable that the execution results of the target task may be obtained during the execution of the above-mentioned pre-verification and task execution stages. For example, in the pre-verification stage, if insufficient account balance is detected, the result of target task execution failure is obtained; if risk control rejection is detected, the result of target task execution failure is obtained. In the task execution stage, if the transfer operation is detected to be successful, the result of successful transfer is obtained; if the transfer operation is detected to be unsuccessful, the result of unsuccessful transfer is obtained.

[0070] S330: Start the local transaction corresponding to the target database, execute the pre-verification stage and the task execution stage in sequence within the local transaction, and when the execution result of the target task is obtained in the pre-verification stage or the task execution stage, commit the local transaction to write the execution result of the target task to the target database.

[0071] Wherein, the target database is a database used to store the execution results of different tasks. After starting the local transaction corresponding to the target database, the server executes the pre-verification stage and the task execution stage in sequence within the local transaction. That is to say, the pre-verification stage and the task execution stage are executed in the context of the local transaction, and the operations of these stages satisfy the atomicity property. After a local transaction is initiated, the target database records a transaction log to support subsequent local transaction commits or rollbacks.

[0072] As mentioned above, the execution results of the target task may be generated during the execution of the pre-verification stage and the task execution stage. When the execution result of the target task is obtained in any of the above stages, the server commits a local transaction to persist the execution result of the target task to the target database. For example, the server can associate the identification information corresponding to the target task with the execution result of the target task and store them in the target database.

[0073] In some embodiments, the pre-verification stage may include multiple sub-verification stages, and different sub-verification stages are configured to verify whether the target task meets the execution conditions from different dimensions. In this case, the server can traverse the above multiple sub-verification stages and, for each current sub-verification stage in the traversal: obtain the reference information required by the current sub-verification stage, and obtain the verification rules corresponding to the current sub-verification stage, determine whether the reference information meets the verification rules; if not, generate the execution result of the target task, and the execution result at least indicates that the target task has failed to execute.

[0074] In some embodiments, if the reference information does not meet the verification rules in a certain sub-verification step, the execution result generated by the server can also represent that the reason for the failure is that the current sub-verification step has not passed the verification (e.g., insufficient balance or risk control rejection). As an example, the stored content in the target database can be as shown in Table 1.

[0075] Table 1

[0076] Specification 8 / 14 pages 11 CN 121567781 A

[0077] In some embodiments, the server can be a distributed system. In this case, the server may include multiple computing devices deployed in a distributed manner. The task execution phase is executed interactively by at least two of the multiple computing devices. In this case, the server may initiate a distributed transaction before executing the task execution phase and commit the distributed transaction after executing the task execution phase. In this way, the multiple interactive operations involved in the task execution phase can be atomic, ensuring that the multiple interactive operations in the task execution phase are either all successfully committed or all rolled back. When committing the distributed transaction, the server may adopt a two-phase commit or a three-phase commit method, which is not limited in this specification.

[0078] S350: Send the execution result of the target task.

[0079] Specifically, the server may send the execution result to the requesting device. After receiving the execution result of the target task, the requesting device may display the execution result or perform other operations based on the execution result.

[0080] In the task request processing method shown in FIG3, since the pre-verification phase and the task execution phase are both executed in the context of a local transaction, the execution result can be persisted to the target database regardless of which phase obtains the execution result of the target task. In this way, the execution results of each executed task will be persistently stored in the target database. Therefore, the content stored in the target database can be used to identify duplicate task requests.

[0081] In some embodiments, after receiving a task request corresponding to a target task and starting a local transaction, the server can identify whether the task request is a duplicate request within the local transaction. A duplicate request refers to a request that the server has received before receiving the task request. If it is a duplicate request, the server directly reads the execution result of the target task from the target database, sends the execution result of the target task to the requesting device, and disconnects the local transaction. If it is not a duplicate request, the server sequentially executes the pre-verification step and the task execution step within the local transaction.

[0082] For example, after the server receives a task request corresponding to a target task for the first time, the server can persist the execution result of the target task to the target database by executing the task request processing method shown in Figure 3. Thus, when the server receives a task request corresponding to the target task again, the server can directly obtain the previously obtained execution result from the target database without re-executing the target task, thereby avoiding data inconsistency caused by multiple re-executing of the target task.

[0083] In some embodiments, when identifying duplicate requests, the server can obtain idempotency information corresponding to the target task, and identify whether the currently received task request is a duplicate request based on the idempotency information. Here, idempotency information refers to relevant information that can uniquely identify the target task. Idempotency information can be represented using the field value of a single field, or it can be...The idempotency information of the target task is represented by the values ​​of multiple fields.

[0084] In some embodiments, the server may obtain the idempotency information of the target task in the following manner: the server parses the field value of at least one idempotent field from the task request, and then generates the idempotency information of the target task based on the field value of the at least one idempotent field. Wherein, the at least one idempotent field may be a field pre-negotiated between the server and the requesting device. For example, taking the target task as a transfer task, the at least one idempotent field may include one or more of the following: transfer date, transfer amount, transfer currency, and transaction number. When the requesting device sends the task request to the server, it will carry the field value of each idempotent field in the task information. In this way, after receiving the task request, the server can obtain the field value of each idempotent field by parsing the task request. Then, the server concatenates the field values ​​of each idempotent field according to a preset rule to obtain the idempotency information corresponding to the target task.

[0085] In some embodiments, the server may identify duplicate requests in the local transaction in the following manner: the server queries the target database to see if / contains the idempotency information corresponding to the target task. If the target database contains idempotent information corresponding to the target task, then the current task request is determined to be a duplicate request; if the target database does not contain idempotent information corresponding to the target task, then the current task request is determined to be a duplicate request.

[0086] In conjunction with the foregoing description, in some embodiments, the data storage format in the target database can be as shown in Table 1, that is, the target database stores identification information and execution results of different tasks. Among them, the identification information is used to uniquely represent a task. The identification information is used as the primary key in the target database. The target database automatically guarantees the uniqueness of the primary key when performing data insertion operations. In this case, the server can use the idempotent information of each task as the identification information. Thus, the server can also identify duplicate requests in the local transaction in the following way: the server performs an insertion operation on the target database based on the idempotent information corresponding to the target task. The result of the insertion operation is success or failure. If the result of the insertion operation is failure, the server determines that the current task request is a duplicate request. If the result of the insertion operation is success, the server determines that the current task request is not a duplicate request.

[0087] As can be seen, in the task request processing method provided in this specification, after receiving the task request, the server starts a local transaction corresponding to the target database, performs the pre-verification stage and the task execution stage of the target task within the local transaction, and when the execution result of the target task is obtained in either stage, the local transaction is committed to submit the target task.The execution result is persisted to the database. When the server receives a duplicate task request, it directly reads the previous execution result from the database and returns it. In this way, the server can avoid executing the target task multiple times in the case of resending the task request, thereby avoiding the problem of data inconsistency caused by different results of multiple executions of the target task. That is to say, even if the reference information required for verification in the pre-verification stage of the target task is a variable, the server will not execute the target task multiple times when it receives multiple duplicate requests corresponding to the target task, and the execution result returned by the server to the requesting device multiple times based on multiple duplicate requests will be consistent. It can be seen that this scheme can avoid the situation where the requesting device receives inconsistent execution results multiple times.

[0088] The following will take the fund transfer scenario as an example and, in conjunction with Figure 4, provide a more detailed explanation of the task request processing method provided in this specification.

[0089] In the fund transfer scenario, the server is responsible for providing fund management services and maintaining multiple accounts. The requesting device can initiate a task request to the server to request the execution of tasks related to fund transfer, such as fund disbursement, transfer, withdrawal, foreign exchange settlement, etc.

[0090] As shown in Figure 4, the task request processing method P400 may include S410-S530.

[0091] S410: The requesting device sends a task request to the server, the task request being used to request the execution of a target task.

[0092] For example, the target task may be a transfer task, indicating that a target amount of funds in a first account be transferred to another account. The first account is any one of multiple accounts maintained by the server.

[0093] In some embodiments, the task request may be a request based on the HTTP protocol. The HTTP protocol adopts a clear request-response model, supports text or binary data transmission, and is adaptable to various application scenarios; its stateless characteristics and persistent connection mechanism balance efficiency and distributed deployment requirements; it offers high communication security and is deeply integrated with the Web ecosystem (such as caching, cookies, etc.).

[0094] S420: The server initiates a local transaction corresponding to the target database.

[0095] In some embodiments, before initiating a local transaction, the server may also parse the task request and verify the legality of the parameters carried in the task request. If the verification passes, the server executes S420. If the verification fails, the server can ignore the task request.

[0096] S430: The server identifies whether the task request is a duplicate request within the local transaction.

[0097] It should be noted that the specific implementation of S430 has been described above and will not be repeated here.

[0098] If the task request is a duplicate request, the server executes S440. Specification 10 / 14 pages 13 CN 121567781 A

[0099] If the task request is not a duplicate request, the server executes S450.

[0100] S440: The server reads the execution result of the target task from the target database, sends the execution result of the target task to the requesting device, and disconnects the local transaction.

[0101] If the task request is a duplicate request, it means that the server has previously executed the target task, and the execution result of the target task has been persisted to the target database. Therefore, the server can directly read the execution result of the target task from the target database. It is easy to understand from the above description that the execution result is the result obtained by the server when it executes the target task for the first time upon receiving the service request corresponding to the target task.

[0102] It is understood that the server will not execute subsequent steps after executing S440.

[0103] If the task request is not a duplicate request, it means that the server has not previously executed the target task. Therefore, the server can sequentially execute the pre-verification step and the task execution step within the local transaction to obtain the execution result of the target task. That is, if the task request is not a duplicate request, the server continues to execute S450.

[0104] For ease of understanding, the following description uses the example of a pre-verification process including two sub-verification processes: a balance verification process and a risk control verification process. The balance verification process verifies whether the balance in the first account is greater than the target amount to be transferred. The risk control verification process verifies whether the current transfer task meets risk control requirements.

[0105] S450: The server obtains the reference information required for the balance verification process and the corresponding verification rules.

[0106] For example, the reference information required for the balance verification process may include: the current balance in the first account and the amount of funds to be transferred specified in the task request. Simultaneously, the server also obtains the verification rules corresponding to the balance verification process. For example, the verification rules may include: the balance in the first account is greater than or equal to the amount of funds to be transferred.

[0107] S460: The server determines whether the reference information meets the verification rules.

[0108] After obtaining the reference information and verification rules corresponding to the balance verification process, the server can determine whether the reference information meets the verification rules. If the reference information satisfies the verification rule, the target task is determined to meet the execution conditions required by the balance verification step, and is allowed to proceed to the subsequent process; otherwise, it is considered not to meet the execution conditions required by the balance verification step, and the subsequent operation is stopped.

[0109] If the reference information does not meet the verification rule, the server executes S470.

[0110] If the reference information satisfies the verification rule, the server executes S480.

[0111] S470: The server determines the execution result of the target task and submits a local transaction to transfer the target task's...The execution result is written to the target database, and the execution result of the target task is sent to the requesting device.

[0112] Since the reference information does not meet the verification rules, the execution result determined by the server in S470 at least indicates that the target task execution failed (e.g., transfer failure). After determining the execution result, the server submits a local transaction to persist the execution result of the target task to the target database so that the execution result can be read from the target database when a duplicate request corresponding to the target task is received later.

[0113] In some embodiments, the execution result may also indicate that the reason for failure is that the balance verification step failed. For example, the execution result may carry a reason field to indicate "insufficient balance". In this way, the requesting device can know the reason for the failure of the target task execution.

[0114] It is understood that the server does not execute subsequent steps after executing S470.

[0115] S480: The server obtains the reference information required for the risk control verification step and obtains the verification rules corresponding to the risk control verification step. Instruction manual, pages 11 / 14, CN 121567781 A

[0116] For example, the reference information required for the risk control verification step may include: the status of the first account, historical transfer behavior, the amount of funds to be transferred specified in the task request, transfer frequency, transfer time period, etc. The verification rules corresponding to the risk control verification step may include: the total amount of transfers in a single day shall not exceed the set limit, the number of transfers of the same account per day shall not exceed the limited number, and large transfers shall be restricted during specific high-risk time periods, etc.

[0117] S490: The server determines whether the verification reference information meets the verification rules.

[0118] After obtaining the reference information and verification rules corresponding to the risk control verification step, the server can determine whether the reference information meets the verification rules. If the reference information meets the verification rules, it is determined that the target task meets the execution conditions required by the risk control verification step and is allowed to enter the subsequent process; otherwise, it is considered that the execution conditions required by the risk control verification step are not met, and the subsequent operation is stopped. By performing risk control verification, server 140 can intercept potential abnormal or high-risk transactions in advance, effectively preventing financial risks.

[0119] If the reference information does not meet the verification rules, the server executes S500.

[0120] If the reference information meets the verification rules, the server executes S510.

[0121] S500: The server determines the execution result of the target task, submits a local transaction to write the execution result of the target task into the target database, and sends the execution result of the target task to the requesting device.

[0122] Since the reference information does not meet the verification rules, the execution result determined by the server in S500 is not valid.The result at least indicates that the target task failed to execute (e.g., transfer failed). After determining the execution result, the server submits a local transaction to persist the execution result of the target task to the target database so that the execution result can be read from the target database when a duplicate request corresponding to the target task is received later.

[0123] In some embodiments, the execution result may also indicate that the reason for failure is that the risk control verification step failed. For example, the execution result may carry a reason field indicating "risk control rejection" or "exceeding the daily transfer limit". In this way, the requesting device can know the reason for the failure of the target task execution.

[0124] It is understood that the server will not execute subsequent steps after executing S500.

[0125] If the judgment result of S490 is that the reference information meets the verification rules, it means that each sub-verification step in the first verification step (e.g., the balance verification step and the risk control verification step) has passed the verification, that is, the target task meets the execution conditions. Therefore, the server can enter the task execution step, that is, the server continues to execute S510-S530.

[0126] S510: The server executes the target task and determines the execution result of the target task.

[0127] For example, taking the target task as a transfer task, the server can execute a transfer operation (transferring the target amount of funds in the first account to other accounts) according to the task request. The result of the transfer operation can be a successful transfer or a failed transfer. In the case of a successful transfer, the server determines that the execution result of the target task is successful; in the case of a failed transfer, the server determines that the execution result of the target task is failed.

[0128] In some embodiments, when the server includes multiple computing devices deployed in a distributed manner, the server can also start a distributed transaction before executing the target task, and can also commit the distributed transaction after executing the target task, thereby ensuring that the operations of the multiple computing devices in the task execution process are either all successfully committed or all rolled back. For details, please refer to the relevant description above, which will not be repeated here.

[0129] S520: The server commits a local transaction to write the execution result of the target task into the target database.

[0130] After determining the execution result, the server commits a local transaction to persist the execution result of the target task to the target database, so that the execution result can be read from the target database when a subsequent duplicate request corresponding to the target task is received.

[0131] S530: The server sends the execution result of the target task to the requesting device. Specification 12 / 14 pages 15 CN 121567781 A

[0132] Accordingly, the requesting device can receive the execution result of the target task from the server. In this case, the requesting device can display the execution result or perform subsequent operations based on the execution result.

[0133] In the scheme shown in Figure 4, if the server fails to start a local transaction in S420, it can be considered as a lock acquisition failure. In this case, it indicates that the transaction resources of the target database have not been released, and the server can return an exception message to the requesting device. In S420, if the server successfully starts a local transaction, it can be considered as a lock acquisition success. In this case, if the server receives a new task request corresponding to the same target task before the server commits the transaction, the new task request will fail to acquire the lock. This can avoid the server executing the same target task multiple times.

[0134] In the interaction process shown in Figure 4, when the server receives the task request corresponding to the target task for the first time, it verifies whether the target task meets the execution conditions through the balance verification step and the risk control verification step. If it does not meet the conditions, the server returns the execution result of the failed execution to the requesting device and persists the execution result to the target database. In this way, when the server receives a duplicate request corresponding to the target task next time, it can directly read the execution result of the target task from the target database without repeating the execution of the target task, especially without repeating the balance verification step and the risk control verification step. In this way, when the reference information required for the balance verification and risk control verification stages is variable, even if the service device receives multiple duplicate requests for the same target task, the multiple execution results returned by the server to the requesting device based on the multiple duplicate requests are consistent, thereby avoiding the problem of data inconsistency. Especially in scenarios involving fund transfers, it reduces the probability of financial loss due to data inconsistency.

[0135] The task request processing method provided in this specification, by reasonably arranging the code of the idempotency verification stage (i.e., the stage for identifying duplicate requests), the pre-verification stage, and the task execution stage, executes all three stages within a local transaction, enabling the server to avoid multiple repeated executions of the same target task, requiring less code modification to the server and lowering development costs. In addition, the implementation of local transactions in the database is relatively simple and less prone to errors, further reducing development costs. Since the technical solution provided in this specification can avoid multiple repeated executions of the same target task within the server, this solution is applicable to scenarios where the service requester wants to support fast retries, meeting the service requester's need to quickly obtain task execution results.

[0136] In another aspect, this specification provides a computer-readable non-transitory storage medium storing at least one set of instructions for processing task requests. When the at least one set of instructions is executed by a processor, the at least one set of instructions instructs the processor to implement the steps of the task request processing method P300 described herein. In some possible embodiments, various aspects of this specification may also be implemented as a program product comprising program code. When the program product is run on a server, the program code is used to cause the server to execute the task request described herein.The processing method P300 describes the steps. The program product used to implement the above method can employ a portable compact disc read-only memory (CD-ROM) containing program code and can run on a server. However, the program product in this specification is not limited to this; in this specification, a readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product can employ any combination of one or more readable media. A readable medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium can include data signals propagated as part of a carrier wave in baseband, carrying readable program code. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium can also be any readable medium other than the readable storage medium described on pages 13 / 14 of the specification (CN 121567781 A), which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations of this specification can be written in any combination of one or more programming languages, including object-oriented programming languages—such as Java, C++, etc.—and conventional procedural programming languages—such as the "C" language or similar programming languages.

[0137] Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or potentially advantageous.

[0138] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that...Those skilled in the art will understand that the requirements of this specification encompass various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0139] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" means that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "an alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.

[0140] It should be understood that in the foregoing description of the embodiments of this specification, various features are combined in a single embodiment, drawing, or description thereof for the purpose of simplifying this specification in order to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art will be fully likely to identify some of the devices as separate embodiments when reading this specification. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. The content of each secondary embodiment also applies even when it contains fewer than all the features of a single foregoing disclosed embodiment.

[0141] Every patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, articles, etc., referenced herein, except for those inconsistent with or conflicting with this document, or those having a limiting effect on the widest scope of the claims, may be incorporated herein by reference and used for all purposes now or hereafter associated with this document. Furthermore, in the event of any inconsistency or conflict between the description, definition, and / or use of relevant terms in any material and the description, definition, and / or use of relevant terms in this document, the terms in this document shall prevail.

[0142] Finally, it should be understood that the embodiments of the applications disclosed herein are illustrative of the principles of the embodiments of this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications. Instruction manual, page 14 / 14, 17 CN 121567781 A, Figure 1, Figure 2, Instruction manual drawing, page 1 / 3, 18 CN 121567781 A, Figure 3, Instruction manual drawing, page 2 / 3, 19 CN 121567781 A, Figure 4, Instruction manual drawing, page 3 / 3, 20CN 121567781 A Abstract Abdominal ultrasound examination method, system and device Task request processing method and device and storage medium The embodiment of the invention provides a task request processing method and device and a storage medium. In the method, after a server receives a task request for requesting to execute a target task from a request device, a local transaction corresponding to a target database is started, and a pre-verification link and a task execution link of the target task are sequentially executed in the local transaction; and when an execution result of the target task is obtained in the pre-verification link or the task execution link, submitting the local transaction to write the execution result of the target task into the target database. And then, the server sends an execution result of the target task to request equipment.

Claims

1. A method for processing task requests, comprising: The system receives a task request to execute a target task. The execution process of the target task includes a pre-verification step and a task execution step. The pre-verification step is configured to verify whether the target task meets the execution conditions based on reference information, wherein at least part of the information in the reference information is a variable. A local transaction corresponding to the target database is initiated. Within the local transaction, the pre-verification step and the task execution step are executed sequentially. When the execution result of the target task is obtained in the pre-verification step or the task execution step, the local transaction is committed to write the execution result of the target task into the target database. Send the execution result of the target task.

2. The method according to claim 1, wherein, Before performing the pre-verification step within the local transaction, the method further includes: Within the local transaction, it is determined whether the task request is a duplicate request; and If the task request is a duplicate request, the execution result of the target task is read from the target database, the execution result of the target task is sent, and the local transaction is disconnected.

3. The method according to claim 2, wherein, Within the local transaction, the pre-verification step and the task execution step are executed sequentially, including: If the task request is not a duplicate request, the pre-verification step and the task execution step are executed sequentially within the local transaction.

4. The method according to claim 2, wherein, The step of identifying whether the task request is a duplicate request includes: Obtain the idempotency information corresponding to the target task; and The idempotency information is used to identify whether the task request is a duplicate request.

5. The method according to claim 4, wherein, The step of identifying whether the task request is a duplicate request based on the idempotency information includes: If the target database contains idempotency information corresponding to the target task, it is determined that the task request is a duplicate request; or If the target database does not contain idempotent information corresponding to the target task, it is determined that the task request is not a duplicate request.

6. The method according to claim 4, wherein, Identifying whether the task request is a duplicate request based on the idempotency information includes: An insertion operation is performed on the target database based on the idempotency information corresponding to the target task. If the insertion operation fails, the task request is determined to be a duplicate request, or If the insertion operation is successful, it is determined that the task request is not a duplicate request.

7. The method according to claim 4, wherein, Obtaining the idempotency information corresponding to the target task includes: Parse at least one idempotent field value from the task request; and Idempotency information corresponding to the target task is generated based on the field values ​​of the at least one idempotency field.

8. The method according to claim 1, wherein, The pre-verification step includes multiple sub-verification steps, and the execution process of the pre-verification step includes: Iterate through the multiple sub-verification steps, and for each current sub-verification step in the iteration: Obtain the reference information required for the current sub-verification step, and obtain the verification rules corresponding to the current sub-verification step; determine whether the reference information satisfies the verification rules; and If the conditions are not met, an execution result of the target task is generated, and the execution result at least indicates that the target task has failed.

9. The method according to claim 8, wherein, The execution result also indicates that the reason for the failure is that the current sub-verification step failed the verification.

10. The method according to claim 1, wherein, The method is applied to a server, which includes multiple computing devices deployed in a distributed manner, and the task execution phase is interactively executed by at least two of the multiple computing devices. Before executing the task execution phase, the method further includes: initiating a distributed transaction; After executing the task execution phase, the method further includes: submitting the distributed transaction.

11. A server, comprising: At least one storage medium storing at least one instruction set for processing task requests; as well as At least one processor is communicatively connected to the at least one storage medium, wherein when the server is running, the at least one processor reads the at least one instruction set and executes the method as described in any one of claims 1-10 according to the instructions of the at least one instruction set.

12. A computer-readable non-transitory storage medium storing at least one instruction set for processing task requests, wherein, When the at least one instruction set is executed by at least one processor, the method as described in any one of claims 1-10 is implemented.

Images