A multi-branch enterprise saas physical examination data distributed storage and collaboration method and electronic equipment

Abstract

This application discloses a distributed storage and collaboration method and electronic device for SaaS health checkup data in multi-branch enterprises. The method includes: allocating initial physical nodes using tenant identifier mapping; when the monitoring load index exceeds a preset threshold, introducing employee identifiers to generate composite hash keys, and performing hotspot node splitting and migration; pulling historical health checkup data from the central cloud database cluster to the edge cache node group in descending order based on preheating priority scores; establishing independent consensus groups for each tenant, with edge cache nodes acting as learners sending logs to the central master node, initiating a majority synchronization to complete data persistence. This application can reduce extreme concurrent load fluctuations in cloud databases, address heat dissipation points through adaptive sharding, accelerate cross-domain historical archive retrieval, and decouple data consistency blocking in multi-tenant isolation scenarios.

Description

Technical Field

[0001] This application relates to the fields of distributed database services and Internet data processing, and is subject to priority examination classification number G06F16 / 27. Specifically, it refers to a method and electronic device for distributed storage and collaboration of SaaS health check data for multi-branch enterprises. Background Technology

[0002] Large, multi-regional enterprise groups face immense pressure from massive concurrent writes and cross-domain reads during centralized system maintenance periods. Traditional SaaS multi-tenant databases employ consistent hashing sharding, which can easily lead to high-concurrency requests falling onto the same physical shard node, causing severe storage skew and disk bottlenecks, potentially triggering cluster avalanches. Existing general content delivery networks or full synchronization solutions do not consider the time-series characteristics of maintenance business, resulting in invalid data occupying edge node storage resources and high latency in cross-domain retrieval of critical historical files. Furthermore, global transaction control significantly reduces concurrency performance while ensuring strong multi-tenant isolation. Therefore, there is an urgent need for an adaptive heat dissipation and cross-domain collaborative storage and synchronization mechanism to ensure data reliability and consistency under high concurrency. Summary of the Invention

[0003] This application provides a distributed storage and collaboration method and electronic device for SaaS health check data of multi-branch enterprises, which is used to solve the database hotspot bottleneck problem caused by data skew during the centralized health check period of existing SaaS platforms, as well as the problems of high latency in cross-regional historical file retrieval and global transaction blocking.

[0004] This application provides a distributed storage and collaboration method for SaaS physical examination data in multi-branch enterprises, applied to a system including a central cloud database cluster and an edge cache node group. The method includes: allocating initial physical nodes for access requests using a mapping rule with tenant identity identifiers as keys; monitoring the load index of each initial physical node, and when the load index exceeds a preset threshold, introducing employee identity identifiers to generate composite hash keys, splitting data from hot nodes and migrating it to low-load physical nodes; generating a preheating priority score based on the remaining time of the target physical examination, the size of historical records, and the health risk coefficient, and pulling historical physical examination data from the central cloud database cluster to the edge cache node group in descending order of the preheating priority score; establishing an independent consensus group for each tenant, and when new data is generated, the edge cache node acting as a learner sends log entries to the corresponding tenant's central cloud master node, and the central cloud master node completes data persistence after initiating a majority synchronization.

[0005] Furthermore, the load index includes read / write load index and storage load index; monitor the load index of each initial physical node, and when the load index exceeds a preset threshold, introduce employee identity identifiers to generate a composite hash key, split the data of hot nodes and migrate it to low-load physical nodes, including: periodically collecting the query rate per second and disk utilization of each initial physical node; calculating the read / write load index based on the query rate per second and the storage load index based on the disk utilization; when the weighted sum of the read / write load index and the storage load index exceeds a preset threshold for multiple consecutive collection periods, the corresponding initial physical node is marked as a hot node; extract the data access records within the hot node, combine the tenant identity identifier and the employee identity identifier to calculate a composite hash key using a hash function, and reroute the data within the hot node to low-load physical nodes based on the composite hash key.

[0006] Furthermore, a composite hash key is calculated by combining the tenant identity and employee identity using a hash function. Based on this composite hash key, data within hot nodes is rerouted to low-load physical nodes. This process includes: performing a first hash operation on the tenant identity to obtain a first hash value, and performing a second hash operation on the employee identity to obtain a second hash value; concatenating the high-order byte of the first hash value with the low-order byte of the second hash value to obtain an initial composite key; perturbing the initial composite key to eliminate hash collisions to obtain the final composite hash key; establishing a global routing table in the central cloud database cluster to map and bind the composite hash key to the network addresses of low-load physical nodes; during data splitting, write operations on hot nodes are redirected to a memory buffer. After the existing data is migrated to low-load physical nodes based on the composite hash key, the incremental data in the memory buffer is appended to the low-load physical nodes, and the global routing table is updated.

[0007] Furthermore, a pre-examination priority score is generated based on the remaining time of the target physical examination, the size of historical records, and the health risk coefficient. This includes: obtaining the appointment sequence list and extracting the difference between the current time and the scheduled physical examination time from the appointment sequence list as the remaining time of the target physical examination; querying the number of bytes of the historical physical examination files to be retrieved as the size of the historical records; reading the examinee's historical disease records, matching the corresponding basic risk value according to the set risk grading rules, and using the basic risk value as the health risk coefficient; taking the reciprocal of the remaining time of the target physical examination to obtain the time urgency; and multiplying the time urgency, the size of historical records, and the health risk coefficient by the corresponding preset weight coefficients and summing them to obtain the pre-examination priority score.

[0008] Furthermore, historical health check data is retrieved from the central cloud database cluster to the edge cache node group in descending order of preheating priority score. This includes: constructing a priority blocking queue in the edge cache node group and pushing the calculated preheating priority score along with the corresponding data retrieval task into the priority blocking queue; when multiple data retrieval tasks have the same preheating priority score, extracting the historical file size corresponding to the data retrieval task and placing the data retrieval task with the smaller historical file size at the front of the priority blocking queue; monitoring the downlink network bandwidth utilization of the edge cache node group, and when the downlink network bandwidth utilization is lower than the bandwidth threshold, the worker thread retrieves the highest priority data retrieval task from the head of the priority blocking queue; parsing the storage addressing path in the data retrieval task, sending a block read request to the central cloud database cluster through the LAN direct connection channel, receiving the returned historical health check data and storing it in the local solid-state drive, while marking the data retrieval task as completed.

[0009] Furthermore, an independent consensus group is established for each tenant. When new data is generated, the edge cache nodes acting as learners send log entries to the corresponding tenant's central cloud master node. This includes: logically isolating the data space based on the tenant's identity in the underlying data structure; configuring state machines for database nodes of the same tenant distributed in different regions within the isolated data space; electing a unique central cloud master node for each consensus group in the central cloud database cluster through an election protocol; registering the edge cache node groups deployed in various enterprises as learners without voting rights; and when the medical examination device generates new data and writes it to the edge cache node group, encapsulating the new data into log entries, with the log entries carrying the tenant's identity, and sending them to the central cloud master node via a secure encrypted channel.

[0010] Furthermore, after the central cloud master node initiates a majority synchronization, it completes data persistence, including: upon receiving a log entry, the central cloud master node verifies whether the tenant identity identifier in the log entry matches the consensus group it is responsible for. If the match fails, it refuses to process the entry and returns an error signal; if the match is successful, the central cloud master node appends the log entry to its local write-ahead log and broadcasts the append request to other slave nodes belonging to the same tenant consensus group; after receiving append success confirmation signals from more than half of the slave nodes, the central cloud master node marks the log entry as committed and applies it to its local state machine to complete data persistence; the central cloud master node asynchronously sends a commit notification to the edge cache nodes acting as learners, and the edge cache nodes update their local read views according to the commit notification.

[0011] Furthermore, the method provided in this application also includes: real-time monitoring of the available storage capacity of the edge cache node group, triggering a cache eviction mechanism when the available storage capacity is lower than a set safety water level; scanning all historical physical examination data stored locally, extracting the last access timestamp and the corresponding physical examination business completion status of each historical physical examination data; prioritizing the selection of historical physical examination data with a completed physical examination business status and deleting and releasing storage space; if the released storage space is lower than the safety water level, eviction of the historical physical examination data that has not been accessed for the longest time based on the last access timestamp.

[0012] Furthermore, the method provided in this application also includes: when the network connection between the edge cache node (which is in the role of a learner) and the central cloud master node is interrupted, the newly generated data is recorded in the local retransmission log file, and the exponential backoff retry logic is initiated to detect the network status; after the network connection is detected to be restored, the edge cache node reads the offset record in the retransmission log file and sends a synchronization request containing the offset record to the central cloud master node; the central cloud master node compares its own commit index with the offset record and packages and transmits the missing incremental data back.

[0013] This application also provides an electronic device, including a memory and a processor. The memory is used to store a computer program; the processor is communicatively connected to the memory; when the processor executes the computer program, it implements the SaaS-based distributed storage and collaboration method for health checkup data of multi-branch enterprises, as described above. Attached Figure Description

[0014] Figure 1 A flowchart illustrating the distributed storage and collaboration method for SaaS health checkup data of multi-branch enterprises provided in an embodiment of this application is shown.

[0015] Figure 2 The diagram illustrates the logical structure of a distributed storage and collaboration system for SaaS-based health checkup data of multi-branch enterprises provided in this application embodiment. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of this application, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] Figure 1 A flowchart illustrating a distributed storage and collaboration method for SaaS health checkup data of multi-branch enterprises provided in an embodiment of this application is shown. This method is applied to a system comprising a central cloud database cluster and an edge cache node group.

[0018] The following reference Figure 2 The system described in the embodiments of this application will be illustrated. For example... Figure 2As shown, this embodiment provides a distributed storage and collaboration system for SaaS-based health checkup data in multi-branch enterprises. The underlying logical structure of this system includes a central cloud database cluster 201, a multi-tenant business middleware 202, and an edge cache node group 203 deployed at the locations of each branch office. A communication interface component 204 is configured between the central cloud database cluster 201 and the edge cache node group 203. The communication interface component 204 is used for cross-WAN remote procedure call data interaction between cloud physical nodes and edge cache nodes. The central cloud database cluster 201 has an embedded background monitoring thread and is configured with a scheduled task trigger scheduler 205. The scheduled task trigger scheduler 205 is used to maintain the load calculation heartbeat within a time window to periodically drive the load monitoring and shard status update logic. The multi-tenant business middleware 202 receives health checkup data requests generated by the SaaS platform and coordinates the writing and scheduling of data. The edge cache node group 203 uses a local Redis database or a distributed edge storage cluster as the storage medium, possessing high data read / write bandwidth to meet the low-latency data access requirements of the health checkup site.

[0019] Continue to refer to Figure 1 The method mainly includes the following steps S101 to S104.

[0020] Step S101: Assign an initial physical node to the access request using a mapping rule with the tenant identity identifier as the key value.

[0021] The central cloud database cluster 201 receives health checkup data requests from the SaaS platform and maps the data to physical storage nodes through an adaptive sharding layer. The basic sharding key is set as the tenant identity identifier, denoted as Tenant. ID In the initial deployment state, the system allocates N virtual nodes and uses a static hash mapping formula for addressing calculation. A standard cryptographic hash algorithm is used to hash the input tenant identity, converting the variable-length identifier into a fixed-length hash value. Then, a modulo operation is performed on the total number of allocated virtual nodes to ensure that the generated index number falls within the valid address space, thus obtaining the virtual node index number. The specific static hash mapping operation is shown in the following formula:

[0022] (1)

[0023] In this formula, V index This represents the virtual node index number obtained from the mapping calculation. The function uses a standard cryptographic hash algorithm to hash the input Tenant. IDHash calculation is performed. After calculating the virtual node index, the system maps these virtual nodes evenly to the M physical nodes under the system according to the mapping table. By adopting this initial mapping rule based on tenant identity, it ensures that the physical examination data of the same enterprise is centrally stored in a specific physical node domain, reducing the complexity of cross-tenant joint queries and laying the foundation for data isolation.

[0024] Step S102: Monitor the load index of each initial physical node. When the load index exceeds the preset threshold, introduce the employee identity identifier to generate a composite hash key, split the data of the hot node and migrate it to the low-load physical node.

[0025] To address severe data skew, the background monitoring thread embedded in the adaptive sharding layer is driven by a scheduled task triggering scheduler 205, performing high-frequency status probing. The monitoring thread periodically collects the query rate per second and disk usage of each initial physical node. Based on the collected query rate per second, a read / write load index is calculated; based on disk usage, a storage load index is calculated. The system calculates the comprehensive load index for each virtual node within a time window period. Let the time window T be... win The span is 5 minutes, and the virtual node V is quantified using a weighted summation method. i The comprehensive load index L(V) i The specific evaluation formula is shown below:

[0026] (2)

[0027] Among them, QPS i Represents virtual node V i The number of actual read / write requests during the current collection period; QPS max This represents the theoretical maximum number of read / write requests that the node can handle; S i This indicates the number of bytes of storage currently occupied by the virtual node; S threshold This indicates the set storage capacity alarm threshold. and These are system-preset weighting coefficients used to balance the proportion of read / write pressure and storage pressure in the overall evaluation. The calculated comprehensive load index L(V) i () is a dimensionless floating-point number between 0 and 1.

[0028] When the weighted sum of the read / write load index and the storage load index exceeds a preset threshold for multiple consecutive sampling cycles, the corresponding initial physical node is marked as a hotspot node. When the load index L(V) is detected for three consecutive cycles... iWhen the hash value is greater than 0.85, an adaptive hotspot splitting mechanism is triggered. This splitting mechanism expands the original single hash key into a composite hash key, forcibly introducing the employee identity identifier as a secondary sharding dimension into the data under this virtual node. The employee identity identifier is denoted as User. ID Extract data access records from hotspot nodes, combine tenant and employee identifiers, and calculate a composite hash key using a hash function. Perform independent hashing on the employee identifier, then XOR the result with the tenant identifier. Finally, generate the final hash value using an outer hash function and modulo the expanded total node capacity. The specific splitting calculation rules are shown in the following formula:

[0029] (3)

[0030] In this formula, V new This represents the index of the new virtual node calculated after the split expansion. N expanded This represents the total capacity of the expanded virtual nodes. During computation, an independent hash processing is performed on the employee identity identifier, and the result is then XORed bitwise with the tenant identity identifier. The hash function performs a series of operations, ultimately generating the final hash value through an outer hash function. During this process, a first hash operation is performed on the tenant's identity to obtain a first hash value, and a second hash operation is performed on the employee's identity to obtain a second hash value. The high-order byte of the first hash value is then concatenated bit-by-bit with the low-order byte of the second hash value to obtain the initial composite key. Subsequently, the initial composite key is perturbed by a bitwise XOR operation to obtain a highly discrete composite hash key.

[0031] Based on the composite hash key, data within hot nodes is rerouted to the least loaded physical node in the cluster. A global routing table is established in the central cloud database cluster 201, mapping and binding the newly generated composite hash key to the network address of the low-load physical node. During data splitting and physical migration, write operations targeting the hot node are intercepted and redirected to a dedicated memory buffer. After the existing data blocks are physically migrated to the low-load physical node based on the composite hash key, the incremental data temporarily stored in the memory buffer is sequentially appended to the low-load physical node, and the global routing table is updated.

[0032] Step S103: Generate a preheating priority score based on the remaining time of the target physical examination, the size of historical records, and the health risk coefficient. Pull historical physical examination data from the central cloud database cluster 201 to the edge cache node cluster 203 in descending order of the preheating priority score.

[0033] In this system, the edge cache nodes in edge cache node group 203 obtain appointment instructions in advance by subscribing to the data stream of multi-tenant business middleware 202. Multi-tenant business middleware 202 maintains a medical examination appointment sequence table for employees. When a new appointment record is detected, the appointment tuple is extracted, and the target edge cache node providing the medical examination service is precisely determined based on the location identifier in the tuple. The target edge node executes the preheating priority evaluation logic. It retrieves the appointment sequence table and extracts the difference between the current system time and the scheduled medical examination time from the appointment sequence table as the remaining time for the target medical examination, denoted as . The unit is hours. The number of bytes in the historical medical examination files to be retrieved is used as the historical archive size, denoted as Size. history The system reads the examinee's historical medical records, matches the corresponding baseline risk value according to the set risk grading rules, and uses the baseline risk value as the health risk coefficient, denoted as C. health The urgency level is calculated by adding a small constant to the remaining time for the target physical examination and then taking the reciprocal. The logarithm of the historical file size is then calculated by adding one. Finally, the urgency level, the smoothed historical file size, and the health risk coefficient are multiplied by their respective preset weighting coefficients and summed. This summation assigns a priority score to each appointment task, denoted as the Score. The specific scoring logic is shown in the following formula:

[0034] (4)

[0035] In this evaluation formula, , , These are the preset evaluation weight coefficients. To prevent the use of tiny constants with a denominator of zero. Health risk coefficient C health A discrete quantization mechanism is adopted: if an employee's historical file contains an abnormal critical illness marker, its value is set to 1; otherwise, it is set to 0.

[0036] After calculation, edge nodes are queued in descending order of priority score and enter the task queue. A priority blocking queue is built in edge cache node group 203, and the calculated warm-up priority score along with the corresponding data retrieval task is pushed into the priority blocking queue. When multiple data retrieval tasks have the same warm-up priority score, the size of the historical file corresponding to the data retrieval task is extracted. Data retrieval tasks with smaller historical file sizes are placed at the front of the priority blocking queue. Edge nodes monitor their own network downlink available bandwidth utilization in real time. When the downlink network bandwidth utilization is lower than the set bandwidth threshold, the worker thread retrieves the highest priority data retrieval task from the head of the priority blocking queue. The worker thread parses the storage addressing path in the data retrieval task, sends a block read request to the central cloud database cluster 201 through the LAN direct connection channel, receives the returned historical health check data and loads it into the local solid-state drive or local Redis database, and marks the data retrieval task as completed.

[0037] Step S104: Establish an independent consensus group for each tenant. When new data is generated, the edge cache node in the learner role sends the log entries to the central cloud master node of the corresponding tenant. After the central cloud master node initiates a majority synchronization, the data is written to disk.

[0038] In the underlying data structure, data spaces are isolated based on tenant identity. Within these isolated data spaces, independent state machine instances are configured for database nodes of the same tenant distributed across different regions. A unique central cloud master node is elected for each independent consensus group within the central cloud database cluster 201 via an election protocol. The remaining physical nodes within the central cloud cluster act as follower nodes. Edge cache nodes deployed across various enterprises, such as those undergoing preheating or data uploads, are registered as learner roles without voting rights. Learner roles passively receive data synchronization and do not participate in the master election vote within the consensus group.

[0039] When the medical examination equipment generates new data and writes it to the edge cache node cluster 203, the edge cache node encapsulates the new data into a log entry, with the corresponding tenant identity identifier attached to the log entry. This log entry is then sent to the central cloud master node corresponding to the tenant via a secure encrypted channel and a remote procedure call protocol.

[0040] Upon receiving a log entry, the central cloud master node verifies whether the tenant identity in the log entry matches the identity of the consensus group it currently manages. If the match fails, it refuses to process the entry and returns an error signal to the edge nodes. If the match is successful, the central cloud master node appends the log entry to the write-ahead log on its local hard drive and broadcasts the append request to other follower slave nodes belonging to the same tenant consensus group. After receiving append success confirmation signals from more than half of the slave nodes, the central cloud master node marks the log entry as committed and applies it to its local state machine to complete the data write-to-disk process. After the write-to-disk process is complete, the central cloud master node asynchronously sends a commit notification to the edge cache node that initiated the request and is in the learner role. The edge cache node updates its local read view pointer based on the received commit notification.

[0041] To maintain the storage health of the edge cache node group 203 during long-term operation, this embodiment also includes cache eviction logic. A background daemon monitors the available storage capacity of the edge cache node group 203 in real time. When the available storage capacity falls below a set safety threshold, the cache eviction mechanism is triggered. All historical medical examination data blocks in local storage are scanned, and the last access timestamp of each piece of historical medical examination data in the file system is extracted. The corresponding medical examination service completion status is then queried from the multi-tenant business middleware 202 via an interface. During the eviction execution phase, historical medical examination data with a completed service status are prioritized and deleted from the solid-state drive to free up storage space. If the remaining storage space after release is still below the safety threshold, the action of eviction of the least accessed historical medical examination data is executed based on the last access timestamp.

[0042] In one optional implementation, the system is configured with an offset retransmission mechanism to address potential network conditions encountered during cross-WAN transmission between the edge and central cloud endpoints. When the network connection between the edge cache node (acting as a learner) and the central cloud master node is interrupted, the edge cache node records the newly generated data in its local retransmission log file. Simultaneously, the edge cache node's network probing module initiates exponential backoff retry logic to probe the network status. Upon detecting that the network connection has been restored, the edge cache node reads the offset record from its local retransmission log file and sends a data synchronization request containing the current offset record to the central cloud master node. Upon receiving the request, the central cloud master node compares its own commit index with the offset record, calculates the difference range, packages the missing incremental data from the edge node, and transmits it back.

[0043] This embodiment also provides an electronic device for use as a central cloud physical server or an edge cache computing terminal. The electronic device includes a memory and a processor that are communicatively connected. The memory uses a non-volatile storage medium to store executable computer program code. The processor includes a central processing unit that, when executing the computer program stored in the memory, implements the SaaS-based distributed storage and collaboration method for health checkup data of multi-branch enterprises as detailed in the foregoing embodiments.

[0044] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0045] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the claims may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A distributed storage and collaboration method for SaaS health check data of multi-branch enterprises, applied to a system including a central cloud database cluster and an edge cache node group, characterized in that, include: An initial physical node is assigned to access requests using a mapping rule that uses the tenant's identity as the key. Monitor the load index of each initial physical node. When the load index exceeds a preset threshold, introduce employee identification to generate a composite hash key, split the data of the hot node and migrate it to the low-load physical node. Based on the remaining time of the target physical examination, the size of historical records, and the health risk coefficient, a preheating priority score is generated, and historical physical examination data is pulled from the central cloud database cluster to the edge cache node group in descending order of the preheating priority score. Each tenant establishes an independent consensus group. When new data is generated, the edge cache node in the learner role sends the log entries to the corresponding tenant's central cloud master node. The central cloud master node then initiates a majority synchronization to complete the data persistence.

2. The method as described in claim 1, characterized in that, The load index includes read / write load index and storage load index. Monitoring the load index of each initial physical node, when the load index exceeds a preset threshold, involves using employee identification to generate a composite hash key, splitting the data from hot nodes, and migrating it to low-load physical nodes, including: The query rate per second and disk utilization of each initial physical node are periodically collected; the read / write load index is calculated based on the query rate per second, and the storage load index is calculated based on the disk utilization; when the weighted sum of the read / write load index and the storage load index exceeds the preset threshold for multiple consecutive collection periods, the corresponding initial physical node is marked as a hot spot node; data access records within the hot spot node are extracted, and a composite hash key is calculated using a hash function in combination with the tenant identity identifier and the employee identity identifier; the data within the hot spot node is then rerouted to the low-load physical node based on the composite hash key.

3. The method as described in claim 2, characterized in that, The step of calculating the composite hash key by combining the tenant identity and the employee identity using a hash function, and then rerouting the data in the hot spot node to the low-load physical node based on the composite hash key, includes: A first hash operation is performed on the tenant identity identifier to obtain a first hash value, and a second hash operation is performed on the employee identity identifier to obtain a second hash value; the high-order byte of the first hash value is concatenated with the low-order byte of the second hash value to obtain an initial composite key; the initial composite key is perturbed to obtain the composite hash key; a global routing table is established in the central cloud database cluster (201), and the composite hash key is mapped and bound to the network address of the low-load physical node; during data splitting, the write operations of the hot node are redirected to the memory buffer, and after the existing data is migrated to the low-load physical node according to the composite hash key, the incremental data in the memory buffer is appended to the low-load physical node, and the global routing table is updated.

4. The method as described in claim 1, characterized in that, The pre-examination priority score is generated based on the remaining time for the target physical examination, the size of historical records, and the health risk coefficient, including: Obtain the appointment sequence list, extract the difference between the current time and the scheduled physical examination time from the appointment sequence list as the remaining time for the target physical examination; query the number of bytes of the historical physical examination files to be retrieved as the size of the historical files; read the historical disease records of the examinees, match the corresponding basic risk value according to the set risk grading rules, and use the basic risk value as the health risk coefficient; calculate the reciprocal of the remaining time for the target physical examination to obtain the time urgency; multiply the time urgency, the size of the historical files, and the health risk coefficient by the corresponding preset weight coefficients and sum them to obtain the preheating priority score.

5. The method as described in claim 4, characterized in that, The step of pulling historical physical examination data from the central cloud database cluster to the edge cache node group in descending order of the preheating priority score includes: A priority blocking queue is constructed in the edge cache node group. The calculated preheating priority score, along with the corresponding data retrieval task, is pushed into the priority blocking queue. When multiple data retrieval tasks have the same preheating priority score, the historical file size corresponding to the data retrieval task is extracted, and the data retrieval task with the smaller historical file size is placed at the front of the priority blocking queue. The downlink network bandwidth utilization of the edge cache node group is monitored. When the downlink network bandwidth utilization is lower than the bandwidth threshold, the worker thread retrieves the highest priority data retrieval task from the head of the priority blocking queue. The storage addressing path in the data retrieval task is parsed, and a block read request is sent to the central cloud database cluster through the LAN direct connection channel. The returned historical health check data is received and stored in the local solid-state drive, and the data retrieval task is marked as completed.

6. The method as described in claim 1, characterized in that, The process involves establishing an independent consensus group for each tenant. When new data is generated, the edge cache nodes acting as learners send log entries to the corresponding tenant's central cloud master node, including: In the underlying data structure, the data space is logically isolated according to the tenant identity identifier. Within the isolated data space, a state machine is configured for database nodes of the same tenant distributed in different regions. A unique central cloud master node is elected for each consensus group in the central cloud database cluster through an election protocol. The edge cache node groups deployed in each enterprise are registered as learner roles without voting rights. When the physical examination device generates new data and writes it to the edge cache node group, the new data is encapsulated into the log entry. The log entry carries the tenant identity identifier and is sent to the central cloud master node via a secure encrypted channel.

7. The method as described in claim 6, characterized in that, After the central cloud master node initiates a majority synchronization, it completes data persistence to disk, including: After receiving the log entry, the central cloud master node verifies whether the tenant identity identifier in the log entry matches the consensus group it is responsible for. If the match fails, it refuses to process the entry and returns an error signal. If the match is successful, the central cloud master node appends the log entry to its local write-ahead log and broadcasts the append request to other slave nodes belonging to the same tenant's consensus group. After receiving append success confirmation signals from more than half of the slave nodes, the central cloud master node marks the log entry as committed and applies it to its local state machine to complete the data write-to-disk process. The central cloud master node asynchronously sends a commit notification to the edge cache nodes acting as learners, and the edge cache nodes update their local read views based on the commit notification.

8. The method as described in claim 1, characterized in that, Also includes: The system monitors the available storage capacity of the edge cache node group in real time. When the available storage capacity is lower than the set safety level, it triggers a cache eviction mechanism. It scans all the historical physical examination data stored locally, extracts the last access timestamp of each piece of historical physical examination data and the corresponding physical examination business completion status. It prioritizes the selection of historical physical examination data whose physical examination business completion status is completed and deletes them to release storage space. If the released storage space is lower than the safety water level, the historical physical examination data that has not been accessed for the longest time will be eliminated based on the last access timestamp.

9. The method as described in claim 1, characterized in that, Also includes: When the network connection between the edge cache node in the learner role and the central cloud master node is interrupted, the newly generated data is recorded in the local retransmission log file, and the exponential backoff retry logic is initiated to detect the network status. After detecting that the network connection has been restored, the edge cache node reads the offset record in the retransmission log file and sends a synchronization request containing the offset record to the central cloud master node; the central cloud master node compares its own commit index with the offset record and packages and transmits the missing incremental data back.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor is communicatively connected to the memory; when the processor executes the computer program, it implements the SaaS-based distributed storage and collaboration method for physical examination data of multi-branch enterprises as described in any one of claims 1 to 9.

Images