Cloud storage client hot upgrade method, device and equipment and storage medium

Abstract

The invention discloses a hot upgrade method, device and equipment for a cloud storage client and a storage medium, relates to the field of computers, is applied to the client, and comprises the following steps: constructing a target cross-process connection to transfer a target mounting file descriptor from an old daemon process to a new daemon process, using the new daemon process to obtain a first user space request based on the target mounted file descriptor; sending a target request takeover signal to the old service process by using the new daemon process, and storing an intermediate state file generated by the old service process based on the target request takeover signal to the local client; and calling the intermediate state file by utilizing the new service process, obtaining the target mounting file descriptor from the new daemon process to process the first user space request, and processing a second user space request which is not processed by the old service process based on the intermediate state file. According to the method and the device, the cloud storage client is upgraded while the service is not interrupted and the data consistency is ensured.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a cloud storage client hot upgrade method, device, equipment and storage medium. Background Art

[0002] With the rapid development of information technology, cloud storage, as an efficient and convenient method for data management and sharing, has become widely adopted by both individual users and enterprise applications. However, with growing user demands and continuous technological advancements, cloud storage client software requires frequent updates to adapt to new functional requirements, security standards, and performance optimizations. Within the existing technical framework, cloud storage clients based on FUSE (Filesystem in Userspace) allow users to access cloud data through a standard file system interface, greatly improving user convenience. Traditional client upgrade methods often require service interruption, which not only affects the user experience but can also cause delays in critical business operations or data loss.

[0003] In summary, how to upgrade cloud storage clients without interrupting services and ensuring data consistency is a problem that needs to be solved urgently. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a cloud storage client hot upgrade method, device, equipment and storage medium, which can achieve the upgrade of the cloud storage client without interrupting service and ensuring data consistency. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a cloud storage client hot upgrade method, which is applied to the client and includes:

[0006] Establishing a target inter-process connection, and using the target inter-process connection to transfer a target mount file descriptor from the old daemon process to the new daemon process, so as to use the new daemon process to obtain a first user space request sent by the kernel based on the target mount file descriptor;

[0007] Using the new daemon process to send a target request takeover signal to the old service process, and saving the intermediate state file generated by the old service process based on the target request takeover signal to the local client;

[0008] Using the new service process to call the intermediate state file, and obtaining the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and to process the second user space request that has not been completed by the old service process based on the intermediate state file;

[0009] The old service process and the old daemon process are service processes and daemon processes corresponding to the currently installed version of the client, and the new service process and the new daemon process are service processes and daemon processes corresponding to the optimized version of the currently installed version of the client.

[0010] Optionally, before the cross-process linking of the building target, the following is further included:

[0011] Access the target image repository based on the preset update check time;

[0012] Determine whether the target update package corresponding to the currently installed version of the client exists in the target image repository;

[0013] If the target update package exists in the target image repository, the target update package is obtained from the target image repository; the client version corresponding to the target update package is an optimized version of the currently installed version;

[0014] A new daemon process and a new service process are constructed based on the target update package.

[0015] Optionally, determining whether a target update package corresponding to the currently installed version of the client exists in the target image repository includes:

[0016] Comparing the version information of all client update packages in the target image repository with the version information of the currently installed version using a target package management tool or based on a target transmission protocol to determine whether there is an update package to be verified corresponding to the optimized version of the currently installed version;

[0017] If the update package to be verified exists, version compatibility verification and security verification are performed on the update package to be verified; the security verification includes digital signature verification and hash value comparison;

[0018] If the update package to be verified passes the version compatibility verification and the security verification, the update package to be verified is determined as the target update package corresponding to the currently installed version of the client.

[0019] Optionally, obtaining the target update package from the target image repository includes:

[0020] Determine target network bandwidth;

[0021] The target update package is obtained from the target image repository using target multi-thread download technology based on a breakpoint resume mechanism and the target network bandwidth.

[0022] Optionally, the build target is linked across processes, including:

[0023] Using the target component, establish target communication connections between the old daemon process and the old service process, between the new daemon process and the new service process, between the old daemon process and the new daemon process, and between the old service process and the new daemon process respectively;

[0024] Initializing the target communication connection between the old daemon process and the old service process using the target device file to generate a target mount file descriptor;

[0025] A dual-process collaboration architecture is constructed during the hot upgrade process, and a target cross-process connection is constructed based on the dual-process collaboration architecture, the target protocol family, and the initialized target communication connection.

[0026] Optionally, processing the unprocessed second user space request of the old service process based on the intermediate state file includes:

[0027] Parsing the intermediate state file to obtain corresponding parsing results;

[0028] Restoring the working state of the old service process based on the analysis result to adjust the working state of the new service process;

[0029] The new service process with the adjusted working state is used to process the second user space request that has not been completely processed by the old service process.

[0030] Optionally, the cloud storage client hot upgrade method further includes:

[0031] If the updated client meets the preset version rollback condition, the client is rolled back based on the pre-reserved old service process, old daemon process and intermediate state file.

[0032] In a second aspect, the present application discloses a cloud storage client hot upgrade device, which is applied to a client and includes:

[0033] a first request processing module, configured to establish a target inter-process connection, and transfer a target mount file descriptor from the old daemon process to the new daemon process by using the target inter-process connection, so as to obtain a first user space request sent by the kernel based on the target mount file descriptor by using the new daemon process;

[0034] an intermediate file saving module, configured to use the new daemon process to send a target request takeover signal to the old service process, and save the intermediate state file generated by the old service process based on the target request takeover signal to the local client;

[0035] a second request processing module, configured to use the new service process to call the intermediate state file and obtain the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and to process the second user space request that has not been completed by the old service process based on the intermediate state file;

[0036] The old service process and the old daemon process are service processes and daemon processes corresponding to the currently installed version of the client, and the new service process and the new daemon process are service processes and daemon processes corresponding to the optimized version of the currently installed version of the client.

[0037] In a third aspect, the present application discloses an electronic device, comprising:

[0038] Memory, used to store computer programs;

[0039] The processor is configured to execute the computer program to implement the aforementioned cloud storage client hot upgrade method.

[0040] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned cloud storage client hot upgrade method when executed by a processor.

[0041] In the present application, when hot upgrading the cloud storage client, the client constructs a target cross-process connection, and uses the target cross-process connection to pass the target mount file descriptor from the old daemon process to the new daemon process, so that the new daemon process obtains the first user space request sent by the kernel based on the target mount file descriptor; uses the new daemon process to send a target request takeover signal to the old service process, and saves the intermediate state file generated by the old service process based on the target request takeover signal to the client locally; uses the new service process to call the intermediate state file, and obtains the target mount file descriptor from the new daemon process, so that the new service process processes the first user space request based on the target mount file descriptor, and processes the second user space request that has not been processed by the old service process based on the intermediate state file; wherein the old service process and the old daemon process are the service process and the daemon process corresponding to the currently installed version of the client, and the new service process and the new daemon process are the service process and the daemon process corresponding to the optimized version of the currently installed version of the client. As can be seen, this application establishes a target cross-process connection between different processes, so that the target mount file descriptor can be passed from the old daemon process to the new daemon process and finally to the new service process. After obtaining the target mount file descriptor, the new daemon process can obtain the first user space request sent by the kernel and pass it to the new service process for processing. From the kernel's perspective, since the target mount file descriptor always points to the same device file stably before and after the update, its consistency is perfectly maintained. The user hardly feels the existence of the upgrade process, and the communication between the kernel and the client can still proceed smoothly without any interruption or exception. In addition, after the new daemon process is loaded, it will send a target request takeover signal to the old service process to take over the second user space request that the old service process has not completed. After receiving the target request takeover signal, the old service process will generate an intermediate state file that records the current working state, so that the new service process can adjust its own working state based on the intermediate state file, thereby ensuring a seamless connection of the hot upgrade process and ensuring that no unfinished tasks are omitted or lost during the entire hot upgrade process. All ongoing operations can continue smoothly in the new service process. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0043] Figure 1This is a flow chart of a cloud storage client hot upgrade method disclosed in this application;

[0044] Figure 2 This is a schematic diagram of the structure of a cloud storage client hot upgrade device disclosed in this application;

[0045] Figure 3 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0046] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0047] With the rapid development of information technology, cloud storage, as an efficient and convenient way to manage and share data, has been widely used in individual users and enterprise-level applications. However, with the growth of user needs and the continuous advancement of technology, cloud storage client software needs to be frequently updated to adapt to new functional requirements, security standards and performance optimization. In the existing technical framework, cloud storage clients implemented based on FUSE (Filesystem in Userspace) allow users to access cloud data through a standard file system interface, greatly improving user convenience. Traditional client upgrade methods often require service interruption, which not only affects the user experience, but may also cause delays in key business operations or data loss. In order to solve the above technical problems, the present application discloses a cloud storage client hot upgrade method that can upgrade the cloud storage client without interrupting service and ensuring data consistency.

[0048] See also Figure 1 As shown, an embodiment of the present invention discloses a cloud storage client hot upgrade method, which is applied to a client and includes:

[0049] Step S11: construct a target cross-process connection, and use the target cross-process connection to transfer the target mount file descriptor from the old daemon process to the new daemon process, so as to use the new daemon process to obtain the first user space request sent by the kernel based on the target mount file descriptor.

[0050] In this embodiment, before establishing a target cross-process connection, the client also needs to access the target image repository based on a preset update check time; determine whether the target update package corresponding to the client's currently installed version exists in the target image repository; if the target update package exists in the target image repository, obtain the target update package from the target image repository; the client version corresponding to the target update package is an optimized version of the currently installed version; and build a new daemon process and a new service process based on the target update package. In other words, in this embodiment, based on a scheduled task mechanism, the target image repository is automatically accessed according to a preset update check time (such as a quick check once an hour and / or a full check once a day). In order to determine whether the target update package corresponding to the client's currently installed version exists in the target image repository, the version information of all client update packages in the target image repository can be compared with the version information of the currently installed version using a target package management tool or based on a target transmission protocol to determine whether there is an update package to be verified corresponding to the optimized version of the currently installed version. Specifically, you can compare the currently installed version with the version information in the image repository through HTTP (Hypertext Transfer Protocol) / HTTPS (Hypertext Transfer Protocol Secure) or use professional package management tools such as Docker and Helm to determine whether a better new version is available for update.

[0051] In this embodiment, if an update package is available, the client will perform version compatibility and security verification on it. This security verification includes digital signature verification and hash value comparison. If the update package passes both these verifications, it will be identified as the target update package corresponding to the client's currently installed version. In other words, once the client successfully discovers a new version, it does not blindly download and update it immediately. Instead, it first undergoes a rigorous version compatibility verification phase. Through a series of rigorous tests and simulations, the client ensures that the new version is fully compatible with the existing system environment, user configurations, and other related components, and that the update will not cause any malfunctions or anomalies in existing functionality. Furthermore, to effectively prevent malware intrusion, comprehensive security checks are performed, such as rigorously verifying the new version's digital signature or calculating a file's hash value and comparing it to an officially provided standard hash value. Only after the new version is confirmed to be secure, reliable, and compatible will the client proceed to the next step. This ensures that each update is secure and reliable, and that the new version is fully compatible with the existing system environment, without causing any functional anomalies or security vulnerabilities.

[0052] In this embodiment, once the client completes version verification of the target update package and confirms that it is correct, it will quickly pull the latest update package from the image repository and store it in the local cache directory. During the download process, a series of optimization strategies are adopted to ensure download reliability while ensuring download speed. For example, multi-threaded download technology is used to increase download speed, and a breakpoint resume mechanism is used to ensure that the update package can be fully obtained even when the network is unstable. In addition, the network bandwidth is allocated as reasonably as possible, ensuring the security and efficiency of the update process and avoiding excessive bandwidth consumption due to downloading the update package, thereby affecting the user's normal business operations.

[0053] It should be noted that this embodiment has made innovative improvements to the client architecture design, dividing the client into two independent but collaborative processes: a service process and a daemon process. The service process focuses on processing FUSE requests from users. It serves as an interactive bridge between users and the cloud storage system, efficiently converting user operation instructions into access and management of cloud storage resources. The daemon process is responsible for process lifecycle management, version detection, and upgrade coordination. In terms of process monitoring, the inotify mechanism is used to implement real-time and accurate monitoring of the service process PID file status. This mechanism can capture various status changes of PID files with high sensitivity, including but not limited to file creation, modification, and deletion operations. The old service process and old daemon process are the service process and daemon process corresponding to the currently installed version of the client, and the new service process and new daemon process are the service process and daemon process corresponding to the optimized version of the currently installed version of the client.

[0054] It can be understood that, in this embodiment, the specific process of the client constructing the target cross-process connection may include: using the target component to establish target communication connections between the old daemon process and the old service process, between the new daemon process and the new service process, between the old daemon process and the new daemon process, and between the old service process and the new daemon process; using the target device file to initialize the target communication connection between the old daemon process and the old service process to generate a target mount file descriptor; constructing a dual-process collaboration architecture during the hot upgrade process, and constructing a target cross-process connection based on the dual-process collaboration architecture, the target protocol family and the initialized target communication connection. Specifically, the client uses the go-fuse component (also known as the target component) to establish a persistent kernel communication channel (also known as a target communication connection) between various processes. It then initializes the target communication connection using the target device file / dev / fuse, generating a unique mount file descriptor (mount fd). This descriptor maintains a constant state throughout the client's lifecycle, forming a transparent data transmission link between kernel space and the user-mode service process. Furthermore, the client constructs a dual-process collaboration architecture for the hot upgrade process. Based on the AF_UNIX protocol family (also known as the target protocol family), the dual-process collaboration architecture, and the initialized target communication connection, a Unix domain socket connection (also known as a target cross-process connection) is established between various processes. This connection acts as a secure and efficient "data transmission channel." Through this channel, the old service process passes the crucial mount fd to the old daemon, which in turn passes it to the new daemon. This ensures atomic transfer of the mount fd via SCM_RIGHTS control messages throughout the hot upgrade process, ensuring the continuous availability of the kernel I / O channel during process switching.

[0055] In this embodiment, after successfully receiving the mount fd from the old daemon, the new daemon process officially begins handling FUSE requests from the kernel. From the kernel's perspective, the entire process remains largely unchanged, as the mount fd consistently points to the same device file. Although the underlying logic for handling FUSE requests has been updated to the latest version of the code, the consistency of the mount fd is perfectly maintained, allowing communication between the kernel and the client to proceed smoothly without interruption or anomalies. The daemon uses the inotify mechanism to monitor the service process in real time and uses the SO_KEEPALIVE socket option to verify the connection status, ensuring system stability and communication continuity. During the connection verification phase, a fixed-cycle mode is used, utilizing the SO_KEEPALIVE socket option to perform rigorous and thorough verification of the connection status. This high-frequency verification strategy allows the system to accurately identify potential anomalies in the connection process, such as unexpected network link interruptions and sudden crashes of the peer process, in a very short time, laying a solid foundation for the system's continued stable operation. Once a connection failure is detected, the daemon quickly initiates an intelligent recovery process, first attempting an automatic reconnection. If reconnection fails, it automatically switches to a backup connection based on a pre-defined fault handling strategy or promptly notifies the system administrator for manual intervention, ensuring the continuity and stability of system communications. Automated detection and hot-upgrade capabilities reduce the need for manual intervention, lowering operational and maintenance costs and complexity.

[0056] Step S12: Utilize the new daemon process to send a target request takeover signal to the old service process, and save the intermediate state file generated by the old service process based on the target request takeover signal to the local client.

[0057] In this embodiment, when the new daemon process completes all preparatory tasks and is ready to take over a second userspace request that the old service process has already received but not yet processed, a SIGHUP signal (also known as the target request takeover signal) is sent to the old service process. This signal acts as a clear "instruction." Upon receiving this signal, the old service process immediately stops accepting new FUSE requests. Simultaneously, based on the target request takeover signal, it generates an intermediate state file to quickly and completely flush data temporarily stored in the cache to the client, ensuring data security and integrity. Thereafter, the old service process systematically reduces its use of system resources, for example by closing unnecessary network connections and freeing up memory space, until it completely ceases service. However, before terminating service, the old service process will make every effort to complete all ongoing operations to avoid data loss or operation failures due to service interruption. Specifically, this intermediate state file uses memory mapping technology to record information, including a set of active file handles and their access mode identifiers, a transaction state matrix for unfinished asynchronous operations, a cache coherence flag bitmap, and a distributed lock holding state vector. Data integrity is ensured in this intermediate state file using a CRC32C checksum algorithm. The intermediate state file contains detailed information about the client's current context. This includes, but is not limited to, a list of open files, which may be in the critical stages of being edited, read, or written; and unfinished operations, such as ongoing data uploads and downloads. The complete preservation and accurate transmission of this information is crucial for the smooth progress of subsequent hot upgrades.

[0058] Step S13: Use the new service process to call the intermediate state file, and obtain the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and process the second user space request that has not been processed by the old service process based on the intermediate state file.

[0059] In this embodiment, the new service process will call the intermediate state file locally from the client, and then use the target cross-process connection established in the aforementioned process to obtain the target file mount symbol from the new daemon process. The target file mount symbol can then be used to process the first user space request newly received by the new daemon process, and the new service process can also be used to process the second user space request that the old service process has not yet completed. The processing of the second user space request that the old service process has not yet completed based on the intermediate state file can specifically include: parsing the intermediate state file to obtain a corresponding parsing result; restoring the working state of the old service process based on the parsing result to adjust the working state of the new service process; and using the new service process after the working state adjustment to process the second user space request that the old service process has not yet completed.

[0060] Specifically, upon startup, the new service process immediately loads the intermediate state file saved by the old service process. By parsing and restoring the context information detailed in this file, the new service process can quickly restore to the previous working state of the old service process. This critical step is crucial for ensuring a seamless hot upgrade process. It ensures that no unfinished tasks are missed or lost throughout the hot upgrade process, and all ongoing operations can continue smoothly in the new service process, maintaining high system availability and data integrity. In one specific embodiment, the new service process can implement a context recovery engine during the loading phase of the upgraded daemon process (i.e., the new daemon process). By parsing the intermediate state file, it reconstructs the operating environment of the old service process, achieving semantic equivalence of file handles, regenerating instruction sequences for interrupted operations, and maintaining cache topology consistency. In one specific embodiment, this process can employ a lock-free design to ensure the atomicity of the recovery operation and implement a lossless migration mechanism for kernel-mode access channels. Unix domain sockets are used to transmit mount fd and status information, and the SIGHUP signal is used to notify the old service process to complete the handover. A lossless migration mechanism is used to ensure the consistency of the kernel state access channel, making the switch between the old and new processes completely transparent to the user.

[0061] In this embodiment, once the new service process completes all initialization and state recovery tasks, fully boots up, and enters a stable operating state, it officially takes over all FUSE request processing. Since the consistency of the mount fd is strictly guaranteed throughout the hot upgrade process, users can seamlessly switch between the old and new versions. Software updates do not require interrupting the cloud storage service provided to users, so users are virtually unaware that the client software has completed a version upgrade. Operations such as reading and writing files, creating and deleting directories, and more, all proceed smoothly as usual, without any lags or exceptions.

[0062] In this embodiment, during a hot upgrade, the client implements a series of stringent data protection measures, the most critical of which is the timely persistence of all newly written data in memory to the object storage. Simultaneously, the client also fully saves all open file handles to disk. This means that even if a FUSE request fails to complete promptly during the hot upgrade due to various reasons, when the new process is started, these open files can be quickly restored based on the saved file handles and persisted data, ensuring that subsequent FUSE operations proceed smoothly and unimpeded. Furthermore, after each hot upgrade, the client automatically performs a comprehensive and in-depth consistency check. This meticulously compares and verifies all data in the system to ensure data integrity, accuracy, and consistency. If any anomalies are detected during the check, such as data loss, corruption, or inconsistency, the system immediately triggers appropriate remedial measures, such as restoring data from backups or repairing damaged data, to ensure data security and stable operation of the entire cloud storage system.

[0063] As you can understand, after confirming that the new service process has been running stably for a sufficient period of time and can reliably handle all FUSE requests, the old service process can be safely exited. Simultaneously, the client automatically cleans up any no longer needed temporary resources generated during the hot upgrade process, such as temporary files, cached data, and previously saved intermediate state files. This timely cleanup of these temporary resources effectively frees up system resources and improves overall system performance and stability. Furthermore, if the updated client meets pre-set rollback conditions, such as incompatibility with certain system environments, resulting in service startup failures, or significant functional defects discovered during actual operation that impact user experience, the client will be rolled back based on the previously preserved old service processes, daemons, and intermediate state files. By preserving the old service processes and their detailed state information, the client can quickly roll back to the previously stable and reliable version. This rapid rollback capability minimizes the impact of new version issues on users and ensures the continued stability of their services. Furthermore, intelligent fault handling strategies and rapid rollback capabilities make system maintenance more convenient and efficient, significantly improving operational efficiency.

[0064] As can be seen, this application establishes a target cross-process connection between different processes, so that the target mount file descriptor can be passed from the old daemon process to the new daemon process and finally to the new service process. After obtaining the target mount file descriptor, the new daemon process can obtain the first user space request sent by the kernel and pass it to the new service process for processing. From the kernel's perspective, since the target mount file descriptor always points to the same device file stably before and after the update, its consistency is perfectly maintained. The user hardly feels the existence of the upgrade process, and the communication between the kernel and the client can still proceed smoothly without any interruption or exception. In addition, after the new daemon process is loaded, it will send a target request takeover signal to the old service process to take over the second user space request that the old service process has not completed. After receiving the target request takeover signal, the old service process will generate an intermediate state file that records the current working state, so that the new service process can adjust its own working state based on the intermediate state file, thereby ensuring a seamless connection of the hot upgrade process and ensuring that no unfinished tasks are omitted or lost during the entire hot upgrade process. All ongoing operations can continue smoothly in the new service process.

[0065] See also Figure 2 As shown, the present application discloses a cloud storage client hot upgrade device, which is applied to the client and includes:

[0066] A first request processing module 11 is configured to establish a target inter-process connection, and transfer a target mount file descriptor from the old daemon process to the new daemon process by using the target inter-process connection, so as to use the new daemon process to obtain a first user space request sent by the kernel based on the target mount file descriptor;

[0067] The intermediate file saving module 12 is configured to use the new daemon process to send a target request takeover signal to the old service process, and save the intermediate state file generated by the old service process based on the target request takeover signal to the local client;

[0068] a second request processing module 13, configured to use the new service process to call the intermediate state file and obtain the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and to process the second user space request that has not been completed by the old service process based on the intermediate state file;

[0069] The old service process and the old daemon process are service processes and daemon processes corresponding to the currently installed version of the client, and the new service process and the new daemon process are service processes and daemon processes corresponding to the optimized version of the currently installed version of the client.

[0070] As can be seen, this application establishes a target cross-process connection between different processes, so that the target mount file descriptor can be passed from the old daemon process to the new daemon process and finally to the new service process. After obtaining the target mount file descriptor, the new daemon process can obtain the first user space request sent by the kernel and pass it to the new service process for processing. From the kernel's perspective, since the target mount file descriptor always points to the same device file stably before and after the update, its consistency is perfectly maintained. The user hardly feels the existence of the upgrade process, and the communication between the kernel and the client can still proceed smoothly without any interruption or exception. In addition, after the new daemon process is loaded, it will send a target request takeover signal to the old service process to take over the second user space request that the old service process has not completed. After receiving the target request takeover signal, the old service process will generate an intermediate state file that records the current working state, so that the new service process can adjust its own working state based on the intermediate state file, thereby ensuring a seamless connection of the hot upgrade process and ensuring that no unfinished tasks are omitted or lost during the entire hot upgrade process. All ongoing operations can continue smoothly in the new service process.

[0071] In a specific embodiment, the device may further include:

[0072] The image repository access module is used to access the target image repository based on the preset update check time;

[0073] A conditional judgment module, configured to judge whether a target update package corresponding to the currently installed version of the client exists in the target image repository;

[0074] An update package acquisition module is configured to acquire the target update package from the target image repository if the target update package exists in the target image repository; the client version corresponding to the target update package is an optimized version of the currently installed version;

[0075] The process construction module is used to construct a new daemon process and a new service process based on the target update package.

[0076] In a specific implementation, the condition judgment module may specifically include:

[0077] a version comparison unit, configured to compare the version information of all client update packages in the target image repository with the version information of the currently installed version using a target package management tool or based on a target transmission protocol, to determine whether there is an update package to be verified corresponding to the optimized version of the currently installed version;

[0078] An update package verification unit, configured to perform version compatibility verification and security verification on the update package to be verified if the update package to be verified exists; the security verification includes digital signature verification and hash value comparison;

[0079] The target update package determining unit is configured to determine the update package to be verified as the target update package corresponding to the currently installed version of the client if the update package to be verified passes the version compatibility verification and the security verification.

[0080] In a specific implementation, the update package acquisition module may specifically include:

[0081] A bandwidth determination unit, configured to determine a target network bandwidth;

[0082] The update package acquisition unit is configured to acquire the target update package from the target image repository by utilizing a target multi-thread downloading technology based on a breakpoint resume mechanism and the target network bandwidth.

[0083] In a specific implementation, the first request processing module 11 may specifically include:

[0084] a communication connection establishing unit, configured to establish target communication connections between the old daemon process and the old service process, between the new daemon process and the new service process, between the old daemon process and the new daemon process, and between the old service process and the new daemon process, respectively, by using a target component;

[0085] a communication connection initialization unit, configured to initialize the target communication connection between the old daemon process and the old service process using a target device file to generate a target mount file descriptor;

[0086] The cross-process connection construction unit is used to construct a dual-process cooperation architecture during the hot upgrade process, and to construct a target cross-process connection based on the dual-process cooperation architecture, the target protocol family and the initialized target communication connection.

[0087] In a specific implementation, the second request processing module 13 may specifically include:

[0088] A state file parsing unit, configured to parse the intermediate state file to obtain a corresponding parsing result;

[0089] a working state adjusting unit, configured to restore the working state of the old service process based on the analysis result to adjust the working state of the new service process;

[0090] The request processing unit is used to use the new service process with adjusted working status to process the second user space request that has not been processed by the old service process.

[0091] In a specific embodiment, the device may further include:

[0092] The version rollback module is used to roll back the version of the client based on the pre-reserved old service process, old daemon process and intermediate state file if the updated client meets the preset version rollback conditions.

[0093] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 3 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0094] Figure 3 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the cloud storage client hot upgrade method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0095] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0096] In addition, the memory 22 as a carrier for resource storage can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0097] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, and can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of implementing the cloud storage client hot upgrade method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of implementing other specific tasks.

[0098] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned cloud storage client hot upgrade method. The specific steps of this method can be referred to the corresponding content disclosed in the aforementioned embodiments and will not be repeated here.

[0099] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0100] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0102] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0103] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A cloud storage client hot upgrade method, characterized in that: Applied to the client, including: Establishing a target inter-process connection, and using the target inter-process connection to transfer a target mount file descriptor from the old daemon process to the new daemon process, so as to use the new daemon process to obtain a first user space request sent by the kernel based on the target mount file descriptor; Using the new daemon process to send a target request takeover signal to the old service process, and saving the intermediate state file generated by the old service process based on the target request takeover signal to the local client; Using the new service process to call the intermediate state file, and obtaining the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and to process the second user space request that has not been completed by the old service process based on the intermediate state file; The old service process and the old daemon process are service processes and daemon processes corresponding to the currently installed version of the client, and the new service process and the new daemon process are service processes and daemon processes corresponding to the optimized version of the currently installed version of the client.

2. The cloud storage client hot upgrade method according to claim 1, characterized in that: Before building the target cross-process connection, it also includes: Access the target image repository based on the preset update check time; Determine whether the target update package corresponding to the currently installed version of the client exists in the target image repository; If the target update package exists in the target image repository, the target update package is obtained from the target image repository; the client version corresponding to the target update package is an optimized version of the currently installed version; A new daemon process and a new service process are constructed based on the target update package.

3. The cloud storage client hot upgrade method according to claim 2, characterized in that: The determining whether the target update package corresponding to the currently installed version of the client exists in the target image repository includes: Comparing the version information of all client update packages in the target image repository with the version information of the currently installed version using a target package management tool or based on a target transmission protocol to determine whether there is an update package to be verified corresponding to the optimized version of the currently installed version; If the update package to be verified exists, version compatibility verification and security verification are performed on the update package to be verified; the security verification includes digital signature verification and hash value comparison; If the update package to be verified passes the version compatibility verification and the security verification, the update package to be verified is determined as the target update package corresponding to the currently installed version of the client.

4. The cloud storage client hot upgrade method according to claim 2, characterized in that: The obtaining the target update package from the target image repository includes: Determine target network bandwidth; The target update package is obtained from the target image repository using target multi-thread download technology based on a breakpoint resume mechanism and the target network bandwidth.

5. The cloud storage client hot upgrade method according to claim 1, characterized in that: The build targets are linked across processes, including: Using the target component, establish target communication connections between the old daemon process and the old service process, between the new daemon process and the new service process, between the old daemon process and the new daemon process, and between the old service process and the new daemon process respectively; Initializing the target communication connection between the old daemon process and the old service process using the target device file to generate a target mount file descriptor; A dual-process collaboration architecture is constructed during the hot upgrade process, and a target cross-process connection is constructed based on the dual-process collaboration architecture, the target protocol family, and the initialized target communication connection.

6. The cloud storage client hot upgrade method according to claim 1, characterized in that: The processing of the second user space request that has not been processed by the old service process based on the intermediate state file includes: Parsing the intermediate state file to obtain corresponding parsing results; Restoring the working state of the old service process based on the analysis result to adjust the working state of the new service process; The new service process with the adjusted working state is used to process the second user space request that has not been completely processed by the old service process.

7. The cloud storage client hot upgrade method according to any one of claims 1 to 6, characterized in that: Also includes: If the updated client meets the preset version rollback condition, the client is rolled back based on the pre-reserved old service process, old daemon process and intermediate state file.

8. A cloud storage client hot upgrade device, characterized in that: Applied to the client, including: a first request processing module, configured to establish a target inter-process connection, and transfer a target mount file descriptor from the old daemon process to the new daemon process by using the target inter-process connection, so as to obtain a first user space request sent by the kernel based on the target mount file descriptor by using the new daemon process; an intermediate file saving module, configured to use the new daemon process to send a target request takeover signal to the old service process, and save the intermediate state file generated by the old service process based on the target request takeover signal to the local client; a second request processing module, configured to use the new service process to call the intermediate state file and obtain the target mount file descriptor from the new daemon process, so as to use the new service process to process the first user space request based on the target mount file descriptor, and to process the second user space request that has not been completed by the old service process based on the intermediate state file; The old service process and the old daemon process are service processes and daemon processes corresponding to the currently installed version of the client, and the new service process and the new daemon process are service processes and daemon processes corresponding to the optimized version of the currently installed version of the client.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the cloud storage client hot upgrade method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the cloud storage client hot upgrade method according to any one of claims 1 to 7 is implemented.

Images