Distributed transaction processing method and device based on local table, equipment and medium
By storing distributed transaction interface call requests locally in a local table of the local database, the consistency problem of distributed transactions is solved, the eventual consistency management of distributed transactions is realized, and the interface calls across business systems are standardized, thereby improving system stability and transaction processing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-06
- Publication Date
- 2026-04-07
AI Technical Summary
In existing technologies, the problem of distributed transaction consistency is difficult to solve, and asynchronous queue solutions lack mature front-end visual interfaces and flexible strategy configuration mechanisms, resulting in low operational efficiency and transaction processing lag.
By storing distributed transaction API call requests locally in a local table of a local database, and using the pre-configured local table to execute requests, eventual consistency of distributed transactions is achieved, and standardized management of API call configuration information is provided.
It achieves eventual consistency management of distributed transactions without relying on message queues, simplifies parameter passing and execution logic of interface calls, and improves system stability and transaction processing efficiency.
Smart Images
Figure CN121807457A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing, and more specifically, to a distributed transaction processing method, apparatus, device, and medium based on local tables. Background Technology
[0002] As business scale continues to expand, system data volume and code complexity grow exponentially. Monolithic architectures can no longer support the demands of high concurrency and high availability, making distributed systems the mainstream technology choice. By splitting services, distributed systems can effectively reduce the operational pressure on monolithic services and improve overall performance. However, this also breaks the transaction loop inherent in monolithic architectures. The integrity guaranteed by traditional database-local transactions fails in cross-system interaction scenarios, and the distributed transaction consistency problem becomes a core pain point restricting system stability. To address this issue, various distributed transaction processing solutions have emerged in the industry, but all have significant limitations, necessitating a lightweight, reliable, and easy-to-maintain solution.
[0003] In existing technologies, the main solution for achieving distributed transaction consistency is the asynchronous queue solution. While message queues enable asynchronous sending and transfer of messages across systems, reducing the direct impact on business systems, a mature supporting framework is currently lacking. On one hand, message management and failure re-push operations rely entirely on operations personnel searching backend logs, lacking a dedicated front-end visual interface. This prevents operations personnel from quickly filtering target messages and efficiently executing re-push operations, resulting in low operational efficiency. On the other hand, the lack of a flexible strategy configuration mechanism means all failed messages require manual intervention. Messages with idempotency and automatic retry capabilities cannot be automatically re-pushed, leading to a waste of human resources. Furthermore, detailed interface information must be obtained through technical documentation or code queries, making it difficult to quickly and accurately locate interface attributes. Additionally, the lack of a robust alarm mechanism for abnormal pushes prevents operations personnel from promptly detecting message failure status, further exacerbating the lag and uncertainty in transaction processing. Summary of the Invention
[0004] The purpose of this invention is to address the shortcomings of the prior art by providing a distributed transaction processing method, apparatus, device, and medium based on local tables. This allows for the local storage of distributed transaction interface call requests and the execution of requests based on pre-configured local tables. This approach not only ensures eventual consistency of distributed transactions by leveraging the transaction capabilities of local databases but also achieves standardized management of cross-business system interface calls, enabling transaction flow to be completed without relying on message queues.
[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a distributed transaction processing method based on local tables, applied to an interface management system, the method comprising: Obtain the execution trigger operation of the first transaction triggered by the first business system; Based on the execution trigger operation of the first transaction, an interface call request for the second business system is generated, and the interface call request includes: the data to be executed for the second transaction corresponding to the second business system; The interface call request is stored in a local database, which also stores a local table containing interface call configuration information for multiple business systems. According to the interface call configuration information of the second business system, the interface call request is executed, so that the second business system performs the corresponding transaction operation based on the data to be executed in the second transaction.
[0006] In an optional implementation, executing the interface call request according to the interface call configuration information of the second business system includes: Based on the interface call configuration information of the second business system, determine whether the execution triggering condition of the second transaction is met at the current moment; If the execution triggering condition of the second transaction is met, the interface call request will be pushed to the second business system.
[0007] In an optional implementation, the interface call configuration information includes: the scheduled task execution information of the second transaction; determining whether the execution triggering condition of the second transaction is met at the current time based on the interface call configuration information of the second business system includes: Based on the scheduled task execution information of the second transaction, determine whether the execution triggering condition of the second transaction is met at the current moment.
[0008] In an optional implementation, the method further includes: If the interface call request fails, the interface category of the second business system is obtained from the interface call configuration information; If the interface category is the first interface category, then the request push strategy of the second business system is obtained from the interface call configuration information; According to the request push strategy, the interface call request is pushed to the second business system.
[0009] In an optional implementation, the method further includes: If the interface category is the second interface category, a processing message is sent to the operation and maintenance personnel through the interface management system interface.
[0010] In an optional implementation, the method further includes: Receive interface configuration modification operations triggered by the operation and maintenance personnel through the interface management system interface; Modify the interface call configuration information in the local table according to the interface configuration modification operation.
[0011] In an optional implementation, after storing the interface call request in a local database, the method further includes: Return a success message for the execution of the second transaction to the first business system.
[0012] Secondly, embodiments of this application also provide a distributed transaction processing device based on a local table, applied to an interface management system, the device comprising: The acquisition module is used to acquire the execution trigger operation of the first transaction triggered by the first business system; The generation module is used to generate an interface call request for the second business system based on the execution trigger operation of the first transaction. The interface call request includes: the data to be executed for the second transaction corresponding to the second business system. The storage module is used to store the interface call requests in a local database. The local database also stores a local table, which contains interface call configuration information for multiple business systems. The execution module is used to execute the interface call request according to the interface call configuration information of the second business system, so that the second business system performs the corresponding transaction operation according to the data to be executed in the second transaction.
[0013] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the distributed transaction processing method based on local tables as described in any of the first aspects.
[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the distributed transaction processing method based on a local table as described in any of the first aspects.
[0015] The beneficial effects of this application are: This application provides a distributed transaction processing method, apparatus, device, and medium based on a local table. The method includes: obtaining an execution trigger operation of a first transaction triggered by a first business system; generating an interface call request for a second business system based on the execution trigger operation of the first transaction, the interface call request including: data to be executed for the second transaction corresponding to the second business system; storing the interface call request in a local database, the local database also storing: a local table, the local table pre-configured with interface call configuration information for multiple business systems; and executing the interface call request according to the interface call configuration information of the second business system, so that the second business system performs the corresponding transaction operation based on the data to be executed for the second transaction. This method, by storing the interface call request of the distributed transaction locally and executing the request based on the pre-configured local table, not only ensures the eventual consistency of the distributed transaction by leveraging the transaction capabilities of the local database, but also achieves standardized management of cross-business system interface calls, completing transaction flow without relying on message queues. It also simplifies the parameter passing and execution logic of interface calls, improving the overall system stability and transaction processing efficiency. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 One of the flowcharts for a distributed transaction processing method based on a local table provided in this application embodiment; Figure 2 A second flowchart illustrating a distributed transaction processing method based on a local table, provided as an embodiment of this application; Figure 3 The third flowchart illustrates a distributed transaction processing method based on a local table, as provided in this application embodiment. Figure 4 The fourth flowchart illustrates a distributed transaction processing method based on a local table, as provided in this application embodiment. Figure 5 A schematic diagram of the functional modules of a distributed transaction processing device based on a local table, provided for an embodiment of this application; Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.
[0019] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0020] In the description of this application, it should be noted that if the terms "upper", "lower", etc. appear to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship that the product of this application is usually placed in, it is only for the convenience of describing this application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.
[0021] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0022] It should be noted that, where there is no conflict, the features in the embodiments of this application can be combined with each other.
[0023] The following detailed explanation, with reference to the accompanying drawings and specific examples, illustrates the distributed transaction processing method based on local tables provided in this application. This method is applied to an interface management system. Figure 1 This application provides a flowchart illustrating one of the distributed transaction processing methods based on local tables; for example... Figure 1 As shown, the method includes: S101. Obtain the execution trigger operation of the first transaction triggered by the first business system.
[0024] In this embodiment, the first business system can be an e-commerce order management system. A user submits a physical goods order through the business software. After completing payment, an order status update transaction is triggered, thus triggering the first transaction. The order submission interface of the first business system receives a payment callback notification, which is the execution trigger operation of the first transaction. This operation includes parameters such as order number, user ID, deducted amount, and order status.
[0025] S102. Based on the execution trigger operation of the first transaction, generate an interface call request for the second business system.
[0026] The interface call request includes: the data to be executed for the second transaction corresponding to the second business system.
[0027] Specifically, the second business system can be a user account system, and the second transaction can be a transaction that deducts the user account balance. The first business system triggers an operation based on the order submission, and generates an interface call request for the second business system through the request construction module of the interface management system.
[0028] The data to be executed in the second transaction may include: order number, user ID, deduction amount, etc.
[0029] S103. Store the interface call request in the local database.
[0030] The local database also stores: local tables, which contain pre-configured interface call configuration information for multiple business systems.
[0031] S104. Based on the interface call configuration information of the second business system, execute the interface call request so that the second business system can execute the corresponding transaction operation based on the data to be executed in the second transaction.
[0032] Specifically, the storage module of the interface management system writes interface call requests to the local database and simultaneously performs join queries on the local tables. These local tables contain pre-configured interface call configuration information for multiple business systems, including the interface call configuration information for a second business system.
[0033] Then, the interface management system will execute the interface call request according to the interface call configuration information of the second business system, and push the pending data of the second transaction corresponding to the second business system to the second business system so that the second business system can execute the corresponding transaction operation according to the pending data of the second transaction. For example, after receiving the request, the second business system will verify the user's account balance, deduct the amount and update the balance, and return the response result. The interface management system will update the status of the request in the local message table to successful execution and record the execution log.
[0034] In summary, this application provides a distributed transaction processing method based on a local table. The method includes: obtaining the execution trigger operation of a first transaction triggered by a first business system; generating an interface call request for a second business system based on the execution trigger operation of the first transaction, the interface call request including: data to be executed for the second transaction corresponding to the second business system; storing the interface call request in a local database, the local database also storing: a local table, the local table pre-configured with interface call configuration information for multiple business systems; and executing the interface call request according to the interface call configuration information of the second business system, so that the second business system executes the corresponding transaction operation based on the data to be executed for the second transaction. This method, by storing the interface call request of the distributed transaction locally and executing the request based on the pre-configured local table, not only ensures the eventual consistency of the distributed transaction by leveraging the transaction capabilities of the local database, but also achieves standardized management of cross-business system interface calls, completing transaction flow without relying on message queues. It also simplifies the parameter passing and execution logic of interface calls, improving the overall system stability and transaction processing efficiency.
[0035] This application also provides another possible implementation of a distributed transaction processing method based on local tables. Figure 2 A second flowchart illustrating a distributed transaction processing method based on a local table, provided as an embodiment of this application; Figure 2 As shown, based on the interface call configuration information of the second business system, the interface call request is executed, including: S201. Based on the interface call configuration information of the second business system, determine whether the execution triggering conditions of the second transaction are met at the current moment.
[0036] S202. If the execution triggering condition of the second transaction is met, the interface call request will be pushed to the second business system.
[0037] In this embodiment, the interface management system reads the interface call configuration information of the second business system and determines whether the execution triggering conditions of the second transaction are met at the current moment.
[0038] Optionally, the interface call configuration information includes: the scheduled task execution information for the second transaction. Based on the scheduled task execution information for the second transaction, it is determined whether the execution triggering conditions for the second transaction are met at the current time.
[0039] For example, if the scheduled task execution information in the interface call configuration information of the second business system is: execute once every 3 minutes from 9:00 to 23:00 daily; execute once every 30 minutes from 23:00 to 9:00 the next day. If the current time is 22:35, which falls within the 9:00-23:00 time period, and 3 minutes have passed since the last execution, then the current time meets the execution trigger condition. If the current time is 00:10, which falls within the 23:00-9:00 the next day time period, it is necessary to check if 30 minutes have passed since the last execution; if not, execution will not be triggered.
[0040] If the triggering conditions are met at the current moment, an interface call request will be sent to the interface of the second business system.
[0041] The method provided in this application embodiment dynamically determines the execution timing based on the scheduled task execution rules in the interface call configuration information. This can flexibly adapt to the time requirements of different business scenarios, avoid invalid requests occupying system resources, and ensure that interface calls are executed in an orderly manner according to preset strategies. This reduces the randomness and conflict risk of cross-system interactions and improves the controllability and resource utilization of distributed transaction execution.
[0042] This application also provides another possible implementation of a distributed transaction processing method based on local tables. Figure 3 This is the third flowchart illustrating a distributed transaction processing method based on a local table, as provided in this application embodiment; Figure 3 As shown, the method also includes: S301. If the interface call request fails, obtain the interface category of the second business system from the interface call configuration information.
[0043] S302. If the interface category is the first interface category, then obtain the request push strategy of the second business system from the interface call configuration information.
[0044] S303. According to the request push strategy, push the interface call request to the second business system.
[0045] In this embodiment, the reason for the failure of the interface call request can be: the second business system fails to execute the interface call request due to temporary server overload, network problems, or other reasons. In this case, the interface call request returns a failure response code, indicating that the execution has failed.
[0046] At this point, the interface management system queries the interface category of the second business system from the local table. If the obtained interface category is the first interface category, the request push strategy for that interface is extracted. The first interface category can be an interface category that meets the automatic push conditions, such as an idempotent category. In this case, the request push strategy for that interface is: a maximum of 3 retries, with an interval of 5 minutes between each retrieval, and an email alert is triggered if the retrieval fails.
[0047] Following the request push strategy, the interface management system triggers a second and third retweet based on the re-push interval after the first failure. If the second business system server or network has recovered by the time of the third retweet, a success response code is returned. At this point, the interface management system updates the request status to successful and records the retweet log.
[0048] Optionally, if the interface category is the second interface category, a processing message is sent to the operation and maintenance personnel through the interface management system interface.
[0049] The second interface category is the interface category that does not meet the automatic push conditions. If the execution fails, the interface management system will not trigger automatic re-push. Instead, it will directly push a processing message to the interface management system interface via instant message or email. The message content can include: request ID, failure reason, associated order number, and interface details link, so that operation and maintenance personnel can quickly locate the problem.
[0050] In the method provided in this application embodiment, different failure handling strategies are adapted by distinguishing interface categories. If the interface category is the first interface category, automatic re-push is performed without manual intervention. If the interface category is the second interface category, the operation and maintenance personnel are alerted in a timely manner. This reduces the labor cost of repetitive manual operations and avoids data anomalies caused by repeated calls to interfaces of the second interface category. At the same time, through clear re-push strategies and alarm mechanisms, the processing cycle of failed transactions is shortened, and the timeliness and accuracy of system fault response are improved.
[0051] This application also provides another possible implementation of a distributed transaction processing method based on local tables. Figure 4 A flowchart illustrating a distributed transaction processing method based on a local table, as provided in this application embodiment, is shown in Figure 4. Figure 4 As shown, the method also includes: S401: Receive interface configuration modification operations triggered by operation and maintenance personnel through the interface management system interface.
[0052] S402. Modify the interface call configuration information in the local table according to the interface configuration modification operation.
[0053] In this embodiment, the operation and maintenance personnel can access the interface configuration management module through the front-end management web interface of the interface management system. If they find that the interface call request of the second business system failed to execute, and the re-push strategy needs to be adjusted due to business requirements, they can click the "Modify Configuration" button to change the maximum number of re-pushes from 3 to 5, and the interval between each push from 5 minutes to 3 minutes, and then submit the modification operation.
[0054] After receiving the modification request, the API management system updates the re-push count and re-push interval fields for the API call requests from the second business system in its local table. Once the modification is complete, the front-end interface refreshes and displays the latest configuration in real time, and the new configuration takes effect immediately on subsequent API call requests without requiring a restart of the API management system.
[0055] The method provided in this application embodiment allows operation and maintenance personnel to modify the configuration information of local tables in real time through the front-end interface, and complete the policy update without stopping the system. This solves the drawback of traditional configuration modification requiring system restart. At the same time, it realizes the visualization and centralized management of interface configuration, reduces the technical threshold of configuration maintenance, and enables interface call policies to quickly adapt to business changes, thereby improving the flexibility and scalability of the system.
[0056] This application also provides another possible implementation of a distributed transaction processing method based on local tables. After storing the interface call request in a local database, the method further includes: Return a success message for the execution of the second transaction to the first business system.
[0057] In this embodiment, after the interface management system writes the interface call request to the local database and confirms successful storage, it immediately returns a feedback message indicating that the second transaction was successfully executed to the first business system. Upon receiving the feedback, the first business system immediately updates the order status and displays it to the user.
[0058] Once the API call request is stored locally, the processing result is immediately returned to the first business system without waiting for the second business system to actually complete the execution. This significantly shortens the response time of the front-end business and improves the user experience. At the same time, the local storage and asynchronous execution mode avoids the blockage of core business processes by cross-system interaction delays, ensuring the smoothness of core business.
[0059] The following will continue to explain the distributed transaction processing device and electronic device based on local tables provided in any of the above embodiments of this application. The specific implementation process and the resulting technical effects are the same as those in the corresponding method embodiments. For the sake of brevity, the parts not mentioned in this embodiment can be referred to the corresponding content in the method embodiments.
[0060] Figure 5 This is a schematic diagram of the functional modules of a distributed transaction processing device based on a local table, provided as an embodiment of this application. Figure 5 As shown, the distributed transaction processing device 100 based on local tables, applied to an interface management system, includes: The acquisition module 110 is used to acquire the execution trigger operation of the first transaction triggered by the first business system; The generation module 120 is used to generate an interface call request for the second business system based on the execution trigger operation of the first transaction. The interface call request includes: the data to be executed for the second transaction corresponding to the second business system. Storage module 130 is used to store interface call requests in a local database. The local database also stores a local table, which contains pre-configured interface call configuration information for multiple business systems. The execution module 140 is used to execute the interface call request according to the interface call configuration information of the second business system, so that the second business system can execute the corresponding transaction operation according to the data to be executed in the second transaction.
[0061] Optionally, the execution module 140 is further configured to determine whether the execution triggering condition of the second transaction is met at the current moment based on the interface call configuration information of the second business system; if the execution triggering condition of the second transaction is met, the interface call request is pushed to the second business system.
[0062] Optionally, the interface call configuration information includes: the scheduled task execution information of the second transaction; the execution module 140 is also used to determine whether the execution triggering condition of the second transaction is met at the current time based on the scheduled task execution information of the second transaction.
[0063] Optionally, the device further includes: The acquisition module 110 is used to obtain the interface category of the second business system from the interface call configuration information if the interface call request fails; if the interface category is the first interface category, it obtains the request push strategy of the second business system from the interface call configuration information. The push module is used to push interface call requests to the second business system according to the request push strategy.
[0064] Optionally, the device further includes: The sending module is used to send processing messages to operations and maintenance personnel through the interface management system interface if the interface category is the second interface category.
[0065] Optionally, the apparatus method further includes: The receiving module is used to receive interface configuration modification operations triggered by operation and maintenance personnel through the interface management system interface; The modification module is used to modify the interface call configuration information in the local table based on the interface configuration modification operation.
[0066] Optionally, the device further includes: The return module is used to return a success message for the execution of the second transaction to the first business system.
[0067] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.
[0068] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).
[0069] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. This electronic device can be used for distributed transaction processing based on local tables. Figure 6 As shown, the electronic device includes: a processor 210, a storage medium 220, and a bus 230.
[0070] Storage medium 220 stores machine-readable instructions executable by processor 210. When the electronic device is running, processor 210 communicates with storage medium 220 via bus 230, and processor 210 executes the machine-readable instructions to perform the steps of the above method embodiment. The specific implementation and technical effects are similar and will not be described again here.
[0071] Optionally, this application also provides a storage medium 220, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of the above-described method embodiments. The specific implementation and technical effects are similar, and will not be repeated here.
[0072] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus 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 through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0073] 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.
[0074] Furthermore, the functional units in the various embodiments of the present invention 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 in the form of hardware plus software functional units.
[0075] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of the present invention. 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.
[0076] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A distributed transaction processing method based on local tables, characterized in that, Applied to an interface management system, the method includes: Obtain the execution trigger operation of the first transaction triggered by the first business system; Based on the execution trigger operation of the first transaction, an interface call request for the second business system is generated, and the interface call request includes: the data to be executed for the second transaction corresponding to the second business system; The interface call request is stored in a local database, which also stores a local table containing interface call configuration information for multiple business systems. According to the interface call configuration information of the second business system, the interface call request is executed, so that the second business system performs the corresponding transaction operation based on the data to be executed in the second transaction.
2. The method according to claim 1, characterized in that, The step of executing the interface call request according to the interface call configuration information of the second business system includes: Based on the interface call configuration information of the second business system, determine whether the execution triggering condition of the second transaction is met at the current moment; If the execution triggering condition of the second transaction is met, the interface call request will be pushed to the second business system.
3. The method according to claim 2, characterized in that, The interface call configuration information includes: the scheduled task execution information of the second transaction; the step of determining whether the execution triggering condition of the second transaction is met at the current time based on the interface call configuration information of the second business system includes: Based on the scheduled task execution information of the second transaction, determine whether the execution triggering condition of the second transaction is met at the current moment.
4. The method according to claim 1, characterized in that, The method further includes: If the interface call request fails, the interface category of the second business system is obtained from the interface call configuration information; If the interface category is the first interface category, then the request push strategy of the second business system is obtained from the interface call configuration information; According to the request push strategy, the interface call request is pushed to the second business system.
5. The method according to claim 4, characterized in that, The method further includes: If the interface category is the second interface category, a processing message is sent to the operation and maintenance personnel through the interface management system interface.
6. The method according to claim 5, characterized in that, The method further includes: Receive interface configuration modification operations triggered by the operation and maintenance personnel through the interface management system interface; Modify the interface call configuration information in the local table according to the interface configuration modification operation.
7. The method according to claim 1, characterized in that, After storing the interface call request in the local database, the method further includes: Return a success message for the execution of the second transaction to the first business system.
8. A distributed transaction processing device based on local tables, characterized in that, The device, used in an interface management system, includes: The acquisition module is used to acquire the execution trigger operation of the first transaction triggered by the first business system; The generation module is used to generate an interface call request for the second business system based on the execution trigger operation of the first transaction. The interface call request includes: the data to be executed for the second transaction corresponding to the second business system. The storage module is used to store the interface call requests in a local database. The local database also stores a local table, which contains interface call configuration information for multiple business systems. The execution module is used to execute the interface call request according to the interface call configuration information of the second business system, so that the second business system performs the corresponding transaction operation according to the data to be executed in the second transaction.
9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus. The storage medium stores program instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the distributed transaction processing method based on a local table as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the steps of the distributed transaction processing method based on a local table as described in any one of claims 1 to 7.