Method and system for zero-downtime hot update of distributed web services based on atomic transactions

Abstract

Disclosed are an atomic transaction-based distributed Web service zero-interruption hot updating method and system, comprising the following steps: in response to receiving a new version updating instruction, a controller sends a request freezing instruction to a load balancer to redirect new requests to a temporary buffer queue while maintaining established connections; the controller distributes a new version package to Agent nodes in at least one proxy cluster and enters a switching stage after the Agent nodes complete receiving and checking; the Agent nodes perform atomic directory switching operations to atomically switch the new version package from a temporary directory to a target version directory and perform atomic symbolic link switching on a service access path; and the controller notifies the load balancer to restore traffic and release the requests in the temporary buffer queue after confirming that all Agent nodes have completed atomic switching. The hot updating method has the performance of zero interruption, strong consistency and second-level rollback, and significantly improves the stability, reliability and scalability of the system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for zero-disruption hot update of distributed Web services based on atomic transactions. Background Technology

[0002] With the continuous expansion of internet business, distributed web service architecture has become mainstream. To maintain continuous iteration of product functionality and security updates, service applications need frequent version upgrades. However, existing version update methods have significant shortcomings in practical engineering:

[0003] Service interruption issues: While Blue-Green Deployment can guarantee the transition between old and new versions, it requires twice the hardware resources and may still experience short periods of unavailability (tens of seconds) during the transition. Rolling Update completes version upgrades by gradually replacing nodes, but during the coexistence of old and new versions, the request failure rate often increases significantly, even reaching 5% to 8%.

[0004] Data consistency issues: Traditional file-overwrite updates can lead to concurrent read / write conflicts, resulting in dirty data. This can cause serious logical errors, especially in transactions involving strong consistency such as payments and orders. Inconsistent version states across multiple nodes can easily lead to cross-node request processing anomalies, disrupting business continuity.

[0005] Inefficient rollback: Most existing solutions rely on manual intervention for rollback, with average recovery times often exceeding several minutes, resulting in prolonged service unavailability. The lack of a global transaction control mechanism means that some nodes or data may fail to recover synchronously after a rollback, reducing system reliability.

[0006] Limitations of existing tools: During Kubernetes rolling updates, the version switching interval between nodes can reach 2–5 minutes, which cannot meet the needs of high-frequency, low-latency updates. Rsync file synchronization has a high probability of conflicts in large file transfer scenarios. Nginx hot reload is only suitable for configuration updates and cannot solve the problem of atomic replacement of application files.

[0007] Therefore, existing technologies struggle to simultaneously ensure uninterrupted service, strong data consistency, and rapid rollback capabilities in large-scale distributed clusters. How to achieve efficient, stable, and seamless version updates across nodes while guaranteeing user business continuity has become a pressing technical challenge in this field. Summary of the Invention

[0008] To address the aforementioned technical problems in the existing technology, this invention proposes a method and system for zero-disruption hot update of distributed Web services based on atomic transactions, thereby resolving these technical issues.

[0009] According to a first aspect of the present invention, a zero-disruption hot update method for distributed Web services based on atomic transactions is proposed, comprising:

[0010] S1: In response to receiving a new version update instruction, the controller sends a request to freeze the load balancer to redirect new requests to a temporary buffer queue while maintaining established connections.

[0011] S2: The controller distributes the new version package to at least one Agent node in the agent cluster, and enters the switching phase after the Agent node completes the reception and verification;

[0012] S3: The Agent node performs an atomic directory switching operation, atomically switching the new version package from the temporary directory to the target version directory, and atomically switching the service access path using symbolic links.

[0013] S4: In response to the controller confirming that all Agent nodes have completed the atomic switch, notify the load balancer to restore traffic and release requests in the temporary buffer queue.

[0014] In some specific embodiments, S1 specifically includes writing new requests to a temporary buffer queue based on message streams and keeping established connections active until processing is complete.

[0015] In some specific embodiments, the new version package is transmitted in segments according to a preset size, and a verification is performed after each segment is transmitted. After all segments are transmitted, the integrity of the entire version package is verified.

[0016] In some specific embodiments, the atomic directory switching operation in S3 specifically includes: creating a temporary version directory on the Agent node and loading the new version file into the temporary version directory; acquiring a distributed file lock for the directory corresponding to the service access path; freezing the access of new requests after acquiring the file lock, and keeping established connections active; redirecting the service access path from the old version directory to the temporary version directory through atomic operations of the file system within the switching window to complete the atomic replacement of the new version; releasing the file lock and cleaning up the symbolic links of the old version, while delaying the deletion of the old version directory within a preset retention period to support fast rollback.

[0017] In some specific embodiments, restoring traffic specifically includes: gradually releasing requests in the temporary buffer queue according to a preset ratio until the buffer queue is empty, while simultaneously allowing new requests to enter the Agent node.

[0018] In some specific embodiments, a transaction rollback mechanism is also included. The transaction rollback mechanism specifically includes: real-time monitoring of the running status of each Agent node, and automatically triggering a rollback when a heartbeat signal loss, inconsistent version hash value, or service anomaly rate exceeds a preset threshold is detected; during the rollback process, the symbolic links of the service access path are restored to point to the old version directory, and data rollback is performed based on the database transaction log to clear inconsistent data generated during the operation of the new version; new requests are switched to the old version for continued processing, while allowing ongoing requests to complete within a limited time or be forcibly terminated; after the rollback is completed, fault analysis is performed on the faulty nodes and abnormal processes are cleaned up.

[0019] In some specific embodiments, the transaction rollback mechanism is triggered under the following fault judgment conditions: when a node heartbeat signal is lost more than three times consecutively, it is judged as a node timeout and a rollback is triggered within 1.5 seconds; when the version hash value of the Agent node is inconsistent with the expectation, a rollback is triggered in real time; when the service detects an HTTP 500 error rate greater than 10% within 2 seconds, a rollback is triggered; when the CPU utilization of the Agent node exceeds 95% for 30 seconds, a rollback is triggered.

[0020] According to a second aspect of the invention, a computer-readable storage medium is provided on which one or more computer programs are stored, which, when executed by a computer processor, implement the method described above.

[0021] According to a third aspect of the present invention, a zero-disruption hot update system for distributed web services based on atomic transactions is proposed, comprising:

[0022] The controller is configured to send a request freeze command to the load balancer when a new version update instruction is received, redirect the new request to a temporary buffer queue, and distribute the new version package to Agent nodes in at least one agent cluster during the freeze period;

[0023] The load balancer is configured to receive and cache new requests during a freeze, keep established connections active, and gradually restore traffic and release requests in the temporary buffer queue after the controller confirms that all Agent nodes have completed an atomic switch.

[0024] The Agent node cluster is configured to receive new version packages and perform shard verification. After successful verification, a temporary version directory is created and an atomic directory switching operation is performed after acquiring a distributed file lock to redirect the service access path from the old version directory to the temporary version directory. After the switch is completed, a ready signal is reported.

[0025] In some specific embodiments, a monitoring and rollback module is also included, configured to monitor the running status of each Agent node in real time. When a heartbeat signal loss, inconsistent version hash value, or service anomaly rate exceeding a preset threshold is detected, a rollback is automatically triggered. During the rollback process, the symbolic links of the service access path are restored to point to the old version directory, and data rollback is performed based on the database transaction log to clear inconsistent data generated during the operation of the new version. New requests are switched to the old version for continued processing, while ongoing requests are allowed to complete within a limited time or be forcibly terminated. After the rollback is completed, fault analysis is performed on the faulty nodes and abnormal processes are cleaned up.

[0026] This invention proposes a method and system for zero-disruption hot update of distributed web services based on atomic transactions, which has the following technical effects:

[0027] First, this invention overcomes the problems of interruption and resource waste in traditional solutions. Compared with blue-green deployment (requiring double the resources) and rolling updates (where the coexistence of new and old versions leads to a high failure rate of requests), this application achieves seamless updates in less than 0.5 seconds and requires only single-environment resources, resulting in lower resource consumption.

[0028] Secondly, this invention can ensure strong consistency of data and services. Through distributed file locks, atomic switching of symbolic links, and rollback of database transaction logs, it ensures global consistency of data and version status, avoiding dirty data and logical errors.

[0029] In addition, the present invention also has a rapid self-healing capability. Through fault detection and a second-level rollback mechanism, the system can quickly recover when there is a node failure, version error or performance abnormality, significantly reducing MTTR (mean recovery time).

[0030] Finally, this invention has large-scale scalability. Through fragmented verification transmission and progressive traffic recovery design, the system can support rapid parallel updates from tens to thousands of nodes and has linear scalability. Attached Figure Description

[0031] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Many anticipated advantages of the embodiments and other embodiments of the invention will be readily recognized as they become better understood through reference to the following detailed description. Other features, objects, and advantages of this application will become more apparent from reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0032] Figure 1 This is a flowchart of a zero-disruption hot update method for distributed web services based on atomic transactions, according to an embodiment of this application.

[0033] Figure 2 This is a core workflow diagram of a zero-disruption hot update method for distributed web services based on atomic transactions, which is a specific embodiment of this application.

[0034] Figure 3 This is a flowchart of an atomic switching algorithm according to a specific embodiment of this application;

[0035] Figure 4 This is a flowchart of a specific embodiment of the transaction rollback mechanism in this application;

[0036] Figure 5 This is a framework diagram of a zero-disruption hot update system for distributed web services based on atomic transactions, which is a specific embodiment of this application.

[0037] Figure 6 This is a schematic diagram of the structure of a computer system used to implement the electronic device of the present application. Detailed Implementation

[0038] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0039] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0040] Figure 1 A flowchart illustrating a zero-disruption hot update method for distributed web services based on atomic transactions, according to an embodiment of this application, is shown. Figure 1 As shown, the method includes the following steps:

[0041] S1: In response to receiving a new version update instruction, the controller sends a request freeze instruction to the load balancer to redirect new requests to a temporary buffer queue while maintaining established connections.

[0042] In a specific implementation, new requests are written to a temporary buffer queue based on message flow, and established connections remain active until processing is complete. By writing new requests to the temporary buffer queue and maintaining established connections, ongoing business operations are guaranteed to continue uninterrupted, while new requests will not enter nodes that have not yet completed the switchover, thus completely avoiding dirty requests.

[0043] S2: The controller distributes the new version package to at least one Agent node in the agent cluster, and enters the switching phase after the Agent node completes the reception and verification.

[0044] In a specific embodiment, the new version package is transmitted in segments according to a preset size. Verification is performed after each segment is transmitted, and the entire version package is then subjected to integrity verification after all segments have been transmitted. This segmented transmission and segment-by-segment verification, combined with full integrity verification, ensures the consistency and reliability of the version package during transmission and deployment in a large-scale distributed environment, preventing data corruption.

[0045] S3: The Agent node performs an atomic directory switching operation, atomically switching the new version package from the temporary directory to the target version directory, and atomically switching the service access path using symbolic links.

[0046] In a specific embodiment, a temporary version directory is created on the Agent node and the new version file is loaded into the temporary version directory; a distributed file lock is acquired for the directory corresponding to the service access path; after acquiring the file lock, the access of new requests is frozen, while the established connection remains active; within the switching window, the service access path is redirected from the old version directory to the temporary version directory through atomic operations of the file system to complete the atomic replacement of the new version; the file lock is released and the symbolic links of the old version are cleaned up, while the deletion of the old version directory is delayed within a preset retention period to support fast rollback.

[0047] S4: In response to the controller confirming that all Agent nodes have completed the atomic switch, notify the load balancer to restore traffic and release requests in the temporary buffer queue.

[0048] In specific embodiments, a transaction rollback mechanism is also included. This mechanism specifically includes: real-time monitoring of the operational status of each Agent node; automatically triggering a rollback when a heartbeat signal is lost, version hash values ​​are inconsistent, or the service anomaly rate exceeds a preset threshold; during the rollback process, restoring the symbolic links of the service access path to point to the old version directory, and performing data rollback based on the database transaction log to clear inconsistent data generated during the operation of the new version; switching new requests to the old version for continued processing, while allowing ongoing requests to complete within a limited time or be forcibly terminated; and performing fault analysis on the faulty node and cleaning up abnormal processes after the rollback is completed. The triggering of the transaction rollback mechanism specifically includes the following fault judgment conditions: when a node's heartbeat signal is lost more than three times consecutively, it is determined to be a node timeout, and a rollback is triggered within 1.5 seconds; when the version hash value of the Agent node is inconsistent with expectations, a rollback is triggered in real time; when the service detects an HTTP 500 error rate greater than 10% within 2 seconds, a rollback is triggered; when the CPU utilization of the Agent node exceeds 95% for 30 seconds, a rollback is triggered.

[0049] In a specific embodiment, traffic recovery includes: gradually releasing requests in the temporary buffer queue according to a preset ratio until the buffer queue is empty, while simultaneously allowing new requests to enter the Agent node. This gradual release of buffered requests and new requests avoids node overload caused by sudden surges, achieving smooth traffic recovery and ensuring stable service performance.

[0050] Figure 2 This is a core workflow diagram of a zero-disruption hot update method for distributed web services based on atomic transactions, as described in a specific embodiment of this application. Figure 2 As shown, this process mainly includes three stages: pre-distribution, atomic switchover, and service recovery. Its core operations are completed collaboratively by the controller, load balancer, and multiple agent nodes.

[0051] First, during the pre-distribution phase, when the controller receives a new version update instruction, it first sends a request to freeze the load balancer (such as Nginx / HAproxy). Upon receiving this instruction, the load balancer immediately redirects newly arriving requests to a temporary buffer queue by injecting an HTTP 503 status code. In this embodiment, the buffer queue is preferably implemented using Redis Streams to ensure that requests are cached sequentially. Simultaneously, the load balancer keeps established TCP long connections unaffected (retained for a maximum of 300 seconds), ensuring that user sessions can continue to be processed during the freeze period. The freeze process typically lasts 0.1–0.5 seconds, ensuring that the freeze operation is virtually imperceptible to external users.

[0052] After the request to freeze is completed, the controller and each Agent node establish an independent encrypted transmission channel via an SSH tunnel. The channel uses the AES-256-GCM encryption algorithm and enables port multiplexing to reduce the occupancy of existing service ports. This channel includes both a control channel and a data channel. The control channel is used to transmit commands and metadata, with bandwidth usage less than 1%, while the data channel is used for parallel transmission of version packets, utilizing 99% of bandwidth resources. During transmission, the controller fragments the new version packet into 10MB chunks. Each chunk undergoes a CRC32 check immediately upon arrival at the Agent node, with a check time of less than 1 millisecond. After all chunks have been transmitted, a full SHA-256 check is performed to ensure the integrity and consistency of the transmitted data. If a chunk check fails, the system automatically retransmits the chunk (up to three times); if the full check fails, the version packet is discarded and an error alarm is triggered.

[0053] Secondly, during the atomic switchover phase, after successful verification, the Agent node temporarily stores the received new version package in a temporary directory ` / tmp / v2_temp`. This directory is deployed on a tmpfs memory disk to improve I / O performance, and its permissions are set to read-only (`chmod 550 / tmp / v2_temp`) to prevent direct execution or accidental writes. Subsequently, the Agent node acquires a distributed file lock on the service access path directory to ensure no contention occurs when multiple nodes operate simultaneously. After acquiring the file lock and entering the switchover window, the Agent node immediately freezes new request access and keeps existing connections active. Within this switchover window, the Agent node completes directory replacement through atomic operations on the Linux file system: first, it moves the temporary directory to the target directory ` / webapps / v2.0`, and then replaces the service access path ` / current` with a symbolic link to point to the new version directory ` / webapps / v2.0`. This symbolic link replacement is an atomic operation, typically taking less than 0.1 milliseconds, ensuring the instantaneous and indivisible nature of the switchover. After a successful switchover, the Agent node releases the file lock and returns an ACK_READY signal to the controller. The controller waits for all nodes to return this signal. If any node fails to report within the preset 30-second timeout period, it is automatically marked as a faulty node to avoid delaying the overall switchover process.

[0054] Finally, during the service recovery phase, once the controller confirms that all healthy nodes have completed the atomic switchover, it notifies the load balancer to gradually restore traffic. Specifically, the load balancer releases requests in the buffer queue sequentially according to a preset ratio (e.g., 10% per second), and gradually accepts new external requests after the buffer is cleared, thereby avoiding overload pressure on the new version nodes caused by instantaneous traffic surges. After traffic recovery is complete, the Agent node will initiate the old version cleanup process, deleting the old version directory (e.g., / webapps / v1.0), but this operation will be performed in the background with a delay, and the old version will be retained for a preset time window so that a quick rollback can be performed if an anomaly is detected.

[0055] Through the above specific implementation methods, the present invention realizes a complete update chain from request freezing, version package distribution and verification, atomic directory switching and gradual traffic recovery, ensuring uninterrupted service while ensuring cross-node data consistency and efficient rollback capability.

[0056] Figure 3 This is a flowchart of an atomic switching algorithm according to a specific embodiment of this application, such as... Figure 3 As shown, it includes the following steps:

[0057] In step S31, the Agent node first creates a temporary version directory and loads the new version files into this directory. For example, the temporary directory can be created using the command: `mkdir / webapps / v2_temp`, and the following command can be executed: `chmod 550 / webapps / v2_temp` to set the directory permissions to read-only to prevent accidental or malicious modification. Then, the pre-distributed files are copied to the temporary directory using the command: `cp -r / tmp / v2_unpack / * / webapps / v2_temp`. This step preferably uses Copy-on-Write (COW) technology to reduce disk I / O overhead, ensuring that directory creation and file loading are completed within 5-50 milliseconds.

[0058] In step S32, the Agent node acquires a distributed file lock to ensure no conflicts occur during concurrent switching of multiple nodes. Specifically, the system establishes a non-blocking exclusive lock at the inode level using the `flock(fd, LOCK_EX|LOCK_NB)` method, thereby locking the current service directory ` / webapps / current`. If a lock conflict occurs, the node will retry three times at 100-millisecond intervals. If the lock is not acquired within the timeout period, an `ERR_LOCK_TIMEOUT` alarm is triggered. This process typically takes 1-10 milliseconds.

[0059] In step S33, the Agent node freezes newly incoming requests to ensure the stability of service paths within the switching window. The freezing measure includes intercepting new requests at the kernel level using `iptables -A INPUT -p tcp --dport 80 -j DROP`, and placing established connections into the TCP_KEEPALIVE state for a maximum of 300 seconds. New requests will return an HTTP 503 status code during the freeze period, indicating that the service is temporarily unavailable. This step typically completes within 0.5 to 5 milliseconds.

[0060] In step S34, the Agent node performs an atomic replacement operation, redirecting the symbolic link from the old version directory to the new version directory. This operation can be performed using `ln -sfn / webapps / v2_temp / current`, which calls the Linux `rename()` system call at the underlying level, ensuring that the entire switching process is atomic and typically takes less than 0.1 milliseconds.

[0061] In step S35, the Agent node releases the previously acquired file lock by using `flock(fd, LOCK_UN)` and closing the file descriptor. Simultaneously, it cleans up the old symbolic link ` / webapps / v1_link` and reclaims the associated inode resources. This process typically completes within 1 millisecond.

[0062] In step S36, the system gradually restores outbound traffic. The controller instructs the load balancer to release requests in the buffer queue proportionally, for example, releasing 10% of requests per second until the buffer queue is empty. Simultaneously, connections in the TCP_KEEPALIVE state are migrated to the new version node, and the load balancer's routing table is updated accordingly, ensuring that the new version node can smoothly take over the services. This step typically takes 10-100 milliseconds.

[0063] In step S37, the system cleans up the old version directory. To support rapid rollback, this embodiment employs a delayed deletion mechanism, for example, asynchronously deleting the old version in the background using `nohup rm -rf / webapps / v1.0&`, while retaining it for 300 seconds for observation. Within this time window, if an anomaly is detected, a second-level rollback can be immediately triggered via the `rollback.sh` script. If no anomaly is detected, the system safely reclaims the old version resources after the timeout.

[0064] Through the above steps, the atomic switching algorithm in this embodiment can guarantee the atomicity of the version replacement process, avoid file overwrite conflicts or concurrent access errors, and achieve zero service interruption and reversible updates by freezing requests, gradually releasing traffic and delaying the deletion of old versions, thus greatly improving the stability and availability of distributed web services.

[0065] Figure 4 This is a flowchart of a specific embodiment of the transaction rollback mechanism of this application, as shown below. Figure 4 As shown, this transaction rollback mechanism is used to quickly and automatically restore to the old version when an exception occurs during the deployment or switching of a new version, thereby ensuring the continuity and stability of the distributed web service. This mechanism mainly includes the following steps:

[0066] In step 1: Status Monitoring and Fault Detection, the controller polls the running status of each Agent node via an HTTP / 2 long connection at a period of 500ms. Monitoring metrics include CPU load, free memory, version hash value, and the time since the last heartbeat. The specific code is as follows:

[0067] {

[0068] "cpu_load": 0.65,

[0069] "mem_free": 32.1,

[0070] "version_hash": "a1b2c3",

[0071] "last_heartbeat": 1724152837

[0072] }

[0073] The system determines faults based on preset conditions: when heartbeats are lost more than 3 times consecutively, a node timeout is determined and a response is triggered within 1.5 seconds; when the version hash value is inconsistent with expectations, a rollback is triggered in real time; when the HTTP 500 error rate is detected to be greater than 10%, a response is triggered within 2 seconds; when the CPU utilization exceeds 95% for 30 seconds, it is determined to be a resource overload and a response is triggered within 30 seconds.

[0074] In step 2: Rollback triggering, if the system detects a fault and there is no manual intervention, the controller will automatically execute the rollback triggering logic, as shown in the following code:

[0075] if detect_failure() and not manual_override:

[0076] trigger_rollback()

[0077] At the same time, the system will activate a multi-level alarm mechanism, including primary alarms (notifications via WeChat or DingTalk), intermediate alarms (telephone voice reminders), and emergency alarms (automatic wake-up of on-duty personnel) to ensure that fault information can be detected in a timely manner.

[0078] In step 3, during the version rollback process, the system restores symbolic links to the old version directory through atomic operations, such as executing `ln -sfn / webapps / v1.0 / current`. For Windows systems, the rollback can also be completed using the registry restore command `reg restore HKLM\Software\MyApp C:\backup\v1.reg`. To ensure data consistency, the system further executes SQL rollback scripts based on database transaction logs (such as MySQL binlog), for example, deleting order records generated during the new version's operation to avoid business logic errors. The entire version rollback process typically takes 1–5 seconds to complete.

[0079] In step 4, the traffic switching phase, the controller redirects 100% of new requests to the old version node. Requests already executed on the new version node are allowed a maximum of 10 seconds to complete processing; if the timeout period expires before completion, they are forcibly terminated and redirected to the old version to continue execution, thus ensuring the availability of user requests. This process typically completes within 0.5–2 seconds.

[0080] In step 5, fault analysis, the system performs automatic diagnostics in parallel, collecting log files, performing coredump analysis, and generating fault reports. For example, the report might indicate that "version 2.0 has a memory leak on line 382 of app.js, affecting nodes A1, A3, and A7," and provide remediation suggestions.

[0081] In step 6, state recovery, the system restores normal operation by cleaning up residual resources. For example, it executes `pkill -f v2_temp` to terminate the abnormal process and `rm -rf / tmp / v2_lock` to delete the lock file. Then, it performs service self-healing operations, such as `systemctl restart myapp` or `iisreset / restart`, to restore the stability of service components. The entire state recovery process typically takes 1–3 seconds.

[0082] In step 7: the monitoring recovery phase, the system resets the monitoring metrics to a stable state. The specific code is as follows:

[0083] {

[0084] "status": "stable",

[0085] "version": "v1.0",

[0086] "last_rollback": "2025-08-20 15:03:25"

[0087] }

[0088] At the same time, enhanced monitoring strategies are implemented for faulty nodes, including marking them as "vulnerable", performing health checks every minute for 15 minutes, and lowering resource usage thresholds by 20% to reduce the risk of further failures.

[0089] Through the above steps, the transaction rollback mechanism in this embodiment achieves closed-loop control of rapid detection, automatic triggering, atomic rollback, traffic migration, fault diagnosis, and self-healing. This mechanism can restore the system to a stable version within seconds, effectively reducing the mean time to recovery (MTTR) and significantly improving the reliability and high availability of distributed web services.

[0090] The zero-disruption hot update method and system for distributed Web services based on atomic transactions created in this invention have shown significant performance advantages in actual testing and comparison, as shown in Table 1 below.

[0091] Table 1. Comparison of Technical Indicators

[0092]

[0093] Firstly, regarding uninterrupted service capability, traditional update solutions typically require a 30-60 second interruption window, during which user requests may fail or time out. This invention introduces a traffic freezing and buffering queue mechanism to temporarily store new incoming requests during the update process, while maintaining existing TCP connections, thus ensuring the continuity of business sessions. Real-world testing results show that during updates on a 200-node cluster, the user request success rate remains 100%, and the overall service interruption time is less than 0.5 seconds, representing a 99.2% improvement compared to traditional solutions.

[0094] Secondly, regarding data consistency, this invention employs the ACID transaction protocol and an inode-based file locking mechanism to ensure strong consistency in a multi-node concurrent environment. Traditional solutions are prone to file overwrite conflicts during version switching, with a dirty data occurrence rate of approximately 0.15%. However, in this embodiment of the invention, relying on file locking and atomic symbolic link switching, the dirty data occurrence rate is reduced to below 0.001%, resulting in a data consistency improvement of 99.3%.

[0095] Furthermore, regarding rollback efficiency, this invention establishes a second-level transaction rollback mechanism. Through real-time monitoring and automatic triggering logic, the system can roll back to the old version within 2–5 seconds when it detects a lost heartbeat, inconsistent version hash, or an HTTP 500 error rate exceeding a threshold. Compared to the 300–600 seconds recovery time required by traditional manual intervention methods, this invention improves rollback efficiency by 99.2%, significantly shortening the mean time to recovery (MTTR) and thus ensuring business continuity.

[0096] In terms of resource utilization, traditional blue-green deployments require maintaining both the old and new environments simultaneously, resulting in resource occupancy rates of up to 200%. In contrast, this invention relies solely on switching between temporary directories and symbolic links to achieve hot updates, with an overall resource occupancy rate of approximately 105%, nearly half that of traditional solutions, representing an improvement of 47.5%. This reduces operational costs while enhancing resource utilization efficiency.

[0097] To verify the effectiveness of this invention, this embodiment conducted system tests and verifications on the file locking mechanism, performance indicators, and disaster recovery capabilities. The results are as follows:

[0098] Regarding the file lock implementation, this invention employs a distributed file lock based on fcntl to ensure the atomicity and consistency of directory switching operations in a multi-node concurrent environment. Specifically, the core logic of the file lock is shown in the following code:

[0099] / / Core logic of distributed file lock

[0100] void acquire_lock(int fd) {

[0101] struct flock lock = {

[0102] .l_type = F_WRLCK,

[0103] .l_whence = SEEK_SET,

[0104] .l_start = 0,

[0105] .l_len = 0

[0106] };

[0107] fcntl(fd, F_SETLKW,&lock); / / Blocking lock

[0108] }

[0109] In the above implementation, it is guaranteed that only one Agent node can perform symbolic link replacement at any given time, thereby completely avoiding data inconsistency caused by concurrent competition.

[0110] Table 2. Performance Test Report

[0111]

[0112] As shown in Table 2 above, in terms of performance testing, this invention underwent comparative experiments on update time, peak CPU usage, and traffic loss rate in cluster environments of different sizes. The results show that in a 50-node cluster, the update time is 2.3 seconds, the peak CPU usage is approximately 65%, and there is no traffic loss; in a 200-node cluster, the update time is 8.7 seconds, the peak CPU usage is approximately 72%, and again, there is no traffic loss; even in a super-large-scale environment with 1000 nodes, the update time is still only 41.5 seconds, the peak CPU usage is 81%, and the traffic loss rate is less than 0.001%. These results fully demonstrate that this invention possesses good linear scalability and stability, and can still achieve rapid updates without affecting business requests in large-scale clusters.

[0113] Table 3. Disaster Recovery Test Results

[0114]

[0115] As shown in Table 3 above, in terms of disaster recovery capability testing, this invention can maintain business continuity under various failure scenarios. Test results show that when a single node fails, the system can detect and trigger automatic traffic migration within 3 seconds, with the impact limited to the failed node itself; when a network partition occurs, the system can detect and perform a partial rollback within 5 seconds, affecting only the affected partition, while other partitions operate normally without interference; when a version verification failure is detected, the system can immediately stop the update operation and issue an alarm, thereby controlling the impact to zero.

[0116] The above verification results show that the present invention has achieved significant results in ensuring atomicity of the file locking mechanism, maintaining high efficiency and stability of performance, and rapid self-healing of the disaster recovery mechanism. It can effectively solve the problems of service interruption, data inconsistency and inefficient rollback in the existing technology.

[0117] Figure 5 This application illustrates a framework diagram of a zero-disruption hot update system for distributed web services based on atomic transactions, as shown in the following embodiment. Figure 5 As shown, the system includes a monitoring layer 510, a control layer 520, and a data layer 530. The monitoring layer 510 is used to collect performance indicators of 50+ dimensions in real time to achieve closed-loop control. The control layer 520 includes an update controller 521, a load balancer 522, and a proxy cluster 523. The update controller 521 acts as the central brain, coordinating the load balancer 522 and the proxy cluster 523. The data layer 530 manages version files for the proxy cluster and enables the load balancer to intelligently route traffic.

[0118] In a specific embodiment, the update controller 521 is specifically configured to send a request freeze instruction to the load balancer upon receiving a new version update instruction, redirecting new requests to a temporary buffer queue, and distributing the new version package to at least one Agent node in the agent cluster during the freeze period. The load balancer 522 is specifically configured to receive and cache new requests during the freeze period according to the controller's instructions, keeping established connections active, and gradually restoring traffic and releasing requests in the temporary buffer queue after the controller confirms that all Agent nodes have completed the atomic switchover. The agent cluster 523 is specifically configured to receive the new version package and perform shard verification. After successful verification, it creates a temporary version directory and, after acquiring a distributed file lock, performs an atomic directory switchover operation to redirect the service access path from the old version directory to the temporary version directory, and reports a ready signal after the switchover is complete.

[0119] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 6 As shown, the computer system includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0121] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a liquid crystal display (LCD) and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card and a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0122] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the methods of this application. It should be noted that the computer-readable storage medium of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0123] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0124] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0125] The modules described in the embodiments of this application can be implemented in software or in hardware.

[0126] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: upon receiving a new version update instruction, send a request freeze instruction to the load balancer to redirect new requests to a temporary buffer queue while maintaining established connections; distribute the new version package to at least one Agent node in the agent cluster, and enter a switching phase after the Agent node completes reception and verification; perform an atomic directory switching operation, atomically switching the new version package from the temporary directory to the target version directory, and atomically switching the service access path using symbolic links; and, upon the controller confirming that all Agent nodes have completed the atomic switch, notify the load balancer to restore traffic and release requests in the temporary buffer queue.

[0127] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A zero-disruption hot update method for distributed Web services based on atomic transactions, characterized in that, include: S1: In response to receiving a new version update instruction, the controller sends a request to freeze the load balancer to redirect new requests to a temporary buffer queue while maintaining established connections. S2: The controller distributes the new version package to at least one Agent node in the agent cluster, and enters the switching phase after the Agent node completes the reception and verification; S3: The Agent node performs an atomic directory switching operation, atomically switching the new version package from the temporary directory to the target version directory, and atomically switching the service access path using symbolic links; The atomic directory switching operation specifically includes: creating a temporary version directory on the Agent node and loading the new version file into the temporary version directory; acquiring a distributed file lock for the directory corresponding to the service access path; freezing the access of new requests after acquiring the file lock, while keeping established connections active; redirecting the service access path from the old version directory to the temporary version directory through atomic operations of the file system within the switching window to complete the atomic replacement of the new version; releasing the file lock and cleaning up the symbolic links of the old version, while delaying the deletion of the old version directory within a preset retention period to support fast rollback; S4: In response to the controller confirming that all Agent nodes have completed the atomic switch, the load balancer is notified to restore traffic and release requests in the temporary buffer queue.

2. The zero-disruption hot update method for distributed Web services based on atomic transactions according to claim 1, characterized in that, S1 specifically includes writing the new request into a temporary buffer queue based on a message stream, and keeping the established connection active until processing is complete.

3. The zero-disruption hot update method for distributed Web services based on atomic transactions according to claim 1, characterized in that, The new version package is divided into segments according to a preset size for transmission, and a verification is performed after each segment is transmitted. After all segments are transmitted, the integrity of the entire version package is verified.

4. The zero-disruption hot update method for distributed Web services based on atomic transactions according to claim 1, characterized in that, The traffic recovery specifically includes: gradually releasing requests in the temporary buffer queue according to a preset ratio until the buffer queue is empty, while simultaneously allowing new requests to enter the Agent node.

5. The zero-disruption hot update method for distributed Web services based on atomic transactions according to claim 1, characterized in that, It also includes a transaction rollback mechanism, which specifically includes: real-time monitoring of the running status of each Agent node; automatically triggering a rollback when a heartbeat signal is lost, version hash values ​​are inconsistent, or the service anomaly rate exceeds a preset threshold; during the rollback process, restoring the symbolic links of the service access path to point to the old version directory, and performing data rollback based on the database transaction log to clear inconsistent data generated during the operation of the new version; switching new requests to the old version for continued processing, while allowing ongoing requests to complete within a limited time or be forcibly terminated; and performing fault analysis on the faulty nodes and cleaning up abnormal processes after the rollback is completed.

6. The zero-disruption hot update method for distributed Web services based on atomic transactions according to claim 5, characterized in that, The transaction rollback mechanism is triggered under the following fault conditions: when a node's heartbeat signal is lost more than three times consecutively, it is determined that the node has timed out and a rollback is triggered within 1.5 seconds; when the version hash value of the Agent node is inconsistent with the expectation, a rollback is triggered in real time; when the service detects an HTTP 500 error rate greater than 10% within 2 seconds, a rollback is triggered; when the CPU utilization of the Agent node exceeds 95% for 30 seconds, a rollback is triggered.

7. A computer-readable storage medium having one or more computer programs stored thereon, characterized in that, When the one or more computer programs are executed by a computer processor, they perform the method according to any one of claims 1-6.

8. A distributed Web service zero-disruption hot update system based on atomic transactions, characterized in that, include: The controller is configured to send a request freeze command to the load balancer when a new version update instruction is received, redirect the new request to a temporary buffer queue, and distribute the new version package to Agent nodes in at least one agent cluster during the freeze period; A load balancer is configured to receive and cache new requests during a freeze period, keep established connections active, and gradually restore traffic and release requests in the temporary buffer queue after the controller confirms that all Agent nodes have completed an atomic switch. The Agent node cluster is configured to receive the new version package and perform shard verification. After successful verification, it creates a temporary version directory and, after acquiring a distributed file lock, performs an atomic directory switching operation to redirect the service access path from the old version directory to the temporary version directory. After the switch is completed, it reports a ready signal. Specifically, the atomic directory switching operation includes: creating a temporary version directory on the Agent node and loading the new version file into the temporary version directory; acquiring a distributed file lock for the directory corresponding to the service access path; freezing the access of new requests after acquiring the file lock and keeping established connections active; redirecting the service access path from the old version directory to the temporary version directory through atomic operations of the file system within the switching window to complete the atomic replacement of the new version; releasing the file lock and cleaning up the symbolic links of the old version, while delaying the deletion of the old version directory within a preset retention period to support fast rollback.

9. A zero-disruption hot update system for distributed Web services based on atomic transactions as described in claim 8, characterized in that, It also includes a monitoring and rollback module, configured to monitor the running status of each Agent node in real time, and automatically trigger a rollback when a heartbeat signal is lost, the version hash value is inconsistent, or the service anomaly rate exceeds a preset threshold. During the rollback process, the symbolic links of the service access path are restored to point to the old version directory, and data rollback is performed based on the database transaction log to clear inconsistent data generated during the operation of the new version; new requests are switched to the old version to continue processing, while ongoing requests are allowed to complete within a limited time or be forcibly terminated; after the rollback is completed, fault analysis is performed on the faulty node and abnormal processes are cleaned up.

Images