Batch service data processing method and related equipment

Abstract

The embodiment of the invention discloses a batch service data processing method and related equipment, which are used for avoiding rollback of a whole batch of service data caused by processing failure of a single service entity and improving the batch service data processing efficiency. The method comprises the following steps: acquiring batch service processing requests for a plurality of service entities; constructing a transaction unit for each business entity; packaging a plurality of data operations corresponding to the service entity into a data operation sequence; respectively executing the data operation sequence of each transaction unit on one or more business processing nodes, enabling each data operation to execute local business operation on the corresponding business processing node so as to complete business data change, and recording the execution state of each transaction unit in a transaction log; and according to the execution state of each transaction unit recorded in the transaction log, submitting or rolling back the changed business data of each transaction unit so as to reserve the changed business data in the successfully executed transaction unit and revoke the changed business data in the unsuccessfully executed transaction unit.

Description

Technical Field

[0001] This application relates to the field of distributed computing, and more particularly to batch business data processing methods and related equipment. Background Technology

[0002] With the widespread application of distributed systems, batch processing tasks such as batch data import, batch order generation, and batch account changes are very common. Batch processing typically requires handling multiple business entities simultaneously, each often involving writing to or updating multiple business tables, and sometimes even spanning multiple service nodes and data sources. To ensure data consistency across different nodes and data sources, existing distributed systems typically employ distributed transactions or global transactions. A transaction coordinator initiates and schedules local transaction operations on participating nodes, and, when necessary, uses compensating transactions to make commit or rollback decisions in case of overall success or failure, thus maintaining the consistency between distributed system data and business logic.

[0003] In existing technologies, a common practice is to encapsulate the processing of an entire batch of business entities within a single global transaction. This involves a transaction coordinator initiating the global transaction, processing all business entities in the batch sequentially during its duration, and writing and validating data in the main and subsidiary tables for each entity. Only when all operations on all entities in the batch are successful is the transaction coordinator notifying each node to officially save and apply the data changes generated by this batch of operations. If any entity fails at any step during processing, a global transaction rollback is triggered, undoing all previously completed data writes. This results in the data of other successfully processed business entities not being effectively preserved, affecting not only the final data integrity but also wasting computing and storage resources and reducing the overall processing efficiency of the distributed system. Summary of the Invention

[0004] Based on the above problems, this application provides a batch business data processing method and related equipment. The purpose is to enable changes to business data corresponding to each business entity to be submitted or rolled back according to their own execution results, thereby avoiding the overall rollback of the entire batch of business data due to the failure of a single business entity, and improving data integrity and resource utilization efficiency in the batch processing process.

[0005] In a first aspect, embodiments of this application provide a method for batch business data processing, including:

[0006] Obtain batch business processing requests for multiple business entities;

[0007] For each of the aforementioned business entities, a transaction unit is constructed;

[0008] Encapsulate multiple data operations corresponding to the business entity into a data operation sequence;

[0009] The data operation sequence of each transaction unit is executed on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and the execution status of each transaction unit is recorded in the transaction log.

[0010] Based on the execution status of each transaction unit recorded in the transaction log, the business data changed by each transaction unit is committed or rolled back, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units.

[0011] Secondly, embodiments of this application also provide a batch business data processing apparatus, including:

[0012] The request retrieval unit is used to retrieve batch business processing requests for multiple business entities.

[0013] A construction unit is used to construct a transaction unit for each of the aforementioned business entities;

[0014] An encapsulation unit is used to encapsulate multiple data operations corresponding to the business entity into a data operation sequence;

[0015] An execution scheduling unit is used to execute the data operation sequence of each transaction unit on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and records the execution status of each transaction unit in the transaction log.

[0016] The transaction decision unit is used to commit or roll back the business data changed by each transaction unit according to the execution status of each transaction unit recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units.

[0017] Thirdly, embodiments of this application also provide a computer device, including:

[0018] Central processing unit, memory, input / output interfaces;

[0019] The memory is either a short-term storage memory or a persistent storage memory;

[0020] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the batch business data processing method described in the first aspect of the embodiments of this application or any specific implementation thereof.

[0021] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to implement the batch business data processing method described in the first aspect or any specific implementation of the first aspect of the embodiments of this application.

[0022] Fifthly, embodiments of this application also provide a computer program product storing a computer program / instruction thereon, which, when executed by a processor, is used to implement the batch business data processing method described in the first aspect or any specific implementation of the first aspect of the embodiments of this application.

[0023] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0024] This application embodiment breaks down each business entity in batch processing into an independent transaction unit, and encapsulates all data operations within each transaction unit into a data operation sequence. Local business operations are executed independently on the corresponding business processing node to change the business data. The execution status of each transaction unit is recorded, and the final decision on whether to commit or rollback is based on the status of each transaction unit. Therefore, when committing or rolling back the changed business data of each transaction unit according to the transaction log, the changes to the business data of each business entity can be independently retained or revoked. This ensures that if a data operation in a transaction unit fails in a batch task, only the data corresponding to the failed transaction unit can be rolled back, without affecting the business data changes generated by other successfully executed data operations. This guarantees the data integrity and consistency of the batch processing results at the business entity level, avoiding redundant resource consumption caused by the rollback of all business data due to the failure of data operations on some business entities, and reducing system burden and performance waste. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0026] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0027] Figure 2 This application provides another system architecture schematic diagram;

[0028] Figure 3 This application provides a schematic flowchart of a batch business data processing method.

[0029] Figure 4 A schematic diagram of the execution flow within a single transaction unit provided in an embodiment of this application;

[0030] Figure 5 Another system architecture diagram provided for an embodiment of this application;

[0031] Figure 6 This application provides a schematic diagram of a batch onboarding and import task process.

[0032] Figure 7 A schematic diagram of a batch business data processing device provided in this application embodiment;

[0033] Figure 8 This is a schematic diagram of a computer device structure provided in an embodiment of this application. Detailed Implementation

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

[0035] The batch business data processing method provided in this application embodiment can be applied to, for example, Figure 1In the system architecture shown, terminal 102 communicates with server 101 via a network to receive batch business processing requests from terminal 102 and return processing results. Data storage system 100 can be used to store business data, log data, and business-related configuration data generated during batch business processing. Data storage system 100 can be integrated on server 101 or placed on the cloud or other network servers. Terminal 102 can be various computing or display devices with network access capabilities, including but not limited to various personal computers, laptops, smartphones, tablets, and portable wearable devices, such as smartwatches, smart bracelets, and head-mounted devices. Terminal 102 initiates HTTP / API calls to server 101 through a browser, client program, or other application interface to complete the batch business request initiation and result display. Server 101 can be implemented using a standalone server or a server cluster composed of multiple servers. In this embodiment, data storage system 100 can be a standalone physical storage server, a distributed storage system composed of multiple storage nodes, or a cloud storage system providing services such as object storage, relational databases, cache databases, cloud databases, and cloud storage. For example, the data storage system 100 can be implemented using a distributed file system, a NoSQL database (such as MongoDB, Redis), a relational database (such as MySQL, PostgreSQL), or a cloud storage service (such as Alibaba Cloud OSS, Huawei Cloud OBS, etc.). The specific type of the data storage system 100 can be flexibly configured according to the actual deployment environment and business needs, but is not limited to the above examples.

[0036] Based on the above system, such as Figure 2As shown, server 101 can deploy functional components such as an application server cluster, a transaction coordinator service, and a business processing node cluster. The application server cluster handles HTTP / API calls from user terminals. After request parsing, it delivers batch business processing to the transaction coordinator service via internal Remote Procedure Call (RPC) technology or as events. The transaction coordinator service, as the execution unit of the batch business data processing method, constructs transaction units at the business entity level based on the batch business processing requests, generates data operation sequences for each transaction unit, schedules each transaction unit to the business processing node cluster for execution, and records the execution status of each transaction unit and compensation operation instructions related to data operations in the transaction log database. The business processing node cluster can include multiple service nodes targeting different business domains, such as node 1 for employee services, node 2 for document services, and node 3 for education services. Each node is connected to the business database and completes local business operations related to its own node's business within a local database session. The business database is used to store various business table data, such as the employee master table, certificate table, education experience table, etc.; the transaction log database is used to store log data such as transaction unit status table, operation log table, compensation operation instruction table, etc. related to batch transactions, so as to support the transaction coordinator service to commit and confirm or compensate and roll back the business data corresponding to each transaction unit based on the log records.

[0037] It should be noted that the method provided in this application can be executed independently on the server side, independently on the terminal side, or collaboratively by the terminal and the server. For example, in scenarios with high local deployment requirements, the terminal can locally integrate transaction coordination logic and business processing nodes, and complete the construction, execution, and rollback of batch business data by accessing local or embedded data storage systems; in centralized deployment scenarios, the construction, scheduling, and execution of all transaction units can be completed by the server side, and the terminal is only responsible for initiating batch business requests and displaying the processing results; in resource-constrained or edge computing scenarios, the terminal device can preprocess some business data and generate a set of business entities, and the server side can complete the division of transaction units, processing of batch business data, and commit or rollback processing based on transaction logs based on this set of business entities, thereby realizing collaborative computing between the terminal and the server. Figure 1 The system architecture shown in the embodiments is intended to more clearly illustrate the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0038] The method of this application will be further described in detail below, and some specific possible implementation examples will be provided.

[0039] This application provides a method for batch business data processing, such as... Figure 3 As shown, the method includes steps S301-S305.

[0040] S301: Obtain batch business processing requests for multiple business entities;

[0041] Here, a business entity refers to an object that can be processed independently and has business meaning in a real business scenario, such as a single order, a single account, or a single contract record, without being limited to a specific business type. Batch business processing requests can be initiated through user terminals or triggered by upstream systems via API calls; a batch business processing request can contain the identifiers of multiple business entities to be processed, along with their corresponding business data content or data reference information.

[0042] S302: Construct a transaction unit for each business entity;

[0043] A transaction unit refers to a logical set of transactions that manages the execution status of related data operations at the granularity of a single business entity or a set of business entities determined according to preset division rules. Since a transaction unit contains data change operations related to the corresponding business entity, it can also be understood as the smallest control unit in this application embodiment that performs commit or rollback judgments.

[0044] Taking batch order generation as an example, in existing technologies, a common practice is to encapsulate the insertion and update operations of a batch of orders within a single global transaction. Once the global transaction is started, each order is sequentially written to the main order table, order details table, discount record table, etc., until all data tables corresponding to the batch of orders have been processed. If, during the process, a single order fails to be written due to insufficient inventory, payment verification failure, or data anomalies, the entire global transaction is rolled back, meaning that data that has already been successfully written is also undone. As a result, even if the vast majority of orders have complete business data and have been successfully written to the database, they cannot take effect in this batch processing. Therefore, these orders must be reprocessed subsequently, wasting computing and storage resources, extending business processing latency, and reducing the efficiency of batch business data processing.

[0045] In this embodiment, when batch requests arrive, a transaction unit is constructed for each order. The write and update operations of the order on multiple business tables, such as the order master table, order details table, discount record table, and delivery information table, are encapsulated into a data operation sequence and executed step by step on the corresponding business processing node in a local transaction manner. For orders with complete business conditions and all data operations completed successfully, the execution status of the corresponding transaction unit is marked as successful in the transaction log, thereby retaining all business data changes within the transaction unit so that the order can take effect normally. For orders where any step of the operation fails for any reason, only the failed transaction unit is marked as failed, and a compensation operation or rollback process is triggered for the transaction unit, thereby undoing the data changes already generated for the transaction unit without affecting the validity of data in other successfully executed order transaction units.

[0046] S303: Encapsulate multiple data operations corresponding to a business entity into a data operation sequence;

[0047] Data operations refer to local business operations such as writing, updating, or deleting one or more data records in a business data storage system. Examples include inserting records into the main table, updating fields in a subsidiary table, and deleting invalid records. Each data operation can be understood as a change to the business database. A data operation sequence is a collection of multiple data operations arranged in a pre-defined business process order with sequential dependencies. Encapsulating multiple data operations into a unified data operation sequence facilitates the step-by-step execution according to the established business logic order and also makes it easier to refer to the business logic order for processing during rollback.

[0048] S304: Execute the data operation sequence of each transaction unit on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and record the execution status of each transaction unit in the transaction log;

[0049] Business processing nodes can be one or more service instances, microservice nodes, or functional modules deployed in a distributed system, used to execute specific business logic and data access operations. Each business processing node is responsible for completing local business operations within its own scope. Local business operations refer to data change processes initiated and completed within a single business processing node, such as performing insert, update, or delete operations and completing commit or rollback within a single database session. In this embodiment, each data operation is executed on its respective business processing node in a local transaction manner, thereby ensuring the atomicity of the data change locally. A transaction log is maintained for each transaction unit to record the execution result of each data operation and the execution status of the transaction unit. The execution status recorded in the transaction log can include at least preset states such as in progress, successful execution, failed execution, compensation in progress, and rolled back.

[0050] S305: Based on the execution status of each transaction unit recorded in the transaction log, commit or roll back the business data changed in each transaction unit to retain the changed business data in successfully executed transaction units and undo the changed business data in failed transaction units.

[0051] When the transaction log indicates that all data operations within a transaction unit have been successfully executed without errors in the local transaction of the corresponding business processing node, the transaction unit can be marked as successful, and the business data changes of that transaction unit in each business database will remain valid, which is considered as the completion of the transaction commit for that business entity. When the transaction log indicates that one or more data operations within a transaction unit have failed, a compensation rollback based on the Saga pattern is triggered. That is, based on the information of the successful data operations recorded in the transaction log for that transaction unit, the corresponding compensation operation instructions and execution order are determined, and the compensation operation instructions are triggered to undo the business data changes already generated by that transaction unit.

[0052] In one implementation, all compensation operations can be idempotent, thus ensuring that in cases such as network retries, multiple executions of the compensation operation instruction have the same effect as a single execution, guaranteeing the reliability of the rollback operation.

[0053] This application embodiment breaks down each business entity in batch processing into an independent transaction unit, and encapsulates all data operations within each transaction unit into a data operation sequence. Local business operations are executed independently on the corresponding business processing node to change the business data. The execution status of each transaction unit is recorded, and the final decision on whether to commit or rollback is based on the status of each transaction unit. Therefore, when committing or rolling back the changed business data of each transaction unit according to the transaction log, the changes to the business data of each business entity can be independently retained or revoked. This ensures that if a data operation in a transaction unit fails in a batch task, only the data corresponding to the failed transaction unit can be rolled back, without affecting the business data changes generated by other successfully executed data operations. This guarantees the data integrity and consistency of the batch processing results at the business entity level, avoiding redundant resource consumption caused by the rollback of all business data due to the failure of data operations on some business entities, and reducing system burden and performance waste.

[0054] In one embodiment, a data operation sequence for each transaction unit is executed on one or more business processing nodes, so that each data operation performs a local business operation on the corresponding business processing node to complete the business data change, and the execution status of each transaction unit is recorded in a transaction log. This includes: for each transaction unit, executing each data operation in the data operation sequence sequentially on one or more business processing nodes, so that each data operation performs a local business operation on the corresponding business processing node to complete the business data change; for each data operation, writing a compensation operation instruction that is the reverse of the data operation execution logic into the transaction log; and recording the business data change information corresponding to each data operation and the execution status of each data operation into the transaction log, so as to record the execution status of the transaction unit in the transaction log.

[0055] Executing data operation sequences for each transaction unit on one or more business processing nodes essentially involves breaking down multi-step data changes related to a business entity and distributing them to the corresponding business processing nodes. Each business processing node then performs local business operations such as writing, updating, or deleting data within its own local transaction environment. Business processing nodes can be service instances or microservice components deployed in a distributed system, such as order service nodes, account service nodes, and inventory service nodes, without being limited to a specific implementation method. As mentioned earlier, a data operation sequence is a pre-determined set of ordered operations based on the business process, encompassing the data processing order and dependencies within a transaction unit. During execution, data operations can be selected sequentially according to this data operation sequence and assigned to the corresponding business processing nodes. Each business processing node then initiates a local database transaction within its session with the database to execute the specific data change logic, such as executing a Structured Query Language (SQL) statement. If the SQL statement executes successfully and passes validation, the local transaction is committed, making the data changes persistent in the database. If any errors or validation failures occur during execution, the local transaction is immediately rolled back, undoing all changes made to the database within this session.

[0056] During the above execution process, for each data operation, a compensation operation instruction with the opposite execution logic is generated simultaneously with the execution of this local transaction, and this compensation operation instruction is written to the transaction log. The compensation operation instruction can be understood as a reverse operation instruction used to offset the effects of existing data changes when a rollback is needed. For example, when a data operation A1 inserts a new order record into the order master table, the compensation operation instruction for data operation A1 could be to delete the record according to the order's primary key; when a data operation A2 updates the account balance field from 10 to 2, the compensation operation instruction for data operation A2 could be to set the account balance field back to 10.

[0057] Furthermore, after each data operation is completed, the corresponding business data change information and the execution status of that data operation are recorded in the transaction log, thus recording the execution process of the current transaction unit in the transaction log. Business data change information may include, but is not limited to, the target business table identifier, primary key information, and a summary of the old and new values ​​of a certain field; the execution status may include at least successful execution, failed execution, or not executed. In this way, the transaction coordinator can subsequently perform confirmation operations for success or compensation operations for failure for each transaction unit based on the status recorded in the transaction log, improving the controllability and reliability of batch business processing in fault scenarios.

[0058] In one embodiment, based on the execution status of each transaction unit recorded in the transaction log, the business data changed by each transaction unit is committed or rolled back to retain the changed business data in successfully executed transaction units and undo the changed business data in failed transaction units. This includes: for each transaction unit, if it is determined from the transaction log that all data operations of the transaction unit have been successfully executed, then a confirmation instruction is sent to the business processing node corresponding to each data operation to make the changed business data in each business processing node valid; if it is determined from the transaction log that there are failed data operations in the transaction unit, then based on the successful data operations of the transaction unit recorded in the transaction log, a preset compensation operation instruction corresponding to each successful data operation and the execution order of each compensation operation instruction are determined, and the execution status of the transaction unit in the transaction log is updated after each compensation operation instruction is executed.

[0059] When processing each transaction unit, the system first determines, based on the transaction log, whether all data operations related to that transaction unit have completed the expected business data changes in their respective business processing nodes' local transactions. In other words, it checks whether all data operations within the transaction unit have been successfully executed and marked as successful in the transaction log, with no unexecuted or failed records. In this case, no additional rollback or compensation operations are needed for the business data of that transaction unit. Instead, a confirmation instruction is sent to the business processing nodes corresponding to each data operation, notifying them to maintain the results of the previously completed local business operations in a valid state. This "valid state" means that the business data changes generated by the data operations of the current transaction unit will continue to take effect in subsequent business reads and writes, rather than being temporary data; for example, order records can be read by subsequent shipping processes. This allows each successfully executed, error-free transaction unit to independently complete its local transaction commit, avoiding the situation in existing technologies where the failure of a single business entity leads to the complete rollback of the entire batch of business data.

[0060] For transaction units where the transaction log indicates the presence of failed data operations, a rollback is performed on that transaction unit using the successful data operations recorded in the transaction log and pre-written compensation operation instructions. Specifically, when a failed data operation is determined within a transaction unit, all successful data operation records related to that transaction unit are extracted from the transaction log, and the pre-defined compensation operation instructions and their execution order for each successful data operation are determined accordingly. The compensation order can be determined based on information such as the data operation sequence number or time sequence stored in the transaction log, and is not limited to a specific implementation method. Compensation operation instructions can be specific operations used to delete inserted records, restore old values, or undo a certain business state. The execution order is usually the reverse of the original data operation sequence; that is, operations executed earlier are compensated later, and operations executed later are compensated first, to avoid disrupting the original dependencies between data during the rollback process.

[0061] After determining the compensation operation instructions, they can be executed sequentially according to the predetermined execution order. The target compensation operation instruction contains location parameters, which are used to send the parsed instruction to the corresponding business processing node. This node then executes the specific reverse business logic based on the type and parameters of the compensation operation instruction, such as executing preset database delete or update statements. As each compensation operation is executed, the business data changes introduced by successful data operations within the transaction unit will be gradually eliminated until all compensation instructions for successful data operations have been executed. At this point, the data changes within the transaction unit will be rolled back. Furthermore, during the compensation execution process, the execution status related to the transaction unit in the transaction log will be continuously updated. For example, the compensation status of a single data operation can be recorded as "compensated," and the status of the transaction unit can be updated from "failed" to "rollback." When all predetermined compensation operation instructions have been executed, the final status of the transaction unit in the transaction log will be marked as "rollback," preventing inconsistent data from remaining in the database and improving data integrity and consistency in batch business data processing scenarios.

[0062] In one embodiment, based on the execution status of each transaction unit recorded in the transaction log, the changed business data of each transaction unit is committed or rolled back to retain the changed business data in successfully executed transaction units and undo the changed business data in failed transaction units. This includes: if it is determined from the transaction log that there are failed data operations in the transaction unit, then the preset compensation operation instructions corresponding to each successful data operation of the transaction unit are read from the transaction log, and the compensation operation stack is arranged in reverse order of the data operation sequence; the compensation operation instructions are sequentially retrieved from the compensation operation stack and sent to the business processing node corresponding to the compensation operation instruction, so that the business processing node executes the compensation operation according to the type of compensation operation instruction to undo the business data changes generated by the transaction unit; if each compensation operation instruction is executed successfully, the compensation status of the data operation corresponding to the compensation operation in the transaction log is updated; if all compensation operation instructions in the compensation operation stack are executed, the execution status of the transaction unit in the transaction log is updated to the rolled-back status.

[0063] Please refer to Figure 4 , Figure 4 This demonstrates the execution flow within a single transaction unit. Specifically, when a transaction unit begins processing, its execution state is initially set to "IN_PROGRESS". Then, following a pre-determined business sequence, each atomic operation (i.e., data operation) within the transaction unit is executed sequentially. Upon success of each atomic operation, the business data is committed within the same local transaction, and the success status of this data operation is recorded in the transaction log. A compensation operation instruction, the opposite of the logic of that atomic operation, is also pre-set. If all atomic operations are successfully completed, the final state of the transaction unit is marked as "COMMITTED," and the corresponding business data changes are preserved without triggering subsequent compensation operations.

[0064] When any of the above atomic operations fails, the transaction coordinator immediately marks the transaction unit as failed and terminates the execution of the remaining atomic operations. At this point, the transaction log records the execution records of all successful atomic operations performed before the failure, along with the compensation operation instructions corresponding to each atomic operation. Since these successful atomic operations have already generated actual data changes in the business database, in order to roll back the business entity corresponding to the entire transaction unit to its unprocessed state, it is necessary to undone these data changes one by one based on the transaction log.

[0065] Specifically, in this embodiment, the preset compensation operation instructions corresponding to each successfully executed data operation of the transaction unit are read from the transaction log, and a compensation operation stack is constructed in reverse order according to the business order of these data operations in the original data operation sequence. Reverse order construction means that the compensation instruction corresponding to the last successfully executed atomic operation is placed at the top of the compensation operation stack, and the compensation instruction corresponding to the first executed atomic operation is placed at the bottom of the stack. This is because there are often dependencies between multiple atomic operations within a transaction unit. Only by first canceling subsequent operations and then canceling preceding operations can problems such as foreign key dependencies and state inconsistencies be avoided during the rollback process, thereby ensuring the correctness of the rollback path in terms of business semantics.

[0066] During the execution phase of the compensation operation instruction, driven by the compensation operation stack, compensation operation instructions are sequentially retrieved from the top of the stack and sent to the corresponding business processing node. The business processing node executes a compensation operation that is the opposite of the original data operation logic, based on the type and parameters specified in the compensation operation instruction. After each compensation operation instruction is executed, the compensation status of the corresponding data operation in the transaction log is updated according to the execution result. Records of successful compensation are marked as "COMPENSATED".

[0067] When all compensation operation instructions in the compensation operation stack have been retrieved and successfully executed in sequence, it indicates that all business data changes in this transaction unit have been completely rolled back through the compensation operation. At this point, the overall execution status of this transaction unit in the transaction log is updated to the rolled-back status, indicating that the processing of this transaction unit has ended in a compensation manner, and the business entity corresponding to this transaction unit did not undergo any persistent data modification in this batch processing, thus ensuring data consistency.

[0068] For example, in a personnel onboarding scenario, suppose a transaction unit corresponds to one new employee. The data operation sequence of this transaction unit includes: writing to the employee master table, writing to the identification information table, and writing to the education experience table. If the first two steps are completed sequentially and the education experience table is written, the transaction unit fails due to a data validation error in subsequent steps. At this time, according to the transaction log, the writing to the employee master table and the identification information table in this transaction unit are considered successful data operations, while the operations after the failed steps have not yet taken effect. Therefore, a compensation operation stack can be constructed, with the compensation instruction for deleting the education experience record at the top of the stack, followed by the deletion of the identification record, and finally the deletion of the employee master table record. These compensation instructions are sequentially sent to the education service node, the identification service node, and the employee service node. The corresponding record is deleted in the local transaction of each node, and the status of each record is marked as compensated in the transaction log. After all compensation instructions in the stack have been executed, the status of the transaction unit is updated to rolled back. At this time, no residual data will be retained in the business database for the new employee, thus ensuring data consistency. The transaction units corresponding to other employees who have been successfully hired will not be affected by the failed transaction unit and will still remain in a committed and valid state.

[0069] In one embodiment, the type of compensation operation instruction includes a preset database operation statement or a call parameter of a preset compensation service interface; the business processing node executes a compensation operation according to the type of compensation operation instruction to revoke the business data changes generated by the transaction unit, including: if the type of compensation operation instruction is a preset database operation statement, then the database operation statement is directly executed in the database of the current business processing node to reverse the modification of the business data in the database to revoke the business data changes generated by the previous transaction unit; if the type of compensation operation instruction is a call parameter pointing to a preset compensation service interface, then the compensation service corresponding to the call parameter is called to revoke the business data changes generated by the previous transaction unit through the business logic encapsulated by the compensation service.

[0070] To adapt to different system configurations and business architectures, the embodiments of this application include at least two categories of compensation operation instructions: pre-set database operation statements and call parameters pointing to preset compensation service interfaces. This allows compensation operations to directly affect the underlying data tables and also to complete more complex rollback logic through upper-layer business services.

[0071] When the compensation operation instruction is a pre-defined database operation statement, it is directly set as a reverse modification statement that can be executed at the database level, such as deleting a record with a specified primary key, restoring a field to its original value, or clearing a flag. During the rollback phase, upon receiving such a compensation operation instruction, the business processing node executes the instruction directly within its database session and commits the execution result in its local transaction. This reverses the modification of the business data in the database, thus reversing the data changes made by the previous transaction unit at that node. Because the pre-defined compensation operation instruction is generated and written to the transaction log based on the business context at the time of successful forward data operation, a one-to-one correspondence between the compensation operation and the original data operation in terms of data scope and modified content can be guaranteed, ensuring the accuracy of the rollback.

[0072] When the compensation operation instruction is a call parameter pointing to a preset compensation service interface, the compensation logic is completed through the business service layer. In this case, the compensation instruction mainly stores the interface identifier of the target compensation service and a set of call parameters describing the rollback object and rollback parameters, such as the business primary key, version number, and original state value. During the rollback phase, after parsing this type of compensation instruction, the business processing node will initiate a remote call to the corresponding compensation service according to the information carried in the call parameters, requesting the compensation service to execute the encapsulated rollback logic. For example, calling an external system interface to cancel an authorization, updating the status of multiple related tables in the business database, and sending a business revocation event notification to the message queue. Another example: if the forward data operation is calling the payroll system interface to create an account for the employee, the corresponding compensation operation instruction might be calling the account cancellation function of the payroll system interface and passing in the employee's employee number, thereby ensuring data isolation and eventual consistency between different transaction units throughout the entire batch business processing process.

[0073] In one embodiment, constructing a transaction unit for each business entity includes: obtaining a pre-defined partitioning rule for batch business processing requests; combining one or more business entities from multiple business entities into a business entity set based on the partitioning rule; and constructing a corresponding transaction unit for each business entity set.

[0074] In this embodiment, the division rules can be based on the organization department, project, business type, batch number, or a preset fixed quantity, or they can be based on meeting the same business constraint (e.g., all business objects in this group must execute successfully). The division rules can be preset during the business configuration phase or selected by the upper-layer business logic at runtime; this embodiment does not limit this.

[0075] Based on this partitioning rule, multiple business entities included in this batch business processing request are grouped. For example, in a batch onboarding scenario, a single employee can be considered as a set of business entities, or a group of employees from the same department, a group of employees corresponding to the same batch number, or a group of employees with a fixed number of employees can be considered as a set of business entities. In a batch order processing scenario, multiple orders from the same customer or multiple orders from the same payment batch can also be grouped into the same set of business entities. This satisfies the need for fine-grained transaction control at the single entity level in certain scenarios, while also allowing multiple entities to be combined into one when needed to support business constraints of group success or group failure, thus achieving flexible modeling at the business level.

[0076] After the business entities are divided and combined, this embodiment of the application constructs a corresponding transaction unit for each set of business entities. The transaction unit encapsulates all data operation sequences related to the set of business entities. In this way, when a transaction unit is judged to have been executed successfully according to the transaction log, all data changes of one or more business entities contained in the transaction unit will be retained. When a transaction unit is judged to have failed and a compensation rollback is triggered, the system will also uniformly execute the compensation logic for all successfully executed data operations in the transaction unit, and undo all data changes of one or more business entities contained in the transaction unit. This allows the system to adapt to different business scenarios while ensuring business consistency, and achieve a more reasonable balance between data consistency, performance and resource consumption.

[0077] To avoid the transaction coordinator bearing a large amount of compensation and rollback work during peak periods of batch business, which could cause the coordination thread to be blocked or the load to spike sharply, in one embodiment, the business data changed by each transaction unit is committed or rolled back according to the execution status of each transaction unit recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units. This includes: configuring background compensation tasks and setting a preset time interval execution cycle for the background compensation tasks.

[0078] The preset time interval can be flexibly set according to the business requirements for data consistency and timeliness, as well as the system's ability to withstand background load. For example, it can be several seconds, tens of seconds, or several minutes, and this embodiment does not limit this. The background compensation task is triggered periodically according to the preset time interval, and each trigger constitutes an execution cycle. At the beginning of each execution cycle, the background compensation task will retrieve transaction units whose current execution status is in a failed state based on the transaction log. To avoid multiple compensation tasks or repeated scans triggering compensation operations concurrently on the same transaction unit, this embodiment will immediately update the execution status of these transaction units from a failed state to a compensation-in-progress state and persist it back to the transaction log after selecting them. In this way, subsequent execution cycles can skip transaction units that are already in a compensation-in-progress state during scanning, avoiding repeated initiation of compensation operations.

[0079] Within each execution cycle of the background compensation task, the following operations are performed: The background compensation task reads transaction units with a failed execution status from the transaction log and updates the execution status of the transaction units to the compensation in progress status; For each transaction unit with a compensation in progress status, the task reads the preset compensation operation instruction corresponding to the successful data operation in the transaction unit from the transaction log and sends it to the business processing node corresponding to the compensation operation instruction, so that the business processing node executes the compensation operation according to the type of compensation operation instruction to undo the business data changes that have been generated corresponding to the local business operation.

[0080] After successfully marking a transaction unit as being in a compensation state, the background compensation task executes compensation operations on these transaction units one by one. To do this, the background compensation task reads the successful data operations recorded during the forward execution phase of the transaction unit from the transaction log, along with their corresponding preset compensation operation instructions, based on the transaction unit's identifier. Since these compensation operation instructions are synchronously written to the transaction log upon successful forward data operations, the business data changes generated by the transaction unit on each business processing node and the corresponding reverse operation methods can be obtained. After parsing these compensation operation instructions, the background compensation task sends each instruction to its corresponding business processing node to complete the compensation operation, thus reversing the business data changes generated by the previous local business operations.

[0081] By repeating the scanning, marking, and compensation process described above in each execution cycle of the background compensation task, this embodiment can restore the current compensation progress and continue the unfinished compensation operation simply by reading the transaction log again without blocking the business processing flow. This avoids repeated rollbacks or missed rollbacks, thereby technically achieving full-process traceability and controllable management from the failure state to the compensation completion state, and further improving the transaction robustness and data consistency maintenance capabilities in the distributed batch processing environment.

[0082] In a specific application embodiment, the batch business data processing method provided in this application is applied to a batch onboarding scenario, and its system architecture can be referred to Figure 5 As shown. Figure 5 The system architecture shown can be divided into several logical layers from top to bottom, including a presentation layer, a core processing layer, and a storage layer. The presentation layer includes a user interface and a business logic calling module. The user interface allows HR personnel to configure onboarding batches, import employee information, and initiate batch onboarding requests on the terminal. The business logic calling module receives batch onboarding instructions from the user interface, performs basic data validation on the imported data, and then transfers the batch onboarding tasks to the lower core processing layer. The core processing layer contains an onboarding transaction coordinator and multiple onboarding transaction units. The onboarding transaction coordinator receives batch onboarding tasks, constructs each employee or set of employees into an independent transaction unit according to preset division rules, and is responsible for scheduling and monitoring the execution status of all transaction units. The transaction unit, as the specific execution entity, encapsulates all data operations related to its respective employee, such as writing to the employee master table and various supplementary tables. The storage layer includes a main table for new employees, supplementary tables for employees, and a transaction log table. The main table stores basic information for each new employee, while the supplementary tables store extended information such as identification documents, educational background, and work experience. The transaction log table persistently records the execution results of each data operation step in the processing of each transaction unit, the corresponding compensation operation instructions, and the overall execution status of the transaction unit. It serves as the basis for the transaction coordinator to drive the execution of compensation operation instructions. Although this embodiment uses new employees as an example of business objects, those skilled in the art will understand that this architecture is also applicable to the batch processing of other types of business entities such as orders and accounts.

[0083] Based on the above system architecture, the batch onboarding process in this embodiment can be found in [reference needed]. Figure 6As shown, when HR personnel initiate a batch onboarding import request through the user interface, the business logic call module passes the list of personnel in that batch and related onboarding data to the onboarding transaction coordinator. The onboarding transaction coordinator first initializes the global context for this batch task and creates a transaction unit record for each onboarding personnel in the transaction log table, marking its initial status as in progress (IN_PROGRESS). Subsequently, the onboarding transaction coordinator traverses the personnel list, constructs a corresponding transaction unit for each onboarding personnel, and generates a data operation sequence for each transaction unit, including atomic business steps such as writing to the main table, writing identification information, and writing educational experience. After initialization, the onboarding transaction coordinator uses multithreading or other concurrency scheduling mechanisms to distribute each transaction unit to the corresponding business processing nodes. These business processing nodes execute the specific data write and update operations in their local transactions according to the data operation sequence, while simultaneously recording the execution status of each step and the preset compensation operation instructions in the transaction log table in real time.

[0084] As each transaction unit progresses in parallel across different nodes, the onboarding transaction coordinator continuously monitors the status changes of each transaction unit in the transaction log table. When it detects that all data operations of a transaction unit have been successfully completed, the transaction unit is marked as committed, and the corresponding onboarding personnel data remains valid in the main onboarding personnel table and the personnel supplementary table. When it detects that any step of a transaction unit fails during execution, the transaction unit is marked as failed, and a compensation operation stack is constructed in reverse order of the data operation sequence based on the successfully completed data operation entries recorded in the transaction log. Each compensation operation instruction is then executed sequentially on the corresponding business processing node to undo the business data changes already generated by the transaction unit, until the final status of the transaction unit is updated to "rollback". After all transaction units in this batch have reached the final state of committed or rollback, the onboarding transaction coordinator summarizes the execution results of all transaction units, generates a batch onboarding monitoring report, and provides feedback to the user interface so that HR personnel can see which personnel have been successfully onboarded and which personnel require manual intervention and re-import due to data issues or rule validation failures. Based on the above system architecture and batch business data processing method, this application embodiment realizes distributed transaction control for a single employee in the batch onboarding scenario. Compared with the traditional solution of encapsulating the entire batch import into a single global transaction, it not only avoids the problem of the entire batch of data being rolled back due to the failure of a single person, but also significantly improves the processing performance and fault tolerance of the distributed system.

[0085] To implement the batch business data processing method of this application embodiment, this application embodiment also provides a batch business data processing apparatus, such as... Figure 7 As shown, the device includes:

[0086] The request retrieval unit 701 is used to retrieve batch business processing requests for multiple business entities;

[0087] Construction unit 702 is used to construct a transaction unit for each of the business entities;

[0088] Encapsulation unit 703 is used to encapsulate multiple data operations corresponding to the business entity into a data operation sequence;

[0089] The execution scheduling unit 704 is used to execute the data operation sequence of each transaction unit on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and records the execution status of each transaction unit in the transaction log.

[0090] The transaction decision unit 705 is used to commit or roll back the business data changed by each transaction unit according to the execution status of each transaction unit recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units.

[0091] In one embodiment, the execution scheduling unit 704 is specifically configured to: for each transaction unit, sequentially execute each data operation in the data operation sequence on one or more business processing nodes, so that each data operation performs a local business operation on the corresponding business processing node to complete the business data change; for each data operation, write a compensation operation instruction that is the reverse of the data operation execution logic into the transaction log; and record the business data change information corresponding to each data operation and the execution status of each data operation into the transaction log, so as to record the execution status of the transaction unit in the transaction log.

[0092] In one embodiment, the transaction decision unit 705 is specifically configured to: for each transaction unit, if it is determined from the transaction log that all data operations of the transaction unit have been successfully executed, send a confirmation instruction to the business processing node corresponding to each data operation, so that the changed business data in each business processing node is in a valid state; if it is determined from the transaction log that there are data operations that have failed to execute in the transaction unit, determine the preset compensation operation instruction corresponding to each successful data operation and the execution order of each compensation operation instruction based on the successful data operations of the transaction unit recorded in the transaction log, and update the execution status of the transaction unit in the transaction log after each compensation operation instruction has been executed.

[0093] In one embodiment, the transaction decision unit 705 is specifically configured to: if it is determined from the transaction log that there are failed data operations in the transaction unit, then read the preset compensation operation instructions corresponding to each successful data operation of the transaction unit from the transaction log, and arrange the compensation operation stack in reverse order of the data operation sequence; sequentially retrieve the compensation operation instructions from the compensation operation stack and send them to the business processing node corresponding to the compensation operation instructions, so that the business processing node executes the compensation operation according to the type of the compensation operation instruction to revoke the business data changes generated by the transaction unit; if each compensation operation instruction is executed successfully, then update the compensation status of the data operation corresponding to the compensation operation in the transaction log; if all compensation operation instructions in the compensation operation stack are executed, then update the execution status of the transaction unit in the transaction log to the rolled-back status.

[0094] In one embodiment, the type of the compensation operation instruction includes a preset database operation statement or a call parameter of a preset compensation service interface; the execution scheduling unit 704 is specifically used for: if the type of the compensation operation instruction is a preset database operation statement, then directly executing the database operation statement in the database of the current business processing node to reverse modify the business data in the database, so as to undo the business data changes generated by the previous transaction unit; if the type of the compensation operation instruction is a call parameter pointing to a preset compensation service interface, then calling the compensation service corresponding to the call parameter, so as to undo the business data changes generated by the previous transaction unit through the business logic encapsulated by the compensation service.

[0095] In one embodiment, the construction unit 702 is specifically used for: obtaining a preset partitioning rule for the batch business processing request; combining one or more business entities among the plurality of business entities into a business entity set based on the partitioning rule; and constructing a corresponding transaction unit for each of the business entity sets.

[0096] In one embodiment, the transaction decision unit 705 is specifically configured to: configure a background compensation task and set a preset time interval execution cycle for the background compensation task; within each execution cycle of the background compensation task, perform the following operations: the background compensation task reads transaction units with a failed execution status from the transaction log and updates the execution status of the transaction units to a compensation-in-progress status; for each transaction unit with a compensation-in-progress status, reads a preset compensation operation instruction corresponding to the successfully performed data operation in the transaction unit from the transaction log and sends it to the business processing node corresponding to the compensation operation instruction, so that the business processing node performs a compensation operation according to the type of the compensation operation instruction to revoke the business data changes generated corresponding to the local business operation.

[0097] It should be noted that the batch business data processing device provided in the above embodiments is only illustrated by the division of the above program modules. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device can be divided into different program modules to complete all or part of the processing described above. In addition, the batch business data processing device and the batch business data processing method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0098] Based on the hardware implementation of the above program modules, and in order to implement the batch business data processing method provided in this application embodiment, this application embodiment also provides a computer device, such as... Figure 8 As shown, the computer device 800 includes:

[0099] Central processing unit 801, memory 802, and input / output interface 803;

[0100] The memory 802 is a short-term storage memory or a persistent storage memory;

[0101] The central processing unit 801 is configured to communicate with the memory 802 and execute the instructions in the memory 802 to perform any of the above-described batch business data processing methods.

[0102] Of course, in practical applications, the various components in the computer device 800 are coupled together through a bus system 804. It is understood that the bus system 804 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus System 804.

[0103] The memory 802 in this embodiment is used to store various types of data to support the operation of the computer device 800. Examples of such data include any computer program used to operate on the computer device 800.

[0104] It is understood that when the processor in the computer device described above executes the computer program, it can also realize the functions of each unit in the corresponding device embodiments described above, which will not be repeated here. Exemplarily, the computer program can be divided into one or more modules / units, one or more modules / units are stored in memory and executed by the processor to complete the various embodiments of this application. One or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device. For example, the computer program can be divided into units in the aforementioned computer device, and each unit can implement the specific functions described in the corresponding computer device above.

[0105] Computer equipment can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. Computer equipment may include, but is not limited to, processors and memory. Those skilled in the art will understand that processors and memory are merely examples of computer equipment and do not constitute a limitation on the computer equipment. It may include more or fewer components, or combinations of certain components, or different components. For example, computer equipment may also include input / output devices, network access devices, buses, etc.

[0106] A processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of a computer device, connecting all parts of the computer device through various interfaces and lines.

[0107] Memory can be used to store computer programs and / or modules. The processor performs various functions of the computer device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can primarily include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on terminal usage, etc. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0108] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, performs any of the batch business data processing methods described above.

[0109] This application also provides a computer program product that stores a computer program / instruction thereon. When the computer program / instruction is executed by a processor, it is used to implement the batch business data processing method described in the first aspect or any specific implementation of the first aspect of this application.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0114] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for batch business data processing, characterized in that, include: Obtain batch business processing requests for multiple business entities; For each of the aforementioned business entities, a transaction unit is constructed; Encapsulate multiple data operations corresponding to the business entity into a data operation sequence; The data operation sequence of each transaction unit is executed on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and the execution status of each transaction unit is recorded in the transaction log. Based on the execution status of each transaction unit recorded in the transaction log, the business data changed by each transaction unit is committed or rolled back, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units.

2. The method according to claim 1, characterized in that, The step of executing the data operation sequence of each transaction unit on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and recording the execution status of each transaction unit in the transaction log, includes: For each transaction unit, each data operation in the data operation sequence is executed sequentially on one or more business processing nodes, so that each data operation performs a local business operation on the corresponding business processing node to complete the business data change. For each of the data operations, a compensation operation instruction that is the reverse of the execution logic of the data operation is written into the transaction log; The business data change information corresponding to each data operation and the execution status of each data operation are recorded in the transaction log, so as to record the execution status of the transaction unit in the transaction log.

3. The method according to claim 1, characterized in that, The step of committing or rolling back the changed business data of each transaction unit according to the execution status recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units, includes: For each transaction unit, if it is determined from the transaction log that all data operations of the transaction unit have been successfully executed, then a confirmation instruction is sent to the business processing node corresponding to each data operation, so that the changed business data in each business processing node is in a valid state. If the transaction log determines that there are failed data operations in the transaction unit, then based on the successful data operations of the transaction unit recorded in the transaction log, the preset compensation operation instructions corresponding to each successful data operation and the execution order of each compensation operation instruction are determined, and the execution status of the transaction unit in the transaction log is updated after each compensation operation instruction is executed.

4. The method according to claim 1, characterized in that, The step of committing or rolling back the changed business data of each transaction unit according to the execution status recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units, includes: If it is determined from the transaction log that there are failed data operations in the transaction unit, then the preset compensation operation instructions corresponding to each successful data operation in the transaction unit are read from the transaction log, and the compensation operation stack is arranged in reverse order of the data operation sequence. The compensation operation instructions are sequentially retrieved from the compensation operation stack and sent to the business processing node corresponding to the compensation operation instruction, so that the business processing node performs the compensation operation according to the type of the compensation operation instruction to revoke the business data changes generated by the transaction unit. If each compensation operation instruction is executed successfully, the compensation status of the data operation corresponding to the compensation operation in the transaction log is updated; If all compensation operation instructions in the compensation operation stack have been executed, the execution status of the transaction unit in the transaction log will be updated to the rolled-back status.

5. The method according to claim 4, characterized in that, The types of compensation operation instructions include preset database operation statements or preset compensation service interface call parameters; The business processing node executes a compensation operation according to the type of the compensation operation instruction to revoke the business data changes already generated by the transaction unit, including: If the type of the compensation operation instruction is a preset database operation statement, then the database operation statement is executed directly in the database of the current business processing node to reverse the modification of the business data in the database, so as to undo the business data changes generated by the previous transaction unit. If the type of the compensation operation instruction is a call parameter pointing to a preset compensation service interface, then the compensation service corresponding to the call parameter is invoked to revoke the business data changes generated by the previous transaction unit through the business logic encapsulated in the compensation service.

6. The method according to claim 1, characterized in that, The construction of a transaction unit for each of the business entities includes: Obtain the preset division rules for the batch business processing requests; Based on the aforementioned partitioning rules, one or more business entities among the plurality of business entities are combined into a business entity set; Construct a corresponding transaction unit for each of the aforementioned business entity sets.

7. The method according to claim 1, characterized in that, The step of committing or rolling back the changed business data of each transaction unit according to the execution status recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units, includes: Configure background compensation tasks and set a preset time interval execution cycle for the background compensation tasks; Within each execution cycle of the background compensation task, the following operations are performed: The background compensation task reads transaction units whose execution status is failed from the transaction log and updates the execution status of the transaction units to the compensation status. For each transaction unit whose execution status is "compensation in progress", the preset compensation operation instruction corresponding to the successful data operation in the transaction unit is read from the transaction log and sent to the business processing node corresponding to the compensation operation instruction, so that the business processing node performs the compensation operation according to the type of the compensation operation instruction to undo the business data changes that have been generated corresponding to the local business operation.

8. A batch business data processing device, characterized in that, include: The request retrieval unit is used to retrieve batch business processing requests for multiple business entities. A construction unit is used to construct a transaction unit for each of the aforementioned business entities; An encapsulation unit is used to encapsulate multiple data operations corresponding to the business entity into a data operation sequence. An execution scheduling unit is used to execute the data operation sequence of each transaction unit on one or more business processing nodes, so that each data operation performs local business operations on the corresponding business processing node to complete the business data change, and records the execution status of each transaction unit in the transaction log. The transaction decision unit is used to commit or roll back the business data changed by each transaction unit according to the execution status of each transaction unit recorded in the transaction log, so as to retain the changed business data in the successfully executed transaction units and undo the changed business data in the failed transaction units.

9. A computer device, characterized in that, include: Central processing unit, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it is used to implement the method as described in any one of claims 1 to 7.

11. A computer program product having a computer program / instructions stored thereon, characterized in that, When executed by a processor, the computer program / instructions are used to implement the method as described in any one of claims 1 to 7.

Images