A distributed transaction consistency guarantee method for medical information integration

Abstract

The present application relates to the technical field of medical information integration and distributed processing, in particular to a distributed transaction consistency guarantee method for medical information integration, to solve the technical problem that the system throughput seriously decreases due to synchronous locking in the existing two-phase commit scheme during the peak period of medical business. The technical scheme comprises: analyzing the distributed transaction request to determine the participating nodes and the task message; collecting the real-time load of each node, and temporarily storing the message in the delay queue when the node is busy; predicting the transmission time consumption and the processing time consumption of each message; aligning all node completion time as the target, and reversely calculating the differentiated delay sending time length of each message; timing according to the time length in the delay queue, and triggering sending when the time comes; after receiving the confirmation of all node readiness, broadcasting the commit instruction; the present application replaces passive resource locking with active timing scheduling, which guarantees the strong consistency of medical data and improves the throughput of the system in the high concurrency scenario.

Description

Technical Field

[0001] This invention relates to the field of medical information integration and distributed processing technology, and more specifically, to a distributed transaction consistency guarantee method for medical information integration. Background Technology

[0002] In large medical institutions, a typical patient service often involves multiple independent and heterogeneous business systems such as registration, billing, wards, and examinations. To ensure that accounts match reality and records are consistent, a distributed transaction coordination mechanism is needed to ensure that these cross-system operations are performed as if they were completed within a single database, possessing atomicity and consistency.

[0003] Currently, the standard solution to ensure consistency in such distributed transactions is a two-phase commit protocol. Taking a hospital admission procedure as an example, the transaction coordinator sends preparation instructions to the registration system, the financial system, and the ward system respectively. After receiving the instructions, the registration system temporarily locks the patient's registration record; the financial system freezes the corresponding prepayment amount; and the ward system reserves an empty bed. Only after all three systems have completed locking and responded that they can commit will the coordinator issue a formal commit instruction. Each system then unlocks and performs the actual write. During this process, if one system fails to respond, the resources of the other systems must remain locked and wait. During the entire transaction, other patients cannot operate on these locked resources.

[0004] The aforementioned solution revealed a fatal flaw during peak medical service periods. During the morning outpatient rush, hundreds of patients were simultaneously admitted and discharged. Each admission transaction required the registration, finance, and ward systems to lock relevant resources and wait for each other. Since the ward allocation process often took a long time due to manual confirmation, the registration and finance systems, although ready instantly, were stuck for a long time and unable to serve subsequent patients. The backlog of requests caused the system response to slow down significantly or even time out, dragging down the entire hospital's online operations. This synchronous blocking problem urgently requires a new method in medical information integration that can ensure data consistency without sacrificing throughput.

[0005] Therefore, a distributed transaction consistency guarantee method for medical information integration is proposed. Summary of the Invention

[0006] The purpose of this invention is to provide a distributed transaction consistency guarantee method for medical information integration, so as to solve the technical problem that the existing two-phase commit scheme causes a serious drop in system throughput due to synchronization locking during peak medical business periods.

[0007] To address the aforementioned technical problems, the present invention aims to provide a distributed transaction consistency guarantee method for medical information integration, executed by a transaction coordinator, comprising the following steps: Receive distributed transaction requests across multiple heterogeneous medical business systems, parse the distributed transaction requests to determine multiple business nodes participating in the distributed transaction and the task messages to be sent to each business node; Collect the current number of concurrent tasks and the task queue depth of each business node. If the sum of the number of concurrent tasks and the queue depth of any business node exceeds the preset load limit, then all the task messages will be temporarily stored in the delayed sending queue. The data size of the task message is obtained, and the network round-trip delay between the transaction coordinator and each service node is measured. Based on the data size and the round-trip delay, the predicted transmission time of each task message to the corresponding service node is calculated. Obtain the historical baseline time for each business node to process similar transactions, and calculate the predicted processing time for each business node by combining the current number of concurrent tasks and the task queue depth of the corresponding business node. For each service node, its predicted transmission time is added to its predicted processing time to obtain the estimated total time of the service node, and the maximum value of the estimated total time of all service nodes is taken as the maximum estimated total time. The estimated total time of each service node is subtracted from the maximum estimated total time to obtain the delayed transmission time corresponding to each service node. In the delayed transmission queue, a countdown is started according to the delayed transmission duration of each service node. Whenever the delayed transmission duration of a service node reaches zero, its corresponding task message is sent to that service node through the underlying network interface. Once a ready confirmation is received from all business nodes indicating that the task message has been processed, a submit instruction is broadcast to all business nodes, driving each business node to release its local database exclusive lock.

[0008] As a further improvement to this technical solution, the predicted processing time of each business node is calculated by combining the current concurrent task count and task queue depth of the corresponding business node, using the following method: ,in, For business nodes Predicted processing time, For business nodes Historical benchmark time For business nodes The current number of concurrent tasks, For business nodes Task queue depth, For the preset concurrent load weight constant, This is a preset queuing time penalty constant.

[0009] As a further improvement to this technical solution, after broadcasting the submission instruction to all service nodes, a closed-loop correction step for the historical benchmark time is also included: Collect the actual processing time of each business node from receiving the task message to returning a ready confirmation; Calculate the absolute error between the actual processing time and the predicted processing time; When the absolute error exceeds a preset tolerance threshold, the historical benchmark time is updated using the actual processing time. .

[0010] As a further improvement to this technical solution, the step of calculating the predicted transmission time for each task message to reach the corresponding service node based on the data volume and the round-trip delay includes: Extract the set of round-trip delays of network links within a preset time window, remove extreme values, and then calculate the average round-trip delay. Estimate the current link bandwidth based on the average round-trip time and the maximum transmission unit of the underlying network protocol; Divide the data size of the task message by the current link bandwidth to obtain the message serialization and transmission time; Half of the average round-trip time is taken as the theoretical one-way physical transmission time; The predicted transmission time is obtained by adding the serialization transmission time to the one-way physical transmission time.

[0011] As a further improvement to this technical solution, after sending the corresponding task message to the service node through the underlying network interface, a strong consistency rollback step is also included: Start a global timeout monitor associated with the maximum estimated total timeout; If, when the global timeout monitor reaches the preset timeout blocking threshold, there are still business nodes that have not returned a ready confirmation, or an execution exception response is received from any business node, a global rollback instruction is broadcast to all business nodes that have returned ready confirmation, driving these business nodes to discard their local uncommitted transaction data and release the local database exclusive locks they occupy.

[0012] As a further improvement to this technical solution, after receiving distributed transaction requests across multiple heterogeneous medical business systems, the method further includes: The distributed transaction request is unpacked, and the structured field form for medical business is extracted from it; Remove the medical image attachments and unstructured text attachments contained in the request; The structured field form is serialized into a lightweight message with a fixed format, and this message is used as the task message in the subsequent temporary storage step.

[0013] As a further improvement to this technical solution, when sending the corresponding task message to the service node through the underlying network interface, it also includes: Inject a globally unique transaction ID and version number timestamp into the request header of each task message; When each business node receives a task message, it is triggered to perform idempotency verification using the transaction ID and to perform optimistic locking comparison on the local data table using the version number timestamp.

[0014] As a further improvement to this technical solution, the collection of the current concurrent task count and task queue depth of each business node includes: Initiate underlying status probe requests to the database connection pools of each business node; The number of active threads returned by the database connection pool is read in real time and used as the current number of concurrent tasks; The number of waiting connection requests on the application layer transport protocol port is read and used as the task queue depth.

[0015] As a further improvement to this technical solution, after broadcasting the global rollback instruction to all service nodes that have returned ready confirmation, the method further includes: Record the identifier of the abnormal node that triggered this rollback, the transaction ID, and the timestamp of the abnormal occurrence; Write the rollback event characteristics containing the above information into the dead letter queue data table.

[0016] As a further improvement to this technical solution, the multiple heterogeneous medical business systems specifically include hospital information systems, laboratory information systems, or medical image storage and transmission systems.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This distributed transaction consistency guarantee method for medical information integration proposes to replace resource locking synchronization with completion time alignment. The transaction coordinator collects the real-time load and network status of each business node, predicts the processing time and transmission time of each node through a time budget model, and solves in reverse the differential sending time that allows all nodes to complete processing almost simultaneously. After receiving the task message, each business node executes its local transaction completely independently and asynchronously without any mutual waiting or locking, eliminating the synchronization blocking caused by resource locking. During peak business periods, the system throughput will not be reduced due to mutual waiting. 2. In this distributed transaction consistency guarantee method for medical information integration, the historical benchmark time parameter in the time budget model can be updated online using the actual processing time collected after each transaction is executed. This enables the prediction model to adapt to the fluctuations in processing performance of each business node due to changes in business load, hardware upgrades or degradation, thereby ensuring the long-term accuracy of the prediction and improving the robustness of the system. 3. In this distributed transaction consistency guarantee method for medical information integration, after sending the task message, the transaction coordinator starts a global timeout monitor bound to the maximum estimated total timeout. If there are business nodes that time out or fail to complete or have execution abnormalities, a rollback instruction is broadcast to all completed nodes, driving them to discard uncommitted data and release lock resources. This ensures that even in extreme cases of prediction failure or node failure, the global transaction still satisfies atomicity, protecting medical data from a dirty state of partial success and partial failure. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the overall process of the present invention. Detailed Implementation

[0019] 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 only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example

[0020] like Figure 1 As shown in the figure, this invention discloses a distributed transaction consistency guarantee method for medical information integration, which is executed by a transaction coordinator and includes the following steps: Receive distributed transaction requests across multiple heterogeneous medical business systems, parse the distributed transaction requests to determine the multiple business nodes participating in the distributed transaction and the task messages to be sent to each business node; Collect the current number of concurrent tasks and the task queue depth of each business node. If the sum of the number of concurrent tasks and the queue depth of any business node exceeds the preset load limit, all task messages will be temporarily stored in the delayed sending queue. Obtain the data size of the task message and measure the network round-trip latency between the transaction coordinator and each business node. Based on the data size and round-trip latency, calculate the predicted transmission time for each task message to reach the corresponding business node. Obtain the historical baseline time for each business node to process similar transactions, and calculate the predicted processing time for each business node by combining the current number of concurrent tasks and the task queue depth of the corresponding business node. For each service node, add its predicted transmission time to its predicted processing time to obtain the estimated total time for that service node, and take the maximum value of the estimated total time of all service nodes as the maximum estimated total time; subtract the estimated total time of each service node from the maximum estimated total time to obtain the corresponding delayed transmission time of each service node. In the delayed transmission queue, a countdown is started according to the delayed transmission duration of each service node. Whenever the delayed transmission duration of a service node reaches zero, its corresponding task message is sent to that service node through the underlying network interface. Once the system receives readiness confirmations from all business nodes indicating that the task message processing is complete, it broadcasts a submit command to all business nodes, causing each business node to release its local database exclusive lock.

[0021] It should be further explained that the distributed transaction consistency guarantee method for medical information integration disclosed in this embodiment of the invention runs in an independently deployed transaction coordinator. The transaction coordinator is deployed on an independent server in the hospital information center and is connected to various medical business systems through the hospital's internal LAN. The multiple heterogeneous medical business systems specifically include a hospital information system, a laboratory information system, and a medical image storage and transmission system. The hospital information system is mainly responsible for patient basic information management, registration, and billing; the laboratory information system is mainly responsible for test application and test result management; and the medical image storage and transmission system is mainly responsible for the storage, transmission, and browsing of medical images. In addition to the aforementioned hospital information system, laboratory information system, and medical image storage and transmission system, this invention is also applicable to other heterogeneous medical business systems such as radiology information systems, surgical anesthesia systems, electronic medical record systems, and physical examination information systems.

[0022] Furthermore, each step of this method is disclosed.

[0023] Considering that there are many transactions in medical operations that need to be completed collaboratively across multiple systems, such as patient admission registration which requires the simultaneous creation of patient files in the hospital information system, test request accounts in the laboratory information system, and image storage catalogs in the medical image storage and transmission system, if these operations cannot guarantee atomicity, some systems may succeed while others fail, leading to data inconsistency and affecting the subsequent medical operations. Therefore, a unified transaction coordinator is needed to receive and process distributed transaction requests across systems. Thus, the first step is proposed, and the specific implementation method is as follows.

[0024] The transaction coordinator receives distributed transaction requests from front-end business systems or other integration platforms via HTTP or HTTPS protocols. These requests are encapsulated in JSON format and include fields such as transaction type, participating system identifiers, and business data. The coordinator parses the participating system identifier field in the request to determine the multiple business nodes participating in the transaction. For example, for a patient admission registration transaction, the participating system identifiers are HIS, LIS, and PACS, corresponding to the hospital information system node, laboratory information system node, and medical image storage and transmission system node, respectively. Then, based on the transaction type and business data, the transaction coordinator generates task messages to be sent to each business node. For example, the task message sent to the hospital information system includes patient name, gender, age, ID number, and hospital number; the task message sent to the laboratory information system includes patient hospital number and test request permissions; and the task message sent to the medical image storage and transmission system includes patient hospital number and image storage directory name. By uniformly receiving and parsing distributed transaction requests, the coordinator can clearly identify the participants in the transaction and the tasks each participant needs to perform, laying the foundation for subsequent transaction coordination. Considering the limited processing capacity of the medical business system, some systems may become overloaded during peak business periods. If task messages are sent to overloaded systems at this time, it will lead to a significant increase in task processing time, or even task timeout failure, which in turn will cause the entire distributed transaction to fail. Therefore, before sending task messages, it is necessary to collect the real-time load status of each business node to determine whether any node is overloaded. If a node is overloaded, all task messages should be temporarily stored and sent after the load decreases to avoid the overall transaction failure caused by the overload of some nodes. Therefore, the second step is proposed, and the specific implementation method is as follows.

[0025] In this embodiment, the transaction coordinator initiates a low-level status probe request to the database connection pool of each business node every 100 milliseconds. The database connection pool is implemented using the open-source Druid connection pool, which provides a RESTful API interface for querying the connection pool status. By calling this interface, the transaction coordinator reads the number of active threads returned by the database connection pool in real time, as the current number of concurrent tasks. The number of active threads refers to the number of threads currently performing database operations, which can accurately reflect the actual processing load of the business node. At the same time, the transaction coordinator reads the number of waiting connection requests on the application layer transport protocol port, as the task queue depth. The application layer transport protocol uses the TCP protocol, and the transaction coordinator queries the number of connections in the SYN_RCVD state on the corresponding port by calling the netstat command provided by the operating system, as the number of waiting connection requests.

[0026] The preset load limit is determined based on the hardware configuration and historical load of each business node. When the sum of the number of concurrent tasks and the queue depth of any business node exceeds the corresponding load limit, the transaction coordinator temporarily stores all task messages in the delayed sending queue. The delayed sending queue is implemented using Redis's ordered set, with each task message as an element and its score being the corresponding delayed sending timestamp.

[0027] By using the above technical means, the real-time load status of business nodes is collected, and task messages are temporarily stored when nodes are overloaded. This can effectively avoid the overall failure of transactions caused by the overload of some nodes and improve the success rate of transactions. At the same time, the use of Redis sorted sets to implement the delayed sending queue can efficiently manage and schedule delayed sending task messages.

[0028] Considering that the transmission time of task messages is one of the important factors affecting the total transaction time, the network conditions between different business nodes and the transaction coordinator are different, and the network conditions of the same business node will also change at different times. If the difference in transmission time is not considered and synchronous transmission is adopted, nodes with good network conditions will receive task messages earlier and start processing, while nodes with poor network conditions will receive task messages later, resulting in a large difference in the completion time of each node and an extension of the lock holding time. Therefore, it is necessary to accurately calculate the predicted transmission time of each task message to provide a basis for subsequent calculation of delayed transmission time. Therefore, the third step is proposed, and the specific implementation method is as follows.

[0029] The transaction coordinator first obtains the number of bytes in each task message as the data size of the task message. Then, every 500 milliseconds, the transaction coordinator sends a 64-byte ICMP echo request packet to each service node to measure the network round-trip time. The transaction coordinator records the round-trip time obtained from the last 10 measurements, forming a round-trip time set within a 5-second time window. Then, the transaction coordinator removes the maximum and minimum values ​​from the round-trip time set and calculates the average round-trip time of the remaining 8 values.

[0030] Next, based on the average round-trip time (RTD) and the maximum transmission unit (MTU) of Ethernet (1500 bytes), the current link bandwidth is estimated. The formula for estimating the link bandwidth is: Bandwidth = (MTU × 8) / (Average RTD / 2), where multiplying by 8 converts bytes to bits, and dividing by 2 converts the RTD to one-way latency. Then, the data size of the task message is divided by the current link bandwidth to obtain the message serialization time. The serialization time refers to the time required to send the task message from the transaction coordinator's memory to the network interface card. Half of the average RTD is taken as the theoretical one-way physical transmission time. Finally, the serialization time is added to the one-way physical transmission time to obtain the predicted transmission time.

[0031] By taking into account the data size of the task message and the network round-trip latency, the predicted transmission time of the task message can be accurately calculated, providing a reliable basis for subsequent calculation of the delayed transmission duration.

[0032] Considering the different processing capabilities of different business nodes, the processing time of the same business node under different loads will also vary greatly. If these differences are not taken into account and synchronous transmission is adopted, nodes with strong processing capabilities and low loads will complete their tasks in advance and hold locks for a long time, while nodes with weak processing capabilities and high loads will complete their tasks late, thus extending the overall lock holding time of the transaction. Therefore, it is necessary to accurately calculate the predicted processing time of each business node to provide a basis for subsequent calculation of delayed transmission duration. Therefore, the fourth step is proposed, and the specific implementation method is as follows.

[0033] The transaction coordinator maintains a historical baseline time table in the local MySQL database, recording the historical baseline time for each business node to process different types of transactions. The historical baseline time is the average time taken by the business node to process the same type of transaction under no-load conditions. For example, the historical baseline time for the hospital information system to process patient admission registration transactions is 200 milliseconds, the historical baseline time for the laboratory information system to process patient admission registration transactions is 150 milliseconds, and the historical baseline time for the medical image storage and transmission system to process patient admission registration transactions is 100 milliseconds.

[0034] Then, combining the current concurrent task count and task queue depth of the corresponding business node, the predicted processing time of each business node is calculated using the following formula: ,in, For business nodes Predicted processing time, For business nodes Historical benchmark time For business nodes The current number of concurrent tasks, For business nodes Task queue depth, For the preset concurrent load weight constant, The pre-defined queuing time penalty constant is used. The value range is from 0.1 to 0.3. In this embodiment... Take 0.2; The value ranges from 5 to 15 milliseconds. In this embodiment... Take 10 milliseconds; and The value was determined by stress testing each business node; during the stress test, the number of concurrent tasks was gradually increased, and the task processing time under different concurrency levels was measured. The result was obtained through linear regression analysis. The value of the task queue depth was determined by keeping the number of concurrent tasks constant and gradually increasing the task queue depth. The task processing time at different queue depths was measured, and the result was obtained through linear regression analysis. The value; for example, when the current concurrent tasks of a hospital information system node are 5 and the task queue depth is 3, its predicted processing time is millisecond.

[0035] By using the above-mentioned technical means, combined with historical benchmark time, current number of concurrent tasks and task queue depth, the predicted processing time of each business node can be accurately calculated, providing a reliable basis for subsequent calculation of delayed transmission time.

[0036] Considering that the traditional two-phase commit protocol uses synchronous sending of task messages, which leads to large differences in the completion time of each business node, nodes with strong processing capabilities and good network conditions will complete the task ahead of time and hold the local database exclusive lock for a long time, which seriously reduces the system's concurrency performance; therefore, a fifth step is proposed, and the specific implementation method is as follows.

[0037] For each service node, its predicted transmission time is added to its predicted processing time to obtain the estimated total time for that service node. For example, the predicted transmission time for the hospital information system node is 50 milliseconds, the predicted processing time is 430 milliseconds, and the estimated total time is 480 milliseconds; the predicted transmission time for the laboratory information system node is 30 milliseconds, the predicted processing time is 300 milliseconds, and the estimated total time is 330 milliseconds; the predicted transmission time for the medical image storage and transmission system node is 40 milliseconds, the predicted processing time is 200 milliseconds, and the estimated total time is 240 milliseconds. Then... The maximum estimated total time among all business nodes is taken as the maximum estimated total time. In this embodiment, the maximum estimated total time is 480 milliseconds. Finally, the estimated total time of each business node is subtracted from the maximum estimated total time to obtain the corresponding delayed transmission time of each business node. For example, the delayed transmission time of the hospital information system node is 480-480=0 milliseconds; the delayed transmission time of the laboratory information system node is 480-330=150 milliseconds; and the delayed transmission time of the medical image storage and transmission system node is 480-240=240 milliseconds.

[0038] By employing the aforementioned technical means and utilizing differentiated delayed sending of task messages, all business nodes can complete task processing almost simultaneously, shortening the overall lock holding time of the transaction and improving the system's concurrent processing capabilities. For example, in this embodiment, if the traditional synchronous sending method is used, the medical image storage and transmission system node will complete the task and hold the lock in 240 milliseconds, and will only release the lock after the hospital information system node completes the task in 480 milliseconds, with a lock holding time of 240 milliseconds. However, using the method of this invention, the medical image storage and transmission system node sends the task message with a 240-millisecond delay, and will complete the task in 480 milliseconds, releasing the lock simultaneously with the hospital information system node, with a lock holding time of only 0 milliseconds, thus shortening the lock holding time.

[0039] Considering that the delayed sending queue is used to manage task messages that need to be sent with a delay, and the countdown is performed according to the delayed sending duration of each business node, it can ensure that the task messages are sent at the accurate time point, thereby achieving the goal of all business nodes completing task processing almost simultaneously. Therefore, a sixth step is proposed, and the specific implementation method is as follows.

[0040] The delayed sending queue is implemented using a Redis sorted set. Each task message is treated as an element, with its score being the current timestamp plus the corresponding delayed sending duration. The transaction coordinator starts a background thread that scans the delayed sending queue every 10 milliseconds, querying elements with a score less than or equal to the current timestamp. When an element that meets the criteria is found, it is removed from the sorted set and the task message is sent to the corresponding business node through the Java NIO underlying network interface.

[0041] By employing the aforementioned technical means and utilizing Redis sorted sets and background scanning threads to implement a delayed sending mechanism, the sending time of task messages can be scheduled efficiently and accurately, ensuring that all business nodes complete task processing almost simultaneously.

[0042] Considering that once all business nodes have completed task processing and returned a ready confirmation, it means that all nodes are ready to commit the transaction, the transaction coordinator broadcasts a commit instruction to all nodes, driving each node to commit its local transaction and release the local database exclusive lock it holds, thereby completing the entire distributed transaction. Therefore, a seventh step is proposed, and the specific implementation method is as follows.

[0043] After sending a task message, the transaction coordinator maintains a transaction status table, recording the participating nodes of each transaction and the return status of each node. When it receives a ready confirmation from a business node, it updates the status of that node to ready. Once the status of all participating nodes is updated to ready, the transaction coordinator broadcasts a commit instruction to all participating nodes. The commit instruction is sent using an HTTP POST request, and the request body contains the global transaction ID. After receiving the commit instruction, each business node commits its local transaction, releases the exclusive lock it holds on the local database, and returns a commit success response to the transaction coordinator. After receiving the commit success responses from all nodes, the transaction coordinator updates the transaction status to committed and cleans up transaction-related temporary data.

[0044] By employing the aforementioned technical means and utilizing the two-phase commit mechanism, the atomicity and consistency of distributed transactions are guaranteed, ensuring that all business nodes either commit all transactions or roll back all transactions.

[0045] Considering that the processing capacity of service nodes can change due to factors such as hardware aging, software upgrades, and variations in traffic volume, if the historical baseline processing time is not updated for a long period, the accuracy of predicted processing time will decrease, thus affecting the accuracy of calculating the delay duration. Therefore, after broadcasting the submission command to all service nodes, a closed-loop correction step for the historical baseline processing time is also included: collecting the actual processing time of each service node from receiving the task message to returning a ready confirmation; calculating the absolute error between the actual processing time and the predicted processing time; and updating the historical baseline processing time with the actual processing time when the absolute error exceeds a preset tolerance threshold. The specific implementation is as follows.

[0046] The transaction coordinator records the timestamp of sending the task message to each business node and the timestamp of receiving the ready acknowledgment from that node. Then, it calculates the actual processing time of the business node. The actual processing time is equal to the timestamp of receiving the ready acknowledgment minus the timestamp of sending the task message minus the predicted transmission time. For example, if the transaction coordinator sends a task message to the hospital information system node at 1000 milliseconds, receives the ready acknowledgment at 1480 milliseconds, and the predicted transmission time is 50 milliseconds, then the actual processing time is 1480 - 1000 - 50 = 430 milliseconds.

[0047] Then, the absolute error between the actual processing time and the predicted processing time is calculated. The preset tolerance threshold is 20% of the historical baseline time. For example, if the historical baseline time for a hospital information system node is 200 milliseconds, the tolerance threshold is 40 milliseconds. If the absolute error is greater than 40 milliseconds, the historical baseline time is updated with the actual processing time. To avoid the impact of a single outlier on the historical baseline time, a moving average method is used for updating, i.e., the new historical baseline time = 0.8 × the original historical baseline time + 0.2 × the actual processing time.

[0048] Through the above technical means, a closed-loop correction mechanism for historical benchmark time has been established, which can continuously improve the accuracy of predicted processing time, further optimize the calculation accuracy of delayed transmission time, enable all business nodes to complete task processing more accurately at the same time, and further shorten the lock holding time.

[0049] Considering that during distributed transaction processing, some business nodes may fail, the network may be interrupted, or the task execution may be abnormal, causing the transaction to fail to complete normally. If a rollback is not performed in time, some business nodes may hold local database exclusive locks for a long time, affecting the execution of other transactions and causing data inconsistency. Therefore, after sending the corresponding task message to the business node through the underlying network interface, a strong consistency rollback step is also included: starting a global timeout monitor associated with the maximum estimated total timeout; if, when the global timeout monitor reaches the preset timeout blocking threshold, there are still business nodes that have not returned ready confirmation, or an execution abnormal response is received from any business node, a global rollback instruction is broadcast to all business nodes that have returned ready confirmation, driving these business nodes to discard their local uncommitted transaction data and release the local database exclusive locks they hold. The specific implementation is as follows.

[0050] After the transaction coordinator sends the task message to all business nodes, it starts a global timeout monitor. The timeout blocking threshold of the global timeout monitor is set to 1.5 times the maximum estimated total timeout. For example, if the maximum estimated total timeout is 480 milliseconds, then the timeout blocking threshold is 720 milliseconds. The global timeout monitor is implemented using Java's ScheduledExecutorService and triggers timeout processing logic when the timeout blocking threshold is reached.

[0051] Before the timeout blocking threshold is reached, if the transaction coordinator receives ready confirmations from all business nodes, it cancels the global timeout monitor. If, when the timeout blocking threshold is reached, any business node still fails to return a ready confirmation, or if an execution exception response is received from any business node at any time, the transaction coordinator immediately broadcasts a global rollback instruction to all business nodes that have returned ready confirmations. The global rollback instruction is sent via an HTTP POST request, with the global transaction ID included in the request body. Upon receiving the global rollback instruction, each business node rolls back its local transaction, discards uncommitted local transaction data, releases the local database exclusive lock it holds, and returns a rollback success response to the transaction coordinator. After receiving the rollback success responses from all nodes that have returned ready confirmations, the transaction coordinator updates the transaction status to rolled back and cleans up transaction-related temporary data.

[0052] By using the above technical means, a global timeout monitor associated with the maximum estimated total timeout can be set up to trigger a global rollback in a timely manner when a transaction times out or an anomaly occurs, ensuring the consistency of transactions and avoiding the situation where some business nodes hold locks for a long time, thereby improving the system's concurrency performance.

[0053] Considering that medical transaction requests typically contain a large number of medical image attachments and unstructured text attachments, which have a very large data volume (e.g., a single CT image can reach tens of megabytes), packaging and transmitting these attachments with structured business data would result in an excessively large task message data volume, prolonged transmission time, and consequently increased lock holding time and the risk of transaction failure. Therefore, after receiving distributed transaction requests across multiple heterogeneous medical business systems, the process further includes: unpacking the distributed transaction request and extracting the structured field forms of the medical business data; stripping the medical image attachments and unstructured text attachments from the request; and serializing the structured field forms into a lightweight message with a fixed format, which is then used as the task message in subsequent temporary storage steps. The specific implementation is as follows.

[0054] After receiving a distributed transaction request, the transaction coordinator unpacks the request. The request is encapsulated in multipart / form-data format, containing a structured data portion and multiple attachment portions. The transaction coordinator extracts the structured data portion to obtain the medical business structured field form. Then, it removes the medical image attachments and unstructured text attachments from the request, stores these attachments in the hospital's HDFS distributed file system, and generates corresponding attachment access URLs. Finally, the structured field form is serialized into a lightweight JSON message, and the attachment access URLs are added to the structured field form to form the final task message. For example, for a patient examination request transaction containing a CT image, the task message only contains patient information, examination item information, and the CT image access URL. The CT image file itself is stored in HDFS and downloaded by business nodes via the access URL when needed.

[0055] By using the above technical means, the structured field form and attachments are separated, and only the lightweight structured field form is transmitted as a task message, which reduces the data volume of the task message, shortens the transmission time, and further reduces the lock holding time; at the same time, attachments are stored and transmitted through a dedicated distributed file system, which improves the reliability and efficiency of attachment transmission.

[0056] Considering that in distributed systems, due to network instability and other reasons, task messages may be sent repeatedly, if business nodes repeatedly process the same task message, it will lead to duplicate data insertion or updates, causing data inconsistency. At the same time, in concurrent scenarios, multiple transactions may modify the same data simultaneously, which will lead to data conflicts if concurrency control is not implemented. Therefore, when sending the corresponding task message to the business node through the underlying network interface, the following is also included: injecting a globally unique transaction ID and version number timestamp into the request header of each task message; triggering each business node to perform idempotency verification using the transaction ID when receiving the task message, and performing optimistic locking comparison on the local data table using the version number timestamp. The specific implementation is as follows.

[0057] Before sending a task message, the transaction coordinator generates a globally unique transaction ID and a version timestamp. The transaction ID is generated using the UUID algorithm to ensure global uniqueness, and the version timestamp uses the current system time in milliseconds. Then, the transaction ID and version timestamp are injected into the HTTP request header of the task message, with the request header fields being X-Transaction-ID and X-Version-Timestamp, respectively.

[0058] When each business node receives a task message, it first extracts the transaction ID from the request header and checks if a corresponding transaction record exists in its local database. If it does, the task message has already been processed, and a ready confirmation is returned directly. If it does not exist, the task message is processed. Then, the business node extracts the version number timestamp from the request header and compares it with the version field of the corresponding record in its local database. If the version number timestamp is greater than or equal to the version field value of the local record, data updates are allowed, and the version field value of the local record is updated to the version number timestamp. If the version number timestamp is less than the version field value of the local record, the task message is expired, data updates are refused, and an execution exception response is returned.

[0059] By injecting a globally unique transaction ID and version timestamp into the task message header, idempotency of transactions and optimistic locking concurrency control are achieved, avoiding duplicate commits and data conflicts, and ensuring data consistency.

[0060] Considering that recording relevant information about rollback events can provide a basis for subsequent troubleshooting and system optimization, the dead-letter queue data table is used to store transaction events that cannot be processed normally, facilitating manual intervention and handling by operations and maintenance personnel. Therefore, after broadcasting the global rollback instruction to all business nodes that have returned ready confirmation, it also includes: recording the abnormal node identifier, transaction ID, and abnormal occurrence timestamp that triggered this rollback; writing the rollback event characteristics containing the above information into the dead-letter queue data table, as specifically implemented below.

[0061] After triggering a global rollback, the transaction coordinator records the identifier of the abnormal node that triggered the rollback, the global transaction ID, and the timestamp of the abnormal occurrence. If the rollback is caused by a business node returning an abnormal response, detailed information about the abnormal response also needs to be recorded. Then, this information is written to the dead-letter queue data table, which is stored in a MySQL database and includes fields such as the abnormal node identifier, transaction ID, timestamp of the abnormal occurrence, abnormal type, and abnormal details. Operations personnel can query the dead-letter queue data table regularly every day to manually handle abnormal transactions, such as resubmitting transactions or troubleshooting node failures.

[0062] By using the above technical means, the characteristics of rollback events are recorded and written into the dead letter queue data table, providing a basis for subsequent troubleshooting and system optimization, and improving the maintainability of the system.

[0063] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A distributed transaction consistency guarantee method for medical information integration, characterized in that, Executed by the transaction coordinator, characterized by including the following steps: Receive distributed transaction requests across multiple heterogeneous medical business systems, parse the distributed transaction requests to determine multiple business nodes participating in the distributed transaction and the task messages to be sent to each business node; Collect the current number of concurrent tasks and the task queue depth of each business node. If the sum of the number of concurrent tasks and the queue depth of any business node exceeds the preset load limit, then all the task messages will be temporarily stored in the delayed sending queue. The data size of the task message is obtained, and the network round-trip delay between the transaction coordinator and each service node is measured. Based on the data size and the round-trip delay, the predicted transmission time of each task message to the corresponding service node is calculated. Obtain the historical baseline time for each business node to process similar transactions, and calculate the predicted processing time for each business node by combining the current number of concurrent tasks and the task queue depth of the corresponding business node. For each service node, its predicted transmission time is added to its predicted processing time to obtain the estimated total time of the service node, and the maximum value of the estimated total time of all service nodes is taken as the maximum estimated total time. The estimated total time of each service node is subtracted from the maximum estimated total time to obtain the delayed transmission time corresponding to each service node. In the delayed transmission queue, a countdown is started according to the delayed transmission duration of each service node. Whenever the delayed transmission duration of a service node reaches zero, its corresponding task message is sent to that service node through the underlying network interface. Once a ready confirmation is received from all business nodes indicating that the task message has been processed, a submit instruction is broadcast to all business nodes, driving each business node to release its local database exclusive lock.

2. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, The predicted processing time for each business node is calculated by combining the current concurrent task count and task queue depth of the corresponding business node, using the following method: ,in, For business nodes Predicted processing time, For business nodes Historical benchmark time For business nodes The current number of concurrent tasks, For business nodes Task queue depth, For the preset concurrent load weight constant, This is a preset queuing time penalty constant.

3. The distributed transaction consistency guarantee method for medical information integration according to claim 2, characterized in that, After broadcasting the submission instruction to all service nodes, the process also includes a closed-loop correction step for the historical benchmark time: Collect the actual processing time of each business node from receiving the task message to returning a ready confirmation; Calculate the absolute error between the actual processing time and the predicted processing time; When the absolute error exceeds a preset tolerance threshold, the historical benchmark time is updated using the actual processing time. .

4. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, The step of calculating the predicted transmission time for each task message to reach the corresponding service node based on the data volume and the round-trip delay includes: Extract the set of round-trip delays of network links within a preset time window, remove extreme values, and then calculate the average round-trip delay. Estimate the current link bandwidth based on the average round-trip time and the maximum transmission unit of the underlying network protocol; Divide the data size of the task message by the current link bandwidth to obtain the message serialization and transmission time; Half of the average round-trip time is taken as the theoretical one-way physical transmission time; The predicted transmission time is obtained by adding the serialization transmission time to the one-way physical transmission time.

5. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, After sending the corresponding task message to the service node through the underlying network interface, a strong consistency rollback step is also included: Start a global timeout monitor associated with the maximum estimated total timeout; If, when the global timeout monitor reaches the preset timeout blocking threshold, there are still business nodes that have not returned a ready confirmation, or an execution exception response is received from any business node, a global rollback instruction is broadcast to all business nodes that have returned ready confirmation, driving these business nodes to discard their local uncommitted transaction data and release the local database exclusive locks they occupy.

6. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, After receiving distributed transaction requests across multiple heterogeneous medical business systems, the process further includes: The distributed transaction request is unpacked, and the structured field form for medical business is extracted from it; Remove the medical image attachments and unstructured text attachments contained in the request; The structured field form is serialized into a lightweight message with a fixed format, and this message is used as the task message in the subsequent temporary storage step.

7. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, When sending the corresponding task message to the service node through the underlying network interface, the method further includes: Inject a globally unique transaction ID and version number timestamp into the request header of each task message; When each business node receives a task message, it is triggered to perform idempotency verification using the transaction ID and to perform optimistic locking comparison on the local data table using the version number timestamp.

8. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, The collection of the current concurrent task count and task queue depth of each business node includes: Initiate underlying status probe requests to the database connection pools of each business node; The number of active threads returned by the database connection pool is read in real time and used as the current number of concurrent tasks; The number of waiting connection requests on the application layer transport protocol port is read and used as the task queue depth.

9. The distributed transaction consistency guarantee method for medical information integration according to claim 5, characterized in that, After broadcasting the global rollback command to all service nodes that have returned ready confirmation, the process also includes: Record the identifier of the abnormal node that triggered this rollback, the transaction ID, and the timestamp of the abnormal occurrence; Write the rollback event characteristics containing the above information into the dead letter queue data table.

10. The distributed transaction consistency guarantee method for medical information integration according to claim 1, characterized in that, The aforementioned heterogeneous medical business systems specifically include hospital information systems, laboratory information systems, or medical image storage and transmission systems.

Images