A multi-resource coordination oriented distributed reservation system and method

Abstract

The application discloses a kind of distributed reservation systems and methods for multi-resource cooperation, comprising: transaction manager, at least two resource managers, lock manager, transaction log module and workflow controller;Transaction manager coordinates each resource manager through two-phase commit 2PC protocol, realizes the atomicity execution of cross-node shadow and summary table update;Lock manager adopts read-write lock separation mechanism to resolve concurrent conflict, and handles deadlock problem through timeout detection and active unlocking strategy;Transaction log module is based on prewrite log mechanism Complete record shadow and summary table linkage operation details, provide reliable support for fault recovery and transaction rollback;Workflow controller encapsulates distributed call details, realizes service survival real-time detection and automatic reconnection function.The application has high expansibility, strong consistency, high concurrent adaptation capability and perfect exception fault-tolerant mechanism, and can be widely applied to travel service scene of multi-node deployment.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a distributed reservation system and method for multi-resource collaboration. Background Technology

[0002] With the booming development of the tourism industry, users' demands for travel booking services are becoming increasingly diversified, creating an urgent need for integrated booking of various travel resources such as flights, hotels, and car rentals. Traditional travel booking systems often adopt a monolithic architecture design, integrating all resource management and transaction processing logic into a single node, which has the following significant technical drawbacks:

[0003] 1. Lack of scalability: Under a monolithic architecture, adding new types of travel resources, such as attraction tickets and tour packages, requires modifying the core business code and redeploying the entire system, resulting in high development and maintenance costs. At the same time, the processing capacity of a single node has an upper limit, making it difficult to cope with the high concurrency access demands during peak tourist seasons, which can easily lead to service response delays or even system crashes.

[0004] 2. Difficulty in guaranteeing transaction consistency: When users make joint reservations for multiple resources, such as flights and hotels, a monolithic system can ensure the atomicity of operations through local transactions. However, in a distributed deployment scenario, cross-node resource operations lack an effective transaction coordination mechanism, which can easily lead to data inconsistency issues such as "partial reservations succeeding and partial reservations failing," thereby causing user disputes and damage to corporate reputation.

[0005] 3. Insufficient concurrency control capabilities: When multiple users simultaneously reserve the same scarce resource, the simple locking mechanism of a monolithic system is prone to frequent lock conflicts and low concurrency processing efficiency; moreover, the lack of a sound deadlock detection and handling mechanism may lead to system blockage and seriously affect service availability.

[0006] 4. Weak fault tolerance: In a monolithic system, node failure will directly lead to the interruption of the entire service; even with distributed deployment, the existing system lacks a sound fault recovery and automatic reconnection mechanism, making it difficult to quickly restore the service after a node failure, and posing a high risk of data loss.

[0007] 5. Inadequate exception handling system: The existing system handles resource operation exceptions, transaction exceptions, network exceptions and other scenarios in a relatively simple way, often by directly throwing exceptions and terminating the process. It has not formed a closed-loop exception fault tolerance system, resulting in poor system stability and easy service interruption.

[0008] Therefore, developing a distributed travel booking system with high scalability, strong transaction consistency, efficient concurrency control capabilities, and a sound fault tolerance mechanism has become a core technical problem that urgently needs to be solved in this field. Summary of the Invention

[0009] Purpose of the invention: This invention provides a distributed reservation system and method for multi-resource collaboration, which has high scalability, strong consistency, high concurrency adaptability and a sound fault tolerance mechanism, and can be widely applied to travel service scenarios with multi-node deployment.

[0010] Technical Solution: The distributed reservation system for multi-resource collaboration described in this invention includes: a transaction manager, at least two resource managers, a lock manager, a transaction log module, and a workflow controller. The transaction manager coordinates the resource managers through a two-phase commit (2PC) protocol to achieve atomic execution of cross-node shadow and summary table updates. The lock manager uses a read-write lock separation mechanism to resolve concurrency conflicts and handles deadlock issues through timeout detection and proactive unlocking strategies. The transaction log module fully records the details of shadow and summary table linkage operations based on a write-ahead log mechanism, providing reliable support for fault recovery and transaction rollback. The workflow controller encapsulates distributed call details to achieve real-time service liveness detection and automatic reconnection functions.

[0011] Furthermore, the transaction manager includes a global transaction (xid) generation unit, a transaction state management unit, a 2PC coordination unit, and an RM registration unit. The xid generation unit uses the AtomicInteger atomic class to generate globally unique transactions, fundamentally ensuring the uniqueness and allocation safety of transactions in multi-threaded concurrent scenarios, and avoiding confusion in parent-child table update transactions due to duplication. The transaction state management unit constructs a thread-safe transaction state mapping table through ConcurrentHashMap to store the correspondence between transactions and transaction states. The transaction states include ACTIVE, PREPARING, PREPARRED, COMMITTED, and ABORTED, and strictly restricts legal flow paths through state machine verification to prevent illegal state changes from affecting the consistency of parent-child table updates. The 2PC coordination unit is the core execution module for committing parent-child table update transactions, strictly executing the two-phase commit process. The RM registration unit maintains a global resource manager list, supports dynamic registration and deregistration of resource managers, and adapts to the system's elastic expansion, contraction, and operation and maintenance management needs.

[0012] Furthermore, the two-stage submission process is as follows:

[0013] (1) In the first stage and preparation stage, prepare requests are sent to all resource managers participating in the current transaction, and the results of the parent-child table status validity verification of each resource manager are collected synchronously.

[0014] (2) The second stage and the commit stage determine whether to commit or rollback based on the ready status. If all resource managers return ready, a commit command is sent to all resource managers to ensure that the parent and child tables of all nodes are persisted synchronously. If any response is not ready, a rollback command is sent to all resource managers to ensure that the parent and child tables of all nodes are rolled back synchronously.

[0015] Furthermore, the resource manager includes a resource operation unit, a transaction collaboration unit, a lock invocation unit, a reconnection unit, and a shadow table (sub-table) and summary table (parent table) association unit. The parent-sub-table association unit is responsible for maintaining the integrity of the primary key constraints between the shadow sub-table and the summary table, ensuring that the order ID of the shadow sub-table must exist in the summary table, and providing accurate association matching for the merge operation in the commit phase. At the same time, it ensures that when deleting an order in the summary table, the associated shadow sub-table record is deleted simultaneously to avoid data redundancy or isolation. The resource operation unit only implements the CRUD operations and booking operations of the corresponding travel resource shadow sub-table, and does not directly operate on the summary table. The booking operation is essentially a targeted update of the available resource quantity in the shadow sub-table. The data update of the summary table is only completed through the merge operation in the commit phase. The transaction collaboration unit implements the branch logic of transaction preparation, commit, and rollback: the preparation phase completes the legality verification of the resource status of the shadow sub-table and the operability verification of the order status in the summary table, and the commit phase verifies the transaction status. The transaction manager performs a merge operation from the shadow tables to the master table, summarizing and synchronizing the reservation information of each shadow sub-table corresponding to the same order ID to the master table. This achieves atomic updates of information such as order status and total amount in the master table. During the rollback phase, based on the old resource values ​​and version numbers recorded by the transaction log module, it accurately clears temporary data in the shadow sub-tables and restores the original state of the master table. The lock invocation unit calls the lock request and release interface of the lock manager. Query operations apply shared locks to the master table and shadow sub-tables, modification and reservation operations apply exclusive locks to shadow sub-tables, and merge operations apply exclusive locks to the master table. The combination lock mechanism ensures the concurrency security of operations related to the master table and shadow tables. The reconnection unit periodically calls the ping interface of the transaction manager through a timed heartbeat thread to detect the connection status with the transaction manager in real time. When the connection is interrupted, it reads the address information of the transaction manager from the configuration file and automatically triggers the retry and reconnection process until the connection is restored.

[0016] Furthermore, the lock manager includes a lock allocation unit, a conflict detection unit, a deadlock handling unit, and a lock release unit. The lock allocation unit supports differentiated allocation of read locks and write locks, and the lock granularity is precisely located to the resource primary key, such as flight number or room ID, avoiding the performance degradation caused by full table locks. Read locks allow multiple transactions to hold them simultaneously, enabling concurrent reads by multiple transactions and significantly improving the efficiency of scenarios such as master table order queries and shadow table resource verification. Write locks only allow a single transaction to hold them, ensuring the atomicity of write operations such as shadow table resource reservation modification and master table merging during the commit phase. For operations involving the master table and shadow tables, a "combined lock" processing strategy is adopted, that is, the same transaction must simultaneously apply for and hold locks on the corresponding resources in both tables to avoid data inconsistency between tables caused by single table locks. The conflict detection unit maintains a thread-safe lock resource mapping table in real time, recording resource identifiers, currently held lock types, holding transaction IDs, and waiting thread queues. It judges lock request requests in real time according to preset conflict rules, such as read lock vs. write lock conflicts, write lock vs. read lock conflicts, and write lock vs. write lock conflicts, while read locks do not conflict. When a conflict is detected, the requesting threads are added to the corresponding resource's waiting queue in the order of their requests, avoiding increased deadlock probability caused by disordered contention. The deadlock handling unit employs a "timeout detection + priority interruption" lock handling mechanism, with a default timeout of 5 seconds. It periodically scans the lock waiting queue to identify "circular wait" deadlock scenarios. When a lock request times out and fails to acquire the lock, it is automatically determined as a deadlock, an exception is thrown, and transactions initiated after the timeout are interrupted first, sorted by transaction start time, with lower-priority transactions initiated after the interruption. The lock release unit supports a dual lock handling mode of "active release + passive reclamation": after a transaction is successfully committed / rolled back, all lock resources held are actively released; if a transaction is abnormally interrupted, such as by deadlock or network interruption, the lock manager periodically scans for "zombie transactions", i.e., transactions that have not been active for a long time, and passively reclaims the lock resources held by them; after the lock is released, the first thread in the waiting queue is immediately woken up, and lock resources are allocated in turn to ensure system flow efficiency.

[0017] Furthermore, the transaction log module includes a log recording unit, a log persistence unit, and a log parsing unit. The log recording unit fully records all core information of transaction operations, and adds a correlation identifier field for operations on the master table and shadow tables. Specifically, this includes the transaction, operation type (INSERT / UPDATE / DELETE / RESERVE), resource type (flights / rooms / cars, etc.), resource primary key (such as flight number, hotel location), master table order ID, correlation identifier between master table and shadow table operations, old resource value (resource status before operation, stored using deep copy to ensure data accuracy), old resource version number (used to prevent dirty rollback), and transaction preparation status (NONE / READY / ABORT). Among these, the correlation identifier between master table and shadow table operations is used to accurately mark the linkage operations of the master table and each shadow table in the same distributed transaction, providing a core matching basis for cross-node master table and shadow table synchronous rollback and fault recovery. The log persistence unit writes transaction logs to the disk storage medium in real time, using an append-only write mode to ensure the order and integrity of log records, fundamentally preventing the loss of update logs for the master table and shadow table due to system crashes. In the event of a system restart or transaction rollback, the log parsing unit reads the disk log file and parses key information. It accurately matches the master table and corresponding shadow table records on different nodes through the operation association identifiers of the master table and shadow table, extracts the old values ​​and version numbers of resources from both sides, and synchronously restores the state of the master table and shadow table after version consistency verification, completely avoiding the situation where the master table and shadow table data are inconsistent.

[0018] Furthermore, the workflow controller includes a request forwarding unit, a liveness detection unit, and an exception handling unit. The request forwarding unit encapsulates the details of distributed calls, providing clients with a unified, standardized reservation interface, such as reserveFlight and reserveRoom, parsing and splitting client requests, generating operation instructions for the corresponding resource types, and accurately forwarding them to the matching transaction manager and resource manager. The liveness detection unit periodically calls the ping interfaces of the transaction manager and each resource manager through a background daemon thread to detect the service liveness status in real time, generating a service health status report to provide data support for operation and maintenance monitoring. The exception handling unit captures various exceptions during the remote call process and triggers corresponding handling strategies according to the exception type, such as triggering reconnection for network exceptions and triggering rollback for transaction exceptions, to ensure system stability.

[0019] Furthermore, the system also integrates an exception handling module, which formulates differentiated and precise handling strategies for various exception scenarios in a distributed environment, including: resource operation exceptions, transaction management exceptions, concurrency control exceptions, and network service exceptions.

[0020] Accordingly, a distributed reservation method for multi-resource collaboration includes the following steps:

[0021] Step 1: The client initiates a travel resource booking request. After receiving the request, the workflow controller calls the start method of the transaction manager to create a global transaction and obtain a globally unique transaction xid.

[0022] Step 2: The workflow controller parses and splits the reservation request, generates operation instructions for the corresponding resource type, and forwards them to the relevant resource managers. The instructions carry the transaction xid and complete reservation information.

[0023] Step 3: After receiving the operation command, the resource manager of the relevant type calls the lock method of the lock manager through the lock call unit to execute the lock processing flow of "combined lock application": first, it applies for write locks on the corresponding resource shadow sub-tables, and then applies for write locks on the corresponding order entries in the main table to ensure the atomicity of the dual-table lock application; if the lock application is successful, the subsequent reservation operation is executed; if there is a lock conflict, it enters the ordered waiting queue maintained by the lock manager and waits for the currently held lock to be released; if the lock application times out, the deadlock handling mechanism of the lock manager is triggered, and the current transaction is interrupted and the applied lock resources are released after being judged as deadlocked.

[0024] Step 4: The resource operation unit of the resource manager executes the reservation operation, which reduces the available quantity of the corresponding resource shadow table. At the same time, the status of the corresponding order in the master table is updated synchronously through the parent-child table association unit, such as from "pending" to "reserved". This realizes the linkage change between the master table and the shadow table within the same distributed transaction. The log recording unit of the transaction log module synchronously records the linkage operation log of the master table and the shadow table, clearly marking the association relationship and transaction ID between the order ID of the master table and the reservation record of the shadow table. The log persistence unit writes the log to the disk storage medium in real time to provide data support for subsequent transaction commit / rollback.

[0025] Step 5: The transaction collaboration unit of the resource manager returns the operation execution result to the workflow controller, i.e., success or failure;

[0026] Step 6: The workflow controller summarizes the execution results of all resource managers. If all resource managers return success, the commit method of the transaction manager is called to initiate a transaction commit; if any failure response is received, the abort method of the transaction manager is called to initiate a transaction rollback.

[0027] Step 7: The 2PC coordinating unit of the transaction manager executes the two-phase commit process;

[0028] Step 8: After the resource manager completes the commit or rollback operation, it executes the "batch ordered release" lock processing logic through the lock release unit: first release the write lock corresponding to the main table, and then release the write lock of the shadow sub-table to avoid momentary data inconsistency caused by improper release order; after release, the operation execution result is returned to the transaction manager, and at the same time, the lock manager wakes up the first thread in the corresponding resource waiting queue to complete the orderly handover of lock resources;

[0029] Step 9: The transaction manager updates the final state of the transaction to COMMITTED or ABORTED, completing the transaction loop; the workflow controller returns the standardized booking result to the client.

[0030] Furthermore, in step 7, the 2PC coordinating unit of the transaction manager executes the two-phase commit process, specifically including the following steps:

[0031] Step 71, Preparation Phase: The transaction manager updates the transaction status to PREPARING and sends a prepare request to all resource managers participating in the current transaction, namely the flight resource manager and the hotel room resource manager; the transaction collaboration unit of each resource manager completes the resource status validity check. If the check is valid, the transaction preparation status is updated to READY and the transaction is ready; if the check is invalid, the transaction is not ready.

[0032] Step 72, Commit Phase: The transaction manager collects the readiness status of all resource managers. If all resource managers return ready, the transaction status is updated to PREPARED, and a commit command is sent to all resource managers. After receiving the command, each resource manager executes the merge operation from the shadow table to the master table—matching by order ID, summarizing and synchronizing the booking records (resource type, booking quantity, unit price, etc.) of each shadow sub-table to the corresponding order entry in the master table, updating the order status of the master table to "confirmed," calculating and filling the total amount, achieving data unification between the master table and the shadow table, ensuring that the merge operation of all nodes in the distributed environment is completed synchronously, and updating the transaction status to COMMITTED. The merge operation ensures that the parent and child tables are consistent. The core of consistency lies in preventing the exposure of intermediate states caused by partial updates to the master table data during transaction execution. It ensures that the master table data can only be finally updated after all shadow sub-table operations are successful, thus eliminating data inconsistency at its source. If any resource manager returns "not ready," the transaction manager sends an abort command to all resource managers. After receiving the command, each resource manager parses the transaction log through the log parsing unit, accurately matches the associated records of different nodes based on the operation association identifiers of the master table and shadow tables, synchronously clears the temporary data of the shadow sub-tables, restores the original state of the master table (e.g., the order status is reset to "pending"), ensuring the consistency between the master table and the shadow tables after the distributed transaction is interrupted, and updates the transaction status to ABORTED.

[0033] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: The present invention can realize distributed collaborative management and integrated booking of multiple types of travel resources such as flights, hotels, and car rentals. It ensures the distributed transaction consistency of parent and child table updates, has high scalability, strong consistency, high concurrency adaptability and a sound fault tolerance mechanism, and can be widely applied to travel service scenarios with multi-node deployment. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the system architecture of the present invention.

[0035] Figure 2 The following is a schematic diagram illustrating the distributed transaction process of this invention, using the commit process as an example.

[0036] Figure 3 The following is a schematic diagram illustrating the distributed transaction process of this invention, using the commit process as an example.

[0037] Figure 4 The following is a schematic diagram illustrating the distributed transaction process of this invention, using the commit process as an example. Detailed Implementation

[0038] like Figure 1 As shown, a distributed reservation system for multi-resource collaboration comprises: a TransactionManager (TM), multiple ResourceManagers (RM), a LockManager, a Transaction Log module, and a WorkflowController (WC). The TransactionManager coordinates the ResourceManagers using a Two-Phase Commit Protocol (2PC) to achieve atomic execution of cross-node shadow and summary table updates. The LockManager employs a read-write lock separation mechanism to resolve concurrency conflicts and handles deadlock issues through timeout detection and proactive unlocking strategies. The Transaction Log module, based on a write-ahead log mechanism, fully records the details of shadow and summary table linkage operations, providing reliable support for fault recovery and transaction rollback. The WorkflowController encapsulates distributed call details, enabling real-time service liveness detection and automatic reconnection.

[0039] like Figure 2-4As shown, the transaction manager, as the global coordination core of distributed transactions, integrates four major functional modules: a global transaction (xid) generation unit, a transaction state management unit, a 2PC coordination unit, and an RM registration unit. The xid generation unit uses the AtomicInteger atomic class to generate globally unique transactions, fundamentally ensuring the uniqueness and allocation safety of transactions in multi-threaded concurrent scenarios, and avoiding confusion in parent-child table update transactions due to duplication. The transaction state management unit constructs a thread-safe transaction state mapping table using ConcurrentHashMap to store the correspondence between transactions and transaction states. Transaction states include ACTIVE, PREPARING, PREPARRED, COMMITTED, and ABORTED, and strictly restricts legal transition paths through state machine verification to prevent illegal state changes from affecting the consistency of parent-child table updates. The 2PC coordination unit is the core execution module for committing parent-child table update transactions, strictly executing the two-phase commit process.

[0040] 1. In the first and preparation phases, prepare requests are sent to all resource managers participating in the current transaction, and the results of the parent-child table status validity verification of each resource manager are collected synchronously.

[0041] 2. In the second and commit phases, the commit or rollback operation is performed based on the readiness status. If all resource managers return ready, a commit command is sent to all resource managers to ensure that the parent and child tables of all nodes are synchronously persisted. If any response is not ready, a rollback command is sent to all resource managers to ensure that the parent and child tables of all nodes are synchronously rolled back. The RM registration unit maintains a global list of resource managers, supports dynamic registration and deregistration of resource managers, and adapts to the system's elastic expansion, contraction, and operation and maintenance management needs.

[0042] Secondly, the resource managers are deployed independently according to travel resource types. Typical types include flight resource managers (RMFlights), hotel room resource managers (RMRooms), car resource managers (RMCars), and customer resource managers (RMCustomers). Resource manager types can be flexibly added or removed according to business needs, achieving flexibility in business expansion. Each resource manager integrates five functional modules: resource operation unit, transaction collaboration unit, lock invocation unit, reconnection unit, and shadow table (child table) and summary table (parent table) association unit. Among these, the parent-child table data storage module is the core data carrier of the system, explicitly adopting a "master table + shadow table" parent-child table design. The table structures of the parent and child tables are completely identical and use a hash table storage method. The child table only stores temporary data during transaction execution, merges it into the master table upon commit, and clears it upon rollback.

[0043] 1. The parent-child table association unit is responsible for maintaining the integrity of the primary key constraints between the shadow child table and the main table, ensuring that the order ID of the shadow child table must exist in the main table, and providing accurate association matching for the merge operation in the submission stage. At the same time, it ensures that when an order is deleted from the main table, the associated shadow child table record is deleted simultaneously to avoid data redundancy or isolation.

[0044] 2. The resource operation unit only implements the CRUD operations and booking operations of the corresponding travel resource shadow sub-tables. It does not directly operate on the master table. The booking operation is essentially a targeted update of the available resource quantity in the shadow sub-table. The master table data update is only completed through the merge operation during the submission phase.

[0045] 3. The transaction collaboration unit implements the branch logic of transaction preparation, commit, and rollback: In the preparation phase, the legality of the resource status of the shadow sub-table and the operability of the order status in the main table are verified. In the commit phase, the core operation of merging the shadow table into the main table is performed, and the reservation information of each shadow sub-table corresponding to the same order ID is summarized and synchronized to the main table, realizing the atomic update of information such as order status and total amount in the main table. In the rollback phase, based on the old value and version number of the resource recorded by the transaction log module, the temporary data of the shadow sub-table is accurately cleared and the original state of the main table is restored.

[0046] 4. The lock invocation unit calls the lock request and release interface of the lock manager. The query operation applies a shared lock to the main table and a shared lock to the shadow sub-table. The modification and reservation operation applies an exclusive lock to the shadow sub-table. The merge operation applies an exclusive lock to the main table. The combination lock mechanism ensures the concurrency safety of the operation of the main table and the shadow table.

[0047] 5. The reconnection unit periodically calls the ping interface of the transaction manager through a timed heartbeat thread to detect the connection status with the transaction manager in real time. When the connection is interrupted, it reads the address information of the transaction manager from the configuration file and automatically triggers the retry and reconnection process until the connection is restored.

[0048] Furthermore, the lock manager is embedded within each resource manager, integrating four major functional modules: lock allocation unit, conflict detection unit, deadlock handling unit, and lock release unit. The core adopts a full-process lock processing solution of "precise lock granularity + orderly conflict handling + intelligent deadlock resolution".

[0049] 1. The lock allocation unit supports differentiated allocation of read locks and write locks, and the lock granularity is precisely located to the resource primary key, such as flight number or room ID, avoiding the performance degradation caused by full table locks. Read locks allow multiple transactions to hold them simultaneously, enabling concurrent reads by multiple transactions and significantly improving the efficiency of scenarios such as master table order queries and shadow table resource verification; write locks only allow a single transaction to hold them, ensuring the atomicity of write operations such as shadow table resource reservation modification and master table merging during the commit phase; for operations involving the master table and shadow tables, a "combined lock" processing strategy is adopted, that is, the same transaction must simultaneously apply for and hold locks on the corresponding resources in both tables, avoiding data inconsistency between tables caused by single table locks.

[0050] 2. The conflict detection unit maintains a thread-safe lock resource mapping table in real time, recording the resource identifier, the currently held lock type, the holding transaction ID, and the waiting thread queue. According to preset conflict rules, such as read lock and write lock conflict, write lock and read lock conflict, write lock and write lock conflict, and read lock and read lock not conflicting, it judges lock request requests in real time. When a conflict is detected, the requesting thread is added to the waiting queue of the corresponding resource in the order of request to avoid the increased probability of deadlock caused by disordered competition.

[0051] 3. The deadlock handling unit adopts a lock handling mechanism of "timeout detection + priority interruption". The default timeout is set to 5 seconds. It identifies deadlock scenarios of "circular wait" by periodically scanning the lock waiting queue. When the lock request times out and the lock is not acquired, it is automatically judged as a deadlock and throws an exception. It also interrupts transactions initiated after the timeout, sorting them by transaction start time and interrupting the low-priority transactions initiated after the timeout.

[0052] 4. The lock release unit supports a dual lock processing mode of "active release + passive reclamation": After a transaction is successfully committed / rolled back, all lock resources held are actively released; if the transaction is abnormally interrupted, such as by deadlock or network interruption, the lock manager periodically scans for "zombie transactions", i.e., transactions that have not been active for a long time, and passively reclaims the lock resources held by them; after the lock is released, the first thread in the waiting queue is immediately woken up, and lock resources are allocated in turn to ensure system flow efficiency.

[0053] The transaction log module further integrates three major functional modules: log recording unit, log persistence unit, and log parsing unit. Its core function is to provide traceability and recoverability for distributed transactions that update the master table and shadow table.

[0054] 1. The log recording unit fully records all core information of transaction operations. A new association identifier field has been added for operations on the master table and shadow tables. This includes the transaction, operation type (INSERT / UPDATE / DELETE / RESERVE), resource type (flights / rooms / cars, etc.), resource primary key (e.g., flight number, hotel location), master table order ID, master table and shadow table operation association identifier, old resource value (resource status before the operation, stored using a deep copy to ensure data accuracy), old resource version number (used to prevent dirty rollback), and transaction preparation status (NONE / READY / ABORT). The master table and shadow table operation association identifier is used to accurately mark the linked operations of the master table and each shadow table within the same distributed transaction, providing a core matching basis for cross-node master table and shadow table synchronization rollback and fault recovery.

[0055] 2. The log persistence unit writes transaction logs to the disk storage medium in real time, using an append-only write mode to ensure the order and integrity of log records, fundamentally preventing the loss of update logs for the master table and shadow table due to system crashes. In the event of a system restart or transaction rollback, the log parsing unit reads the disk log file and parses key information. It accurately matches the master table and corresponding shadow table records on different nodes through the operation association identifiers of the master table and shadow table, extracts the old values ​​and version numbers of resources from both sides, and synchronously restores the state of the master table and shadow table after version consistency verification, completely avoiding the situation where the master table and shadow table data are inconsistent.

[0056] Finally, the workflow controller, acting as an intermediate adaptation layer between the client and the underlying components, integrates three major functional modules: a request forwarding unit, a liveness detection unit, and an exception handling unit. The request forwarding unit encapsulates the details of distributed calls, providing clients with a unified, standardized reservation interface, such as `reserveFlight` and `reserveRoom`, parsing and splitting client requests, generating operation instructions for the corresponding resource types, and accurately forwarding them to the matching transaction manager and resource manager. The liveness detection unit periodically calls the ping interfaces of the transaction manager and each resource manager through a background daemon thread to detect the service's liveness status in real time, generating a service health status report to provide data support for operation and maintenance monitoring. The exception handling unit captures various exceptions during the remote call process and triggers corresponding handling strategies based on the exception type, such as reconnection for network exceptions and rollback for transaction exceptions, ensuring system stability.

[0057] In addition, the system also integrates an anomaly handling module, which formulates differentiated and precise handling strategies for various anomaly scenarios in a distributed environment, specifically including:

[0058] 1. Resource operation exception: The core exception is InvalidIndexException, which is triggered when calling the getIndex method of a resource entity using an invalid index name. The handling strategy is to return a standardized error message "invalid index" to the client after catching the exception, and at the same time record a detailed exception log containing the transaction xid, resource type, and invalid index name to provide developers with accurate basis for troubleshooting.

[0059] 2. Transaction Management Exceptions: This includes three core exceptions: InvalidTransactionException, TransactionAbortedException, and TransactionManagerUnaccessibleException. InvalidTransactionException is triggered when an operation uses an invalid xid (e.g., a non-existent transaction or a completed transaction). The handling strategy is to immediately terminate the current operation, return a standardized "transaction invalid" error message to the client, and log the exception. TransactionAbortedException is triggered when a transaction is aborted due to deadlock, insufficient resources, or other reasons. The handling strategy is to trigger a global rollback process, restore the resources to their original state, and display "Reservation failed, please retry" to the client. TransactionManagerUnaccessibleException is triggered when the resource manager or workflow controller cannot connect to the transaction manager. The handling strategy is to initiate an automatic reconnection mechanism, periodically retrying the connection. If the connection fails for an extended period, a fallback mode is entered, rejecting new transaction requests and triggering an operational alarm to avoid resource waste.

[0060] 3. Concurrency control exceptions: These include two types: DeadLockException and RedundantLockRequestException. DeadLockException is triggered when a lock request times out and a deadlock is detected. The handling strategy is to interrupt one of the transactions, prioritizing the interruption of transactions initiated later, releasing all lock resources held by those transactions, waking up waiting threads, and logging a deadlock log containing the transaction xid, involved resources, and lock type. RedundantLockRequestException is triggered when a transaction repeatedly requests a lock it already holds. The handling strategy is to ignore redundant requests, log a warning, and prompt developers to optimize the code logic.

[0061] 4. Network service exceptions: The core exceptions are Remote call exception (RemoteException) and Service not bound exception (NotBoundException). RemoteException is triggered when RMI call fails, such as when the resource manager crashes or the network is interrupted. The handling strategy is to start a timed reconnection mechanism in the workflow controller or resource manager until the service is restored. NotBoundException is triggered when the RMI service is not bound, such as when the resource manager is not started or the binding name is incorrect. The handling strategy is to check the service binding status at startup. If binding fails, an error log is output and the system exits, prompting the user to check the service configuration.

[0062] Accordingly, a distributed travel booking method based on the above system includes the following core steps:

[0063] S1: The client initiates a travel resource booking request, such as a combined booking of flights and hotels. After receiving the request, the workflow controller calls the start method of the transaction manager to create a global transaction and obtain a globally unique transaction xid.

[0064] S2: The workflow controller parses and splits the booking request, generates operation instructions for the corresponding resource type, and forwards them to the flight resource manager and hotel room resource manager respectively. The instructions carry the transaction xid and complete booking information, such as flight number, hotel location, and number of bookings.

[0065] S3: After receiving the operation instructions, the Flight Resource Manager and Hotel Room Resource Manager call the lock method of the Lock Manager through the lock call unit to execute the lock processing flow of "combined lock application": first, they apply for write locks on the corresponding resource shadow sub-tables respectively, and then apply for write locks on the corresponding order entries in the master table to ensure the atomicity of the dual-table lock application; if the lock application is successful, the subsequent booking operation is executed; if there is a lock conflict, it enters the ordered waiting queue maintained by the Lock Manager and waits for the currently held lock to be released; if the lock application times out, the deadlock handling mechanism of the Lock Manager is triggered, and the current transaction is interrupted and the applied lock resources are released after being judged as deadlocked;

[0066] S4: The resource operation unit of the resource manager executes the reservation operation, which reduces the available quantity of the corresponding resource shadow table in a targeted manner. At the same time, it updates the status of the corresponding order in the master table synchronously through the parent-child table association unit, such as updating it from "pending" to "reserved". This realizes the linkage change between the master table and the shadow table within the same distributed transaction. The log recording unit of the transaction log module synchronously records the linkage operation log of the master table and the shadow table, clearly marking the association relationship and transaction ID between the order ID of the master table and the reservation record of the shadow table. The log persistence unit writes the log to the disk storage medium in real time, providing data support for subsequent transaction commit / rollback.

[0067] S5: The Resource Manager's Transaction Collaboration Unit returns the operation execution result to the Workflow Controller, i.e., success or failure;

[0068] S6: The workflow controller summarizes the execution results of all resource managers. If all resource managers return success, the commit method of the transaction manager is called to initiate a transaction commit; if any failure response is received, the abort method of the transaction manager is called to initiate a transaction rollback.

[0069] S7: The Transaction Manager's 2PC Coordination Unit executes a two-phase commit process:

[0070] S7-1: Preparation Phase: The transaction manager updates the transaction status to PREPARING and sends a prepare request to all resource managers participating in the current transaction, namely the flight resource manager and the hotel room resource manager; the transaction collaboration unit of each resource manager completes the resource status validity check. If the check is valid, the transaction preparation status is updated to READY and the transaction is ready; if the check is invalid, the transaction is not ready.

[0071] S7-2: Commit Phase: The transaction manager collects the readiness status of all resource managers. If all resource managers return ready, the transaction status is updated to PREPARED, and a commit command is sent to all resource managers. After receiving the command, each resource manager executes the merge operation from the shadow table to the master table—matching by order ID, summarizing and synchronizing the booking records (resource type, booking quantity, unit price, etc.) of each shadow sub-table to the corresponding order entries in the master table, updating the order status of the master table to "confirmed," calculating and filling the total amount, achieving data unification between the master table and the shadow table, ensuring that the merge operation of all nodes in the distributed environment is completed synchronously, and updating the transaction status to COMMITTED. The merge operation ensures that the parent and child tables are consistent. The core of consistency lies in avoiding the exposure of intermediate states caused by partial updates to the master table data during transaction execution. It ensures that the master table data can only be finally updated after all shadow sub-table operations are successful, thus eliminating data inconsistency at its source. If any resource manager returns "not ready," the transaction manager sends an abort command to all resource managers. After receiving the command, each resource manager parses the transaction log through the log parsing unit, accurately matches the associated records of different nodes based on the operation association identifiers of the master table and shadow tables, synchronously clears the temporary data of the shadow sub-tables, restores the original state of the master table (e.g., the order status is reset to "pending"), ensuring the consistency between the master table and the shadow tables after the distributed transaction is interrupted, and updates the transaction status to ABORTED.

[0072] S8: After the resource manager completes the commit or rollback operation, it executes the "batch ordered release" lock processing logic through the lock release unit: first release the write lock corresponding to the main table, and then release the write lock of the shadow sub-table to avoid momentary data inconsistency caused by improper release order; after release, the operation execution result is returned to the transaction manager, and at the same time the lock manager wakes up the first thread in the corresponding resource waiting queue to complete the orderly handover of lock resources;

[0073] S9: The transaction manager updates the transaction's final state to COMMITTED or ABORTED, completing the transaction loop; the workflow controller returns a standardized booking result to the client.

[0074] Compared with the prior art, the present invention has the following significant advantages:

[0075] 1. High scalability: This invention adopts a modular splitting and independent deployment design. Each resource manager is deployed independently according to resource type, and service registration and automatic discovery are realized through the RMI registry. When adding a new resource type, only the corresponding resource manager and resource entity class need to be implemented, without modifying the core framework code. At the same time, the resource manager supports dynamic registration and deregistration, and can be flexibly expanded and shrunk according to business needs, accurately adapting to business changes.

[0076] 2. Strong Transaction Consistency: The core advantage of this invention lies in its parent-child table design of "shadow table temporary storage + merging during the commit phase," which precisely guarantees cross-node distributed transaction consistency. Through the transaction manager executing an optimized two-phase commit (2PC) protocol, shadow table operations and merge operations are integrated into a unified transaction coordination, ensuring that the merge operation to the main table is only executed after all shadow table operations have succeeded, achieving atomicity of "either a full merge or a full rollback." The merge operation, as a core connecting link, effectively isolates intermediate data during transaction execution, preventing data corruption in the main table due to partial success. Simultaneously, precise matching and synchronization are achieved through parent-child table association identifiers. Combined with the write-ahead log mechanism of the transaction log module, complete information on shadow table operations and merge operations, including association identifiers, bidirectional status data, and version numbers, is recorded, providing reliable support for fault recovery and transaction rollback. The resource version number verification mechanism effectively avoids dirty rollback issues, completely resolving the core pain points of asynchronous parent-child table updates, data isolation, or redundancy in traditional distributed systems, ensuring the integrity of order data.

[0077] 3. High-efficiency concurrency control: The lock manager of this invention adopts a read-write lock separation mechanism, which allows multiple transactions to read resources at the same time and only blocks during write operations, greatly improving the efficiency of concurrent queries; through precise lock granularity control by locking according to the resource primary key, the scope of lock conflicts is effectively reduced; combined with the deadlock handling mechanism of timeout detection and active interruption, system blocking is avoided and the system's concurrent processing capability is significantly improved.

[0078] 4. Robust fault tolerance: This invention ensures rapid recovery after temporary service interruptions through dual liveness detection and automatic reconnection mechanisms of the workflow controller and resource manager; the persistent storage mechanism of the transaction log supports fault recovery after system crashes, avoiding data loss; and the independent deployment mode of components ensures that the failure of a single resource manager will not affect the normal operation of other resource managers, achieving fault isolation and significantly improving the overall availability of the system.

[0079] 5. Flexible deployment and configuration: This invention dynamically manages the ports and service names of each component through configuration files. The deployment process does not require modification of the core code and can quickly adapt to different deployment environments. It supports multi-node distributed deployment, and each node does not need to hardcode address information, which greatly reduces deployment and maintenance costs.

[0080] 6. Precise Anomaly Handling: This invention formulates differentiated and precise handling strategies for resource operation anomalies, transaction management anomalies, concurrency control anomalies, and network service anomalies in a distributed environment. This enables precise anomaly capture, rapid handling, and log tracing, preventing error propagation and significantly improving system stability.

Claims

1. A distributed reservation system for multi-resource collaboration, characterized in that, include: Transaction manager, at least two resource managers, lock manager, transaction log module, and workflow controller; The transaction manager coordinates the resource managers through the two-phase commit (2PC) protocol to achieve atomic execution of cross-node shadow and summary table updates; The lock manager uses a read-write lock separation mechanism to resolve concurrent conflicts and handles deadlock issues through timeout detection and active unlocking strategies. The transaction log module fully records the details of shadow and summary table linked operations based on the write-ahead log mechanism, providing reliable support for fault recovery and transaction rollback; the workflow controller encapsulates the details of distributed calls, realizing real-time service liveness detection and automatic reconnection functions.

2. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The transaction manager includes a global transaction xid generation unit, a transaction state management unit, a 2PC coordination unit, and an RM registration unit. The xid generation unit uses the AtomicInteger atomic class to generate globally unique transactions. The transaction state management unit constructs a thread-safe transaction state mapping table through ConcurrentHashMap to store the correspondence between transactions and transaction states. Transaction states include ACTIVE, PREPARING, PREPARRED, COMMITTED, and ABORTED, and the legal flow path is strictly restricted through state machine verification. The 2PC coordination unit is the core execution module for updating transaction commits between parent and child tables, strictly executing the two-phase commit process. The RM registration unit maintains a global list of resource managers, supports dynamic registration and deregistration of resource managers, and adapts to the system's elastic expansion, contraction, and operation and maintenance management needs.

3. The distributed reservation system for multi-resource collaboration as described in claim 2, characterized in that, The two-stage submission process is as follows: (1) In the first stage and preparation stage, prepare requests are sent to all resource managers participating in the current transaction, and the results of the parent-child table status validity verification of each resource manager are collected synchronously. (2) The second stage and the commit stage determine whether to commit or rollback based on the ready status. If all resource managers return ready, a commit command is sent to all resource managers to ensure that the parent and child tables of all nodes are persisted synchronously. If any unready response exists, an abort command is sent to all resource managers to ensure that the parent and child tables of all nodes are rolled back synchronously.

4. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The resource manager includes a resource operation unit, a transaction collaboration unit, a lock invocation unit, a reconnection unit, and a shadow table (sub-table) and summary table (parent table) association unit. The parent-child table association unit is responsible for maintaining the integrity of the primary key constraints between the shadow sub-table and the summary table, ensuring that the order ID of the shadow sub-table must exist in the summary table, and providing accurate association matching for the merge operation in the commit phase. It also ensures that when an order in the summary table is deleted, the associated shadow sub-table record is deleted simultaneously. The resource operation unit only implements CRUD operations and booking operations for the corresponding travel resource shadow sub-table, and does not directly operate on the summary table. The booking operation is essentially a targeted update of the available resource quantity in the shadow sub-table. The data update in the summary table is only completed through the merge operation in the commit phase. The transaction collaboration unit implements the branch logic for transaction preparation, commit, and rollback: In the preparation phase, it verifies the legality of resource status in shadow sub-tables and the operability of order status in the master table. In the commit phase, it performs a core operation to merge shadow tables into the master table, summarizing and synchronizing the reservation information of each shadow sub-table corresponding to the same order ID to the master table, achieving atomic updates to the order status and total amount information in the master table. In the rollback phase, based on the old resource values ​​and version numbers recorded by the transaction log module, it accurately clears temporary data in shadow sub-tables and restores the original state of the master table. The lock invocation unit calls the lock manager's lock request and release interfaces. Query operations apply shared locks to the master table and shadow sub-tables; modification and reservation operations apply exclusive locks to shadow sub-tables; and merge operations apply exclusive locks to the master table. This combined lock mechanism ensures the concurrent security of operations related to the master table and shadow tables. The reconnection unit periodically calls the transaction manager's ping interface through a timed heartbeat thread to monitor the connection status with the transaction manager in real time. When the connection is interrupted, it reads the transaction manager's address information from the configuration file and automatically triggers a retry and reconnection process until the connection is restored.

5. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The lock manager includes a lock allocation unit, a conflict detection unit, a deadlock handling unit, and a lock release unit; The lock allocation unit supports differentiated allocation of read locks and write locks, and the lock granularity is precisely located to the resource primary key. Read locks allow multiple transactions to hold them at the same time, while write locks only allow a single transaction to hold them. For the linkage operation between the master table and the shadow table, a "combined lock" processing strategy is adopted, that is, the same transaction must apply for and hold locks on the corresponding resources of both tables at the same time. The conflict detection unit maintains a thread-safe lock resource mapping table in real time, recording resource identifiers, currently held lock types, holding transaction IDs, and waiting thread queues. It judges lock request requests in real time according to preset conflict rules, and when a conflict is detected, the requesting threads are added to the corresponding resource's waiting queue in the order of their requests. The deadlock handling unit adopts a "timeout detection + priority interruption" lock handling mechanism, with a default timeout of 5 seconds. By periodically scanning the lock waiting queue, it identifies "circular wait" deadlock scenarios. When a lock request times out and fails to acquire the lock, it automatically determines it as a deadlock, throws an exception, and prioritizes interrupting transactions initiated after the current transaction, sorted by transaction start time, and interrupting lower-priority transactions initiated after the current transaction. The lock release unit supports a dual lock handling mode of "active release + passive reclamation": after a transaction completes its commit / rollback normally, it actively releases all held lock resources. If a transaction is abnormally interrupted, the lock manager periodically scans for "zombie transactions," which are transactions that have not been active for a long time. The lock resources held by these transactions are passively reclaimed. Once the lock is released, the first thread in the waiting queue is immediately awakened, and lock resources are allocated in turn.

6. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The transaction log module includes a log recording unit, a log persistence unit, and a log parsing unit. The log recording unit fully records all core information of transaction operations and adds a correlation identifier field for operations on the master table and shadow tables. The correlation identifier for operations on the master table and shadow tables is used to accurately mark the linkage operations between the master table and each shadow table in the same distributed transaction. The log persistence unit writes the transaction log to the disk storage medium in real time and uses an append write mode to ensure the order and integrity of log recording. In system restart or transaction rollback scenarios, the log parsing unit reads disk log files and parses key information. It accurately matches the records in the master table and corresponding shadow table on different nodes through the operation association identifiers of the master table and shadow table, extracts the old values ​​and version numbers of resources from both sides, and synchronously restores the state of the master table and shadow table after version consistency verification.

7. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The workflow controller includes a request forwarding unit, a liveness detection unit, and an exception handling unit. The request forwarding unit encapsulates the details of distributed calls, provides a unified and standardized reservation interface for clients, parses and splits client requests, generates operation instructions for the corresponding resource types, and accurately forwards them to the matching transaction manager and resource manager. The liveness detection unit periodically calls the ping interfaces of the transaction manager and each resource manager through a background daemon thread to detect the service liveness status in real time and generate a service health status report. The exception handling unit captures various exceptions during the remote call process and triggers corresponding handling strategies based on the exception type to ensure system stability.

8. The distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, The system also integrates an exception handling module, which formulates differentiated and precise handling strategies for various exception scenarios in a distributed environment, including: resource operation exceptions, transaction management exceptions, concurrency control exceptions, and network service exceptions.

9. A reservation method based on a distributed reservation system for multi-resource collaboration as described in claim 1, characterized in that, Includes the following steps: Step 1: The client initiates a reservation request. After receiving the request, the workflow controller calls the start method of the transaction manager to create a global transaction and obtain a globally unique transaction xid. Step 2: The workflow controller parses and splits the reservation request, generates operation instructions for the corresponding resource type, and forwards them to the relevant resource managers. The instructions carry the transaction xid and complete reservation information. Step 3: After receiving the operation command, the resource manager of the relevant type calls the lock method of the lock manager through the lock call unit to execute the lock processing flow of "combined lock application": first, it applies for write locks on the corresponding resource shadow sub-tables, and then applies for write locks on the corresponding order entries in the main table to ensure the atomicity of the dual-table lock application; if the lock application is successful, the subsequent reservation operation is executed; if there is a lock conflict, it enters the ordered waiting queue maintained by the lock manager and waits for the currently held lock to be released; if the lock application times out, the deadlock handling mechanism of the lock manager is triggered, and the current transaction is interrupted and the applied lock resources are released after being judged as deadlocked. Step 4: The resource operation unit of the resource manager executes the reservation operation, reducing the available quantity of the corresponding resource shadow table. At the same time, the status of the corresponding order in the master table is updated synchronously through the parent-child table association unit, such as updating from "pending" to "reserved". This realizes the linkage change between the master table and the shadow table within the same distributed transaction. The log recording unit of the transaction log module synchronously records the linkage operation log of the master table and the shadow table, clearly marking the association relationship and transaction ID between the order ID of the master table and the reservation record of the shadow table. The log persistence unit writes the log to the disk storage medium in real time, providing data support for subsequent transaction commit / rollback. Step 5: The transaction collaboration unit of the resource manager returns the operation execution result to the workflow controller, i.e., success or failure; Step 6: The workflow controller summarizes the execution results of all resource managers. If all resource managers return success, the commit method of the transaction manager is called to initiate a transaction commit. If any failure response is received, the transaction manager's abort method is called to initiate a transaction rollback; Step 7: The 2PC coordination unit of the transaction manager executes the two-phase commit process; Step 8: After the resource manager completes the commit or rollback operation, it executes the "batch ordered release" lock processing logic through the lock release unit: first release the write lock corresponding to the main table, and then release the write lock of the shadow sub-table to avoid momentary data inconsistency caused by improper release order; after release, the operation execution result is returned to the transaction manager, and at the same time, the lock manager wakes up the first thread in the corresponding resource waiting queue to complete the orderly handover of lock resources. Step 9: The transaction manager updates the final state of the transaction to COMMITTED or ABORTED, completing the transaction loop; the workflow controller returns the standardized booking result to the client.

10. The distributed reservation method for multi-resource collaboration as described in claim 9, characterized in that, In step 7, the 2PC coordinating unit of the transaction manager executes the two-phase commit process, which specifically includes the following steps: Step 71, Preparation Phase: The transaction manager updates the transaction status to PREPARING and sends a prepare request to all resource managers participating in the current transaction; each resource manager's transaction collaboration unit completes the resource status validity check, and if the check is valid, it updates the transaction preparation status to READY and returns ready. If the validation fails, return "Not Ready"; Step 72, Commit Phase: The transaction manager collects the readiness status of all resource managers. If all resource managers return ready, the transaction status is updated to PREPARED, and a commit command is sent to all resource managers. After receiving the command, each resource manager performs the merge operation from the shadow table to the master table—matching by order ID, summarizing and synchronizing the reservation records of each shadow sub-table to the corresponding order entries in the master table, updating the order status of the master table to "confirmed," calculating and filling the total amount, achieving data unification between the master table and the shadow table, and updating the transaction status to COMMITTED. If any resource manager returns not ready, the transaction manager sends an abort command to all resource managers. After receiving the command, each resource manager parses the transaction log through the log parsing unit, accurately matches the associated records of different nodes based on the operation association identifiers of the master table and the shadow table, synchronously clears the temporary data of the shadow sub-table, restores the original state of the master table, and updates the transaction status to ABORTED.

Images