Data processing method, apparatus, device, storage medium, and product

Abstract

The application discloses a data processing method and device, equipment, storage medium and product, and relates to the technical field. The method comprises the following steps: receiving a service request sent by a client; in response to a parameter verification pass result of the service request, checking whether a request docking record corresponding to the service request exists in a preset request docking record table to obtain a docking record checking result; and processing the service request according to the docking record checking result, the request docking record table and a target service interface corresponding to the service request. Through the method, the request docking record table is introduced to manage the service request of the client, the idempotency of the service end interface is realized, the request processing procedure is simplified, and the complexity, the system maintenance cost and the difficulty caused by repeated processing of the same request are reduced.

Description

Technical Field

[0001] This application relates to the field of technology, and more particularly to a data processing method, apparatus, device, storage medium, and product. Background Technology

[0002] In modern software architecture, distributed systems are becoming increasingly important due to their scalability and high availability. In distributed systems, the interaction between the server and client is a crucial link in implementing business logic. However, due to network instability and non-standard server-side interface design, traditional distributed systems often face transaction consistency issues when processing client requests. This is especially true when the server-side interface lacks idempotency; that is, the same request processed multiple times can lead to different results. This can cause inconsistencies in the database transactions between the server and client, thus triggering distributed transaction problems.

[0003] Furthermore, many system designs lack robust idempotency in their server-side interfaces. This can lead to the same business request being processed multiple times by the server under network anomalies or other external factors, resulting in data inconsistency. Additionally, existing distributed transaction frameworks typically require both the client and server to be integrated with a specific framework, which limits the flexibility of the technology stack and increases system complexity and maintenance costs.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a data processing method, apparatus, device, storage medium, and computer program product, which aims to reduce the complexity and maintenance cost of request processing systems.

[0006] To achieve the above objectives, this application proposes a data processing method, which includes:

[0007] Receive business requests sent by the client;

[0008] In response to the parameter verification result of the business request, query the preset request connection record table to see if there is a request connection record corresponding to the business request, and obtain the connection record verification result;

[0009] The business request is processed based on the verification results of the connection record, the request connection record table, and the target business interface corresponding to the business request.

[0010] In one embodiment, the step of processing the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request includes:

[0011] If the verification result of the connection record is that there is no request connection record, then the request connection record corresponding to the business request is generated and entered into the request connection record table;

[0012] Identify the task type of the business request;

[0013] Based on the task type, set the interface status of the target business interface corresponding to the business request, and synchronize the interface status to the request connection record table.

[0014] In one embodiment, the step of setting the interface status of the target business interface corresponding to the business request based on the task type and synchronizing the interface status to the request connection record table includes:

[0015] If the business request is not an asynchronous task business request, then the state of the target business interface corresponding to the business request is set to the initialization state;

[0016] If the business request is an asynchronous task business request, then the status of the target business interface corresponding to the business request is set to the running state.

[0017] In one embodiment, the step of processing the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request further includes:

[0018] Invoke the target business interface to execute the business request, and set the status of the target business interface to the running state;

[0019] Obtain the execution result of the target business interface executing the business request;

[0020] Based on the execution result, the status of the target business interface is set to either execution success or execution failure.

[0021] In one embodiment, the step of receiving a service request sent by the client further includes:

[0022] Obtain the query result indicating whether the client supports idempotency settings for the target business interface;

[0023] If the target business interface does not support idempotency settings, then query the preset request connection record table to see if there is a request connection record corresponding to the business request;

[0024] If the aforementioned business request connection record exists, then obtain and return the request connection record to the client;

[0025] If the business request connection record does not exist, a request connection record corresponding to the business request is generated and returned to the client;

[0026] If the target business interface supports idempotent settings or responds to a confirmation request command generated by the client, the following steps are executed:

[0027] Receive business requests sent by the client.

[0028] In one embodiment, the method further includes:

[0029] The system queries the request connection record table at preset time intervals to check if there are any request connection records that have timed out.

[0030] If there is a request connection record with a timeout response, then determine the timeout request and timeout business interface corresponding to the timeout request connection record.

[0031] Query the business processing data of the timeout service interface;

[0032] The execution result of the timeout request is determined based on the business processing data, and the interface status of the timeout business interface is set according to the execution result of the timeout request.

[0033] In addition, to achieve the above objectives, this application also proposes a data processing apparatus, which includes: a receiving module for receiving a service request sent by a client;

[0034] The verification module is used to respond to the parameter verification result of the business request, query the preset request connection record table to see if there is a request connection record corresponding to the business request, and obtain the connection record verification result.

[0035] The processing module is used to process the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request.

[0036] In addition, to achieve the above objectives, this application also proposes a data processing apparatus, the apparatus comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data processing method described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the data processing method described above.

[0038] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data processing method described above.

[0039] This application proposes one or more technical solutions that involve receiving business requests sent by clients; responding to the parameter verification result of the business request, querying a preset request connection record table to determine if a corresponding request connection record exists for the business request, and obtaining a connection record verification result; processing the business request based on the connection record verification result, the request connection record table, and the target business interface corresponding to the business request. By introducing a request connection record table to manage client business requests, this method achieves idempotency of the server-side interface, thereby simplifying the request processing flow and reducing the complexity caused by repeatedly processing the same requests. Furthermore, since this solution does not rely on a specific distributed transaction framework, it reduces limitations on the technology stack and lowers maintenance costs and difficulties. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating an embodiment of the data processing method of this application.

[0043] Figure 2 A schematic diagram illustrating the process by which the proposed solution to this application arises;

[0044] Figure 3 This is a schematic diagram illustrating the state machine settings for the business interface of the request processing method in this application.

[0045] Figure 4 A schematic diagram of the processing flow designed for the server-side idempotent interface implementation of the request processing method in this application;

[0046] Figure 5 This is a flowchart illustrating Embodiment 2 of the data processing method of this application;

[0047] Figure 6 This is a schematic diagram illustrating the server-side timeout recovery logic for the request processing method in this application.

[0048] Figure 7 This is a schematic diagram of the module structure of the data processing device according to an embodiment of this application;

[0049] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the data processing method in the embodiments of this application.

[0050] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0052] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0053] The main solution of this application is to propose a server-side distributed transaction processing method based on database record status. This method ensures the idempotency of the interface by recording the client request connection record and the status transition of the connection record in the database. Specifically, when the client sends a business request, the server first performs parameter validation, and then queries the request connection record table to check if a corresponding request record exists. If it exists, it decides whether to continue processing the request or return the previous status and error information based on the status of the connection record and the business logic. If it does not exist, a new connection record is created and its status is set to initialization. Subsequently, the server executes the request and updates the status of the connection record based on the execution result, which may be success, failure, or running. For server interfaces that do not support idempotency, the server provides a verification interface, allowing the client to query the business status before calling, thereby deciding whether to call the server. In addition, to handle possible exceptions or timeouts during server execution, an exception recovery mechanism is designed. The timeout period is used to determine whether the server status is abnormal, and the connection record status is updated based on business data to support client retries after failure. The entire solution does not rely on a specific distributed transaction framework, reducing implementation costs, while supporting custom retry strategies, improving the system's flexibility and reliability.

[0054] In existing technologies, the interaction between the server and client is frequent and complex. Traditional system designs often neglect the idempotency of the server interface. This leads to the same business request being incorrectly processed multiple times under network anomalies or other external factors, thus compromising transaction consistency. Furthermore, existing distributed transaction frameworks typically require both the client and server to connect to specific frameworks, limiting the flexibility of the technology stack and increasing system complexity and maintenance costs. The technical solution proposed in this application aims to address these problems by introducing a request interface record table to manage client business requests, achieving idempotency of the server interface. This simplifies the request processing flow and reduces the complexity caused by repeatedly processing the same requests. Simultaneously, since this solution does not rely on a specific distributed transaction framework, it reduces restrictions on the technology stack, lowers maintenance costs and system upgrade difficulty, and improves system flexibility and reliability.

[0055] This application provides a solution that receives business requests sent by clients; in response to the parameter validation result of the business request, queries a preset request connection record table to determine if a corresponding request connection record exists, obtaining a connection record verification result; and processes the business request based on the connection record verification result, the request connection record table, and the target business interface corresponding to the business request. This method introduces a request connection record table to manage client business requests, achieving idempotency of the server-side interface, thereby simplifying the request processing flow and reducing the complexity caused by repeatedly processing the same requests. Furthermore, since this solution does not rely on a specific distributed transaction framework, it reduces limitations on the technology stack and lowers maintenance costs and difficulties.

[0056] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data processing system capable of performing the above functions. The following description uses a data processing system as an example to illustrate this embodiment and the subsequent embodiments.

[0057] Based on this, embodiments of this application provide a data processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the data processing method of this application.

[0058] In this embodiment, the data processing method includes steps S1000 to S3000:

[0059] Step S1000: Receive the service request sent by the client;

[0060] It should be noted that in traditional system design, when the client and server interact, the interface is often not idempotent due to non-standard server interface design. When providing services to the client, this often leads to inconsistencies in the database transactions between the two parties, resulting in distributed transaction problems.

[0061] For details, please refer to Figure 2 As shown, Figure 2 The diagram illustrates the process by which the processing method of this application addresses the problem. It shows that when the same business request is requested twice simultaneously due to network anomalies on the server side, the client considers it to have been successfully requested once, while the server considers it to have been successfully requested twice. When there is a flaw in the idempotency design of the server side, inconsistency between the two parties' transactions will inevitably occur.

[0062] Due to its own functional limitations, the server cannot coordinate transactions with the client. To solve the above problem, this embodiment requires the server to provide assistance in coordinating distributed transactions for the client during the design phase, so that the client can complete the coordination of database transactions between the two ends and ensure the consistency of transactions.

[0063] Meanwhile, some servers face difficulties in achieving idempotency, or may lack the necessary conditions for idempotency. Alternatively, clients may want to decide for themselves whether to call the server, requiring them to query the current state of the server's data before making the call. Only if the current business transaction is deemed callable will the server be invoked. Therefore, an interface for querying the business status by primary key is needed to facilitate verification by clients and ensure transaction consistency.

[0064] Additionally, it's important to note that clients send business requests through specific protocols and interfaces. These requests may include various business operations, such as data queries, updates, and transaction processing. Upon receiving a request, the server needs to perform a series of processing steps to ensure that the request is handled correctly and effectively. The purpose of this process is to establish a communication bridge between the server and the client, ensuring that the client's business requirements are understood and executed by the server.

[0065] Upon receiving a request, the server also performs preliminary checks on the request's format and data validity to ensure that the received request is complete and meets expectations. This step is crucial for preventing invalid or malicious requests from entering the system. For example, in one specific implementation, the client sends a JSON-formatted request containing user transaction information to the server via the HTTP protocol. The server first verifies the request format is correct, then parses the request content, preparing for subsequent processing.

[0066] Step S2000: In response to the parameter verification result of the business request, query the preset request connection record table to see if there is a request connection record corresponding to the business request, and obtain the connection record verification result;

[0067] It's important to note that the interface verification step is crucial for ensuring the idempotency of business requests. In this embodiment, to guarantee interface idempotency, the client's request needs to be persisted. Simultaneously, to ensure reentrancy and idempotency of the request, the execution result and corresponding status of the server-side logic need to be recorded. The system will query the interface record table in the database based on the parameters of the business request to determine if a corresponding interface record already exists. The interface record table is a table in the database used to record the processing status of each business request; it ensures that even in the event of network anomalies or other circumstances, the same business request will not be processed repeatedly.

[0068] The interface record table typically contains multiple fields, such as request ID, request content, and processing status. These fields collectively identify a unique business request. By querying the interface record table, the system can determine whether the current business request has already been processed, thereby avoiding the repeated execution of the same business logic. The design of the interface record table for client requests recorded in the database is shown in Table 1 below:

[0069]

[0070] The connection record status records the current state of the server-side interface execution, and its value can flow between different states. The state machine design is as follows: Figure 3 As shown, the server interface can switch between initialization, running, failure, and success states.

[0071] Additionally, it should be noted that the verification results of the interface record will directly affect subsequent processing flows. If a corresponding record exists in the interface record table, the system may directly return the previously processed result without executing the business logic; if it does not exist, the subsequent processing flow will continue.

[0072] For example, in one specific implementation, after receiving a transfer request from a user, the system first performs parameter validation to confirm the validity of the request format and data. If the validation passes, the system queries the connection record table to check if there is a record of the same transfer request. If it finds that the same request has already been processed, it directly returns the processing result to the client and does not perform any further transfer operations.

[0073] Step S3000: Process the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request.

[0074] It should be noted that, referring to Figure 4 , Figure 4 This diagram illustrates the processing flow of the server-side idempotent interface implementation for the request handling method in this application. The result of the connection record verification determines the processing strategy for the business request. If a corresponding record does not exist in the connection record table, the system will generate a new connection record and begin processing the business request. This step involves the creation of the connection record, the execution of business logic, and the recording and return of results. The creation of the connection record is to record the processing status of the business request, including information such as the request reception time, processing status, and return time. This helps the system track the processing of each request and, when necessary, troubleshoot and optimize the system. Based on the state machine design of the aforementioned server-side business interface, all upstream requests undergo parameter validation upon entry. As long as the input parameters are correct, the request will be persisted to the database. If duplicate requests exist, the database records can be used to determine whether a duplicate request is made, and re-entry can be prevented during the execution process.

[0075] Additionally, it's important to note that when processing business requests, the system invokes the corresponding business interfaces based on the request content. These interfaces encapsulate specific business logic, such as database operations and third-party service calls. By calling these interfaces, the system executes the operations required by the business request and updates the status of the connected records based on the execution results.

[0076] For example, in one specific implementation, if the verification result of the connection record indicates that no corresponding record exists, the system will create a new connection record for the transfer request and mark its status as "initialized". Subsequently, the system calls the transfer business interface to execute the transfer operation. After the operation is completed, depending on whether the transfer was successful, the status of the connection record is updated to "success" or "failure", and the result is returned to the client. In this way, even in the event of network anomalies or other circumstances, the system can ensure that each business request is processed correctly and effectively.

[0077] In one feasible implementation, step S3000 may include steps S3100 to S3300:

[0078] Step S3100: If the verification result of the docking record is that there is no request docking record, then generate the request docking record corresponding to the business request and enter it into the request docking record table;

[0079] Step S3200: Identify the task type of the service request;

[0080] Step S3300: Set the interface status of the target business interface corresponding to the business request based on the task type, and synchronize the interface status to the request docking record table.

[0081] It should be noted that in this embodiment, the verification of connection records, processing of business requests, and state synchronization are the core steps to ensure the consistency of distributed transactions. The verification result of the connection record indicates whether a corresponding request connection record already exists, which determines whether a new connection record needs to be generated and entered into the request connection record table. As part of the database, the connection record table records the status of each request executed by the server-side interface and is key to achieving idempotency. Task type identification allows the system to select an appropriate processing strategy based on the characteristics of the business request. For asynchronous tasks, the interface status is set to running, while for non-asynchronous tasks, it is set to the initialization state. This design enables the system to flexibly handle different types of business requests.

[0082] Additionally, it should be noted that synchronizing the interface status to the request connection record table is to maintain data consistency and traceability. Regardless of whether the request is successful or failed, the corresponding status can be found in the connection record table, which is crucial for subsequent troubleshooting and system optimization.

[0083] For example, in one feasible implementation, the system first receives a transfer request and then performs parameter validation. If the validation passes, the system queries the request connection record table to determine if a connection record for the transfer request already exists. If it doesn't exist, the system generates a new connection record and sets its status to initialization, then enters the data into the request connection record table. Next, the system recognizes that this is a non-asynchronous transfer task, therefore setting the target business interface status to initialization and synchronizing this status to the request connection record table. Subsequently, the system calls the target business interface to execute the transfer operation, updating the interface status to running. After the transfer operation is completed, the system sets the interface status to successful or failed based on whether the transfer was successful, and synchronizes the final status to the request connection record table for subsequent querying and auditing.

[0084] In one feasible implementation, step S3300 may include steps S3310 to S3320:

[0085] Step S3310: If the business request is not an asynchronous task business request, then set the target business interface state corresponding to the business request to the initialization state;

[0086] Step S3320: If the business request is an asynchronous task business request, then set the status of the target business interface corresponding to the business request to the running state.

[0087] It should be noted that in this embodiment, setting the state of the target business interface according to the task type of the business request is a key step in achieving server-side idempotency. Idempotency means that the server-side interface can correctly handle duplicate requests without changing the system state or causing additional impact. After the request record is entered into the table, the state is the initialization state. After execution begins, the state changes to running. If the business request does not involve asynchronous processing, it can be considered to be in the running state as soon as it is entered into the table. After entering the running state, it can change to a success or failure state depending on whether the execution is successful. After success, the state cannot continue to flow. If the upstream retryes, or the system automatically retryes internally, the retry strategy for the specific scenario can be used to decide whether to flow the failed record back to the initialization state for re-execution, or directly return the previous error information.

[0088] Asynchronous task requests refer to those that require server-side background execution and may take a considerable amount of time to complete, such as large-scale data processing or long-running computational tasks. For these requests, the system sets their status to "running" to reflect their ongoing execution process. Conversely, non-asynchronous task requests typically refer to those that can be processed immediately and return results, such as simple data queries or instant data updates. These requests are set to "initialized," indicating that they are ready to begin execution.

[0089] Additionally, it's important to note that synchronizing the interface status to the request connection record table ensures that every part of the system can access the latest request status information. This synchronization mechanism is a crucial means of achieving distributed transaction consistency, allowing the system to accurately understand the current status of each request at any point in the processing, thereby enabling it to make correct decisions.

[0090] For example, in one feasible implementation, when the system receives a business request from a client, it first performs parameter validation. If the validation passes, the system queries the request connection record table to determine if the request already exists. If it does not exist, the system creates a new connection record for the request and sets the corresponding interface status based on whether the request is an asynchronous task. For an asynchronous data import task, the system sets its status to "Running," while for a simple account balance query request, it sets it to "Initializing." Subsequently, the system synchronizes these statuses to the request connection record table so that other system components or auditing tools can access and monitor this information. During execution, the system updates the status based on the actual execution result of the task, such as success or failure, and synchronizes it again to the connection record table to ensure eventual data consistency.

[0091] This embodiment provides a data processing method that receives a business request sent by a client; in response to the parameter verification result of the business request, queries a preset request connection record table to determine if a corresponding request connection record exists, obtaining a connection record verification result; and processes the business request based on the connection record verification result, the request connection record table, and the target business interface corresponding to the business request. This method introduces a request connection record table to manage client business requests, achieving idempotency of the server-side interface, thereby simplifying the request processing flow and reducing the complexity caused by repeatedly processing the same requests. Furthermore, since this solution does not rely on a specific distributed transaction framework, it reduces limitations on the technology stack and lowers maintenance costs and difficulties.

[0092] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 The data processing method further includes steps S3400 to S3600 in step S3000:

[0093] Step S3400: Invoke the target business interface to execute the business request, and set the status of the target business interface to the running state;

[0094] Step S3500: Obtain the execution result of the target business interface executing the business request;

[0095] Step S3600: Set the status of the target business interface to either successful or failed execution based on the execution result.

[0096] It should be noted that, in this embodiment, the core process of business request processing covers the complete operation from calling the business interface to obtaining the execution result, and then updating the interface status. In this process, the target business interface refers to the interface in the system used to execute specific business logic, such as the interface for processing payments or updating data. The "running" status indicates that the business request is being processed, while the "execution successful" or "execution failed" status indicates that the business request has been successfully completed or that an error was encountered during processing, respectively.

[0097] Additionally, it's important to note that the purpose of this process is to ensure that business requests are processed correctly and reliably, and that processing results are provided promptly. By setting the interface status to "running," the system prevents duplicate processing of business requests during the actual processing phase. After obtaining the execution results, updating the interface status based on those results allows the system to accurately understand the processing status of each business request and provides a basis for subsequent decision-making.

[0098] For example, in one feasible implementation, the system first receives and verifies the business request sent by the client. After successful verification, the system queries the request connection record table to determine if a corresponding connection record exists. If it does not exist, the system generates a new connection record and sets the status of the target business interface according to the task type of the business request. For an asynchronous data import task, the system sets its status to running and then calls the target business interface to begin task execution. During task execution, the system continuously monitors the task status and obtains the execution result upon task completion. If the task completes successfully, the system updates the interface status to successful execution; if the task fails, it updates it to failed execution and records the reason for failure in the connection record table for troubleshooting and subsequent processing. In this way, the system can ensure that each business request is properly processed and that its processing results are accurately recorded and fed back.

[0099] In one feasible implementation, steps A1000 to A5000 may be included before step S1000:

[0100] Step A1000: Obtain the query result of whether the client supports idempotent settings for the target business interface;

[0101] Step A2000: If the target business interface does not support idempotency settings, then query the preset request connection record table to see if there is a request connection record corresponding to the business request;

[0102] Step A3000: If the business request connection record exists, obtain and return the request connection record to the client;

[0103] Step A4000: If the business request connection record does not exist, generate the request connection record corresponding to the business request and return it to the client;

[0104] Step A5000: If the target service interface supports idempotent settings or responds to the confirmation request command generated by the client, execute the following steps:

[0105] Receive business requests sent by the client.

[0106] It should be noted that in this embodiment, to ensure the server can correctly identify and process client requests, especially for business interfaces that do not support idempotency, and for scenarios where the server is not suitable for idempotency, such as after a failure has already executed a series of irreversible business logic (e.g., notifying the user of failure via SMS), the client needs to verify the server's status before calling it. Based on the server's status, the client decides whether to call the server. For details, please refer to... Figure 6 , Figure 6This diagram illustrates the server-side verification process for non-idempotent interfaces in the request processing method described in this application. Idempotency means that executing a request multiple times has the same effect as executing it once. For business interfaces that do not support idempotency, the same request may produce different system states or effects. Therefore, the system needs to pre-check whether the target business interface supports idempotency settings to determine the subsequent processing strategy.

[0107] Additionally, it's important to note that if the target business interface does not support idempotency, the system will query the request connection record table to check if a corresponding request connection record already exists. This step is necessary because it helps the system avoid repeatedly processing the same business requests, thereby maintaining data consistency and integrity. The existence or absence of a connection record directly determines the system's action: if a connection record exists, the system will return the record to the client, informing them that the request is being processed or has been completed; if no connection record exists, the system will generate a new connection record and return it to the client, indicating that the request has been accepted and is ready to begin processing.

[0108] The verification interface should inform the client, based on the status of the connection record, whether the current request corresponds to a business function that has not been executed, is in progress, has been successfully executed, or has failed. If no data is found in the connection record, the verification interface will automatically add a record to the connection record table, creating a mutual exclusion with the business request. This prevents the verification request and the business request from being received almost simultaneously, which could lead to inaccurate verification results. Since the server-side interface does not support idempotency, it does not support error retries. Therefore, the client needs to generate a new business primary key and request the server to execute the relevant business logic again.

[0109] In one feasible implementation, the method further includes steps B1000 to B4000:

[0110] Step B1000: Query the request connection record table according to the preset time interval to see if there is a request connection record with a response timeout;

[0111] Step B2000: If there is a request connection record with a response timeout, then determine the timeout request and timeout business interface corresponding to the timeout request connection record.

[0112] Step B3000: Query the service processing data of the timeout service interface;

[0113] Step B4000: Determine the execution result of the timeout request based on the business processing data, and set the interface status of the timeout business interface according to the execution result of the timeout request.

[0114] It should be noted that in this embodiment, during the process of the system calling the target business interface to execute a business request, there is a small probability that a server-side thread may be killed by the system, or the application may restart, resulting in incomplete execution of business logic, which may cause a certain request to not complete. In this case, different situations and handling methods exist depending on the point of logic interruption. This solution uses... Figure 4 For example, we will analyze various situations.

[0115] If execution is interrupted anywhere before transaction 2, the data to be connected has not been entered into the database, and the client experiences a read timeout error, the client only needs to retry to recover;

[0116] If the connection is broken between transaction 2 and transaction 3, and the status of the connected record is initialized, the client will report an error when reading the record and the client will still be able to retry and recover.

[0117] If the connection is broken between transaction 3 and transaction 4, the status of the connection record is "running". The client will encounter an error when reading. The transaction of the business data will automatically roll back after the connection is broken, which means that the business logic is not executed. Since the server will unconditionally reject duplicate requests for the connection record with the status of "running", the status of this business connection record will remain "running" and cannot be transferred. The client will also be unable to retry and recover.

[0118] If the connection is broken between transaction 4 and transaction 5, the connection record is still running. The client will encounter a read timeout error. At this point, the business operation has been completed, but the status of the connection record is still running, causing the connection status to be inconsistent with the actual business status. At the same time, the client will think that the business operation has failed, and the client and server transactions will also be inconsistent.

[0119] To address the above scenario, this embodiment designs an exception recovery mechanism, such as... Figure 6 As shown, Figure 6 This diagram illustrates the server-side execution exception timeout recovery logic for the request processing method in this application. A timeout period is designed for each server-side interface. If a client request is received but the timeout period has expired and the request is still in the processing state, the server-side status is considered abnormal. In this case, it is necessary to query the relevant business data of the interface to determine whether the interface has executed successfully. If successful, it is marked as successful; if it has not completed or failed, it is marked as failed. For failed interfaces, the retry strategy will determine whether the next client request can be executed again.

[0120] In this embodiment, the system periodically (according to a preset time interval) checks the request connection record table to check for any timeout requests. A timeout means that the business request sent by the client failed to be completed in a timely manner by the server, which may be due to server resource constraints or complex request processing logic. Once a timeout request connection record is found, the system will determine the specific business request and business interface corresponding to these records. This is to accurately identify the problem and take appropriate remedial measures to help the server's connection record status automatically recover and to help the client retry after a failure.

[0121] Additionally, it should be noted that the system will query the business processing data of these timeout service interfaces, including but not limited to transaction status and intermediate processing results in the database. By analyzing this data, the system can determine the actual execution status of the business request, such as whether it was partially completed or interrupted for a specific reason. Based on this information, the system will update the status of the timeout service interface. If the business logic has been completed, the status will be set to success; if it is determined that the business logic has not been executed or has failed, the status will be set to failure, and the system will decide whether to allow the client to re-initiate the request according to the system's retry policy.

[0122] For example, in one feasible implementation, a client initiates a data import request, but the request times out due to resource bottlenecks encountered by the server. After detecting this timeout via a scheduled task, the system immediately queries the request interface record table to identify the timed-out request and its corresponding business interface. Subsequently, the system queries the business processing data and finds that the data import operation has been partially completed, but failed to be fully completed due to resource issues. Based on this information, the system sets the business interface status to failed and notifies the client of the request's processing result, while providing options for retrying or rolling back. In this way, the client can decide on its next step based on the system feedback, and the server can also improve the system's stability and reliability.

[0123] This embodiment provides a data processing method. It queries the request connection record table at preset time intervals to check for requests that have timed out. If a timed-out request connection record exists, it identifies the timed-out request and the timed-out business interface corresponding to that record. It then queries the business processing data of the timed-out business interface. Based on the business processing data, it determines the execution result of the timed-out request and sets the interface state of the timed-out business interface according to the execution result. This method ensures that even when the server processes a timeout, the system can accurately identify and respond to the state of the business request, thereby improving the robustness and reliability of the system, avoiding business data inconsistency or loss due to timeouts, and ensuring the integrity and correctness of distributed transaction processing.

[0124] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0125] This application also provides a data processing apparatus, please refer to... Figure 7 The data processing device includes:

[0126] The receiving module is used to receive business requests sent by the client;

[0127] The verification module is used to respond to the parameter verification result of the business request, query the preset request connection record table to see if there is a request connection record corresponding to the business request, and obtain the connection record verification result.

[0128] The processing module is used to process the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request.

[0129] The data processing apparatus provided in this application, employing the data processing method described in the above embodiments, can solve the technical problems of data processing. Compared with the prior art, the beneficial effects of the data processing apparatus provided in this application are the same as those of the data processing method described in the above embodiments, and other technical features in the data processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0130] This application provides a data processing apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data processing method in Embodiment 1 above.

[0131] The following is for reference. Figure 8This document illustrates a structural diagram of a data processing device suitable for implementing embodiments of this application. The data processing device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The data processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0132] like Figure 8 As shown, the data processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the data processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the data processing device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show data processing devices with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0133] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0134] The data processing device provided in this application adopts the data processing method in the above embodiments. Compared with the prior art, the beneficial effects of the data processing device provided in this application are the same as those of the data processing method provided in the above embodiments. Furthermore, the other technical features of the data processing device are the same as those disclosed in the method of the previous embodiment, and will not be described in detail here.

[0135] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0137] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data processing method described in the above embodiments.

[0138] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0139] The aforementioned computer-readable storage medium may be included in a data processing device or may exist independently without being assembled into a data processing device.

[0140] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by the data processing device, the data processing device receives a business request sent by the client; in response to the parameter verification result of the business request, it queries a preset request connection record table to see if there is a request connection record corresponding to the business request, and obtains the connection record verification result; and processes the business request according to the connection record verification result, the request connection record table, and the target business interface corresponding to the business request.

[0141] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0143] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0144] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for performing the above-described data processing method, thereby solving the technical problem of data processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the data processing method provided in the above embodiments, and will not be repeated here.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data processing method described above.

[0146] The computer program product provided in this application can solve the technical problems of data processing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the data processing method provided in the above embodiments, and will not be repeated here.

[0147] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A request processing method, characterized in that, The method includes: Retrieve query results to determine whether the client supports idempotency settings for the target business interface; If the target business interface does not support idempotency settings, then query the preset request connection record table to see if there is a request connection record corresponding to the business request; If the aforementioned business request connection record exists, then obtain and return the request connection record to the client; If the business request connection record does not exist, a request connection record corresponding to the business request is generated and returned to the client; If the target service interface supports idempotent settings or responds to a confirmation request instruction generated by the client, the following steps are executed: receiving a service request sent by the client; In response to the parameter verification result of the business request, the system queries the preset request connection record table to see if there is a request connection record corresponding to the business request, and obtains the connection record verification result. The request connection record includes at least one of the following fields: request ID, request content, processing status, server interface execution strategy, and server interface execution exception information. Based on the verification results of the connection record, the request connection record table, and the target business interface corresponding to the business request, the business request is processed, including: If the verification result of the connection record is that there is no request connection record, then the request connection record corresponding to the business request is generated and entered into the request connection record table; Identify the task type of the business request; Based on the task type, set the interface status of the target business interface corresponding to the business request, and synchronize the interface status to the request connection record table, including: If the business request is not an asynchronous task business request, then the state of the target business interface corresponding to the business request is set to the initialization state; If the business request is an asynchronous task business request, then the status of the target business interface corresponding to the business request is set to the running state; During the execution of the business request, the status of the target business interface is updated to success or failure based on the actual execution result, and the updated status is synchronized to the request connection record table. The business request is processed according to the request connection record table and the interface status of the target business interface, wherein the status includes, but is not limited to, initialization, running, success, or failure.

2. The method as described in claim 1, characterized in that, The step of processing the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request further includes: Invoke the target business interface to execute the business request, and set the status of the target business interface to the running state; Obtain the execution result of the target business interface executing the business request; Based on the execution result, the status of the target business interface is set to either execution success or execution failure.

3. The method as described in claim 2, characterized in that, The method further includes: The system queries the request connection record table at preset time intervals to check if there are any request connection records that have timed out. If there is a request connection record with a timeout response, then determine the timeout request and timeout business interface corresponding to the timeout request connection record. Query the business processing data of the timeout service interface; The execution result of the timeout request is determined based on the business processing data, and the interface status of the timeout business interface is set according to the execution result of the timeout request.

4. A data processing apparatus, characterized in that, The device includes: The receiving module is used to obtain the query result of the client regarding whether the target business interface supports idempotency settings; if the target business interface does not support idempotency settings, it queries a preset request connection record table to see if there is a request connection record corresponding to the business request; if the business request connection record exists, it obtains and returns the request connection record to the client; if the business request connection record does not exist, it generates a request connection record corresponding to the business request and returns it to the client; if the target business interface supports idempotency settings or responds to the confirmation request instruction generated by the client, the following step is executed: receiving the business request sent by the client; The verification module is used to respond to the parameter verification result of the business request, query whether there is a request connection record corresponding to the business request in the preset request connection record table, and obtain the connection record verification result. The request connection record includes at least one of the following fields: request ID, request content, processing status, server interface execution strategy, and server interface execution exception information. The processing module is used to process the business request based on the verification result of the docking record, the request docking record table, and the target business interface corresponding to the business request. This includes: if the verification result indicates that no request docking record exists, generating a request docking record corresponding to the business request and entering it into the request docking record table; identifying the task type of the business request; setting the interface status of the target business interface corresponding to the business request based on the task type, and synchronizing the interface status to the request docking record table, including: if the business request is not an asynchronous task business request, setting the target business interface status corresponding to the business request to an initialization state; if the business request is an asynchronous task business request, setting the target business interface status corresponding to the business request to a running state; during the execution of the business request, updating the status of the target business interface to success or failure based on the actual execution result, and synchronizing the updated status to the request docking record table; and processing the business request based on the request docking record table and the interface status of the target business interface, wherein the status includes, but is not limited to, initialization, running, success, or failure.

5. A data processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the request processing method as described in any one of claims 1 to 3.

6. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the request processing method as described in any one of claims 1 to 3.

7. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the request processing method as described in any one of claims 1 to 3.

Images