Lock update method for distributed system, and electronic device and storage medium

Abstract

Disclosed in the present disclosure are a lock update method for a distributed system, and an electronic device and a storage medium. The method comprises: in response to a node receiving a state transition signal, determining the current lock holding state of the node, and determining a target lock holding state of the node on the basis of the state transition signal; on the basis of the current lock holding state and the target lock holding state, executing a lock update operation in the node, so as to obtain an execution result, wherein the execution result is used for indicating whether the node has successfully executed the lock update operation; and in response to the execution result indicating that the node has successfully executed the lock update operation, transitioning the current lock holding state to the target lock holding state, so as to obtain a lock update result. By means of the present disclosure, the technical problem in the related art of a relatively poor lock update effect in a distributed system is solved.

Description

Lock update methods, electronic devices, and storage media for distributed systems Technical Field

[0001] This disclosure relates to the fields of distributed technology and computer technology, and more specifically, to a lock update method for a distributed system, an electronic device, and a storage medium. Background Technology

[0002] In distributed systems, distributed locks serve as a core service, ensuring mutual exclusive access to shared resources by multiple nodes and maintaining data consistency. Each node's lock state indicates whether it can exclusively access shared data: holding the lock grants access rights, while releasing the lock relinquishes those rights to other nodes. Nodes communicate lock states through message passing mechanisms to determine subsequent actions, such as acquiring or releasing the lock.

[0003] However, when multiple nodes attempt to update the lock state simultaneously, the system faces the challenge of state inconsistency, known as "lock update conflict." When this occurs, one or more nodes may mistakenly believe they have exclusive access to the lock, leading to data conflicts or security issues. Because the update mechanism of distributed locks does not fully consider the impact of concurrent operations, the lock update performance in distributed systems using related technologies is poor, resulting in state update failures, data inconsistency, and decreased system stability.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This disclosure provides a lock update method, electronic device, and storage medium for a distributed system, to at least solve the technical problem of poor lock update performance in distributed systems in related technologies.

[0006] According to one aspect of the present disclosure, a lock update method for a distributed system is provided, applied to any node in the distributed system. The method includes: in response to a node receiving a state transition signal, determining the current lock holding state of the node, and determining a target lock holding state of the node based on the state transition signal; performing a lock update operation in the node based on the current lock holding state and the target lock holding state, and obtaining an execution result, wherein the execution result is used to indicate whether the node has successfully performed the lock update operation; in response to the execution result indicating that the node has successfully performed the lock update operation, transferring the current lock holding state to the target lock holding state, and obtaining a lock update result.

[0007] According to another aspect of the embodiments of this disclosure, a lock update method for a distributed system is also provided, applied to any node in the distributed system. The method includes: obtaining a state transition signal of a node in the distributed system by calling a first interface to determine the current lock holding state of the node, and determining a target lock holding state of the node based on the state transition signal, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the state transition signal; performing a lock update operation in the node based on the current lock holding state and the target lock holding state to obtain an execution result, wherein the execution result is used to indicate whether the lock update operation was successfully performed in the node; transferring the current lock holding state to the target lock holding state based on the execution result to obtain a lock update result; and outputting the lock update result by calling a second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the lock update result.

[0008] According to another aspect of the embodiments of this disclosure, a computer terminal is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in the various embodiments of this disclosure when it runs.

[0009] According to another aspect of the embodiments of the present disclosure, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of the various embodiments of the present disclosure.

[0010] According to another aspect of the embodiments of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this disclosure.

[0011] According to another aspect of the embodiments of this disclosure, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this disclosure.

[0012] According to another aspect of the embodiments of this disclosure, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this disclosure.

[0013] In this embodiment, in response to a node receiving a state transition signal, the node's current lock holding state is determined, and the target lock holding state is determined based on the state transition signal. Based on the current lock holding state and the target lock holding state, a lock update operation is performed on the node, yielding an execution result. This execution result indicates whether the node successfully performed the lock update operation. In response to the execution result indicating successful lock update, the current lock holding state is transitioned to the target lock holding state, resulting in a lock update result. This improves the lock update efficiency in the distributed system. It is noteworthy that the explicit state transition signal and accurate determination of the current lock holding state enable the node to update its lock state. Under this mechanism, when a node receives a state transition signal, it can perform a precise lock update operation based on its current lock holding state and the target lock holding state indicated by the signal. Through a unified signal-driven and state machine coordination mechanism, the inconsistency problem caused by multiple nodes simultaneously operating on the lock state is effectively avoided. Specifically, this disclosure ensures that all nodes undergo state transitions under the same instruction through global signal synchronization control, avoiding lock state conflicts caused by local information asynchrony. This guarantees the accuracy and consistency of the lock update process, significantly improving the effectiveness of lock updates and the overall stability of the distributed system. By controlling state transitions and lock update operations, it effectively coordinates the holding and releasing of locks in the distributed environment, enhancing the reliability and efficiency of the locking mechanism, thereby solving the technical problem of poor lock update performance in distributed systems in related technologies.

[0014] It is worth noting that the above general description and the following detailed description are merely for illustrative and explanatory purposes and do not constitute a limitation thereof. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0016] Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a lock update method for a distributed system according to an embodiment of the present disclosure.

[0017] Figure 2 is a structural block diagram of a computing environment according to an embodiment of the present disclosure;

[0018] Figure 3 is a structural block diagram of a service mesh according to an embodiment of the present disclosure;

[0019] Figure 4 is a flowchart of a lock update method for a distributed system according to an embodiment of the present disclosure;

[0020] Figure 5 is a schematic diagram of a centralized distributed lock online upgrade mechanism based on a finite state machine according to an embodiment of the present disclosure;

[0021] Figure 6 is a schematic diagram of a state machine according to an embodiment of the present disclosure;

[0022] Figure 7 is a schematic diagram of a loading partition according to an embodiment of the present disclosure;

[0023] Figure 8 is a schematic diagram of a centralized distributed lock upgrade process according to an embodiment of the present disclosure;

[0024] Figure 9 is a schematic diagram of a multi-active distributed lock degradation process according to an embodiment of the present disclosure;

[0025] Figure 10 is a schematic diagram of a state exit according to an embodiment of the present disclosure;

[0026] Figure 11 is a flowchart of a lock update method for a distributed system according to an embodiment of the present disclosure;

[0027] Figure 12 is a schematic diagram of a lock update device for a distributed system according to an embodiment of the present disclosure;

[0028] Figure 13 is a schematic diagram of a lock update device for a distributed system according to an embodiment of the present disclosure;

[0029] Figure 14 is a structural block diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] First, some nouns or terms that appear in the description of the embodiments of this disclosure shall be interpreted as follows:

[0033] Cloud file network storage is a cloud service designed to provide high-performance, highly reliable, and scalable file storage solutions. It simplifies the complexity of file storage, allowing users to focus on application development without worrying about the underlying storage details. It is suitable for scenarios requiring file sharing across multiple servers and elastic scaling of storage capacity and bandwidth, such as media processing, database backup, development and testing environments, and big data analytics.

[0034] Currently, the direct restart solution achieves phase switching by restarting the corresponding service. In cloud file storage, some service roles mainly perform background tasks or low-frequency operations, so restarting generally does not affect user requests. For such services, this disclosure chooses to upgrade the centralized distributed lock through direct restart. The current restart process is as follows: the cluster configuration is set to single-holding centralized distributed lock (holding the un-upgraded lock), i.e., the original logic; the cluster configuration is set to dual-holding centralized distributed lock (holding both the un-upgraded and upgraded locks) and multi-active distributed lock (holding the upgraded lock). After the settings are completed, the processes are restarted one by one to achieve phase switching; after confirming that the process restarts and is correctly configured, the cluster configuration is set to single-holding centralized distributed lock, and the processes are restarted one by one after the settings are completed. Finally, an operation and maintenance check is performed. The direct restart solution requires at least two process restarts, while the online upgrade solution designed in this disclosure does not require process restarts, avoiding multiple service interruptions.

[0035] According to embodiments of this disclosure, a lock update method for a distributed system is provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] The method embodiments provided in this disclosure can be executed in a mobile terminal, computer terminal, or similar computing device. Figure 1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a lock update method for a distributed system according to an embodiment of this disclosure. As shown in Figure 1, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. It will be understood by those skilled in the art that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the above-described electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in Figure 1, or have a different configuration than shown in Figure 1.

[0037] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in embodiments of this disclosure, the data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0038] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method in the embodiments of this disclosure. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the method in the above embodiments. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0040] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0041] The hardware structure block diagram shown in Figure 1 can serve as an exemplary block diagram not only for the aforementioned computer terminal 10 (or mobile device) but also for the aforementioned server. In an optional embodiment, Figure 2 illustrates an example using the computer terminal 10 (or mobile device) shown in Figure 1 as a computing node in the computing environment 201. Figure 2 is a structural block diagram of a computing environment according to an embodiment of the present disclosure. As shown in Figure 2, the computing environment 201 includes multiple computing nodes (such as servers) running on a distributed network (shown as 210-1, 210-2, ... in the figure). Each computing node contains local processing and memory resources, and the end user 202 can remotely run applications or store data in the computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 in the computing environment 201, representing services "A", "D", "E", and "H", respectively.

[0042] End user 202 can provide and access services through a web browser or other software application on a client. In some embodiments, the provisioning and / or requests of end user 202 can be provided to ingress gateway 230. Ingress gateway 230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 201).

[0043] The services are provided or deployed based on various virtualization technologies supported by the computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the machine is virtualized by a virtual machine, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance.

[0044] In one embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, as shown in Figure 2, service 220-2 can be equipped with one or more Pods 240-1, 240-2, ..., 240-N (collectively referred to as Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, ..., 242-M (collectively referred to as containers). One or more containers in a Pod handle requests related to one or more corresponding functions of the service. The proxy 245 typically controls service-related network functions such as routing and load balancing. Other services can also be equipped with similar Pods.

[0045] During operation, executing a user request from end user 202 may require calling one or more services in computing environment 201, and executing one or more functions of one service may require calling one or more functions of another service. As shown in Figure 2, service "A" 220-1 receives a user request from end user 202 from ingress gateway 230. Service "A" 220-1 can call service "D" 220-2, and service "D" 220-2 can request service "E" 220-3 to execute one or more functions.

[0046] The aforementioned computing environment can be a cloud computing environment, where resource allocation is managed by cloud services, allowing functionality development without needing to consider implementation, adjustment, or server scaling. This computing environment allows developers to execute event-responsive code without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically and independently scale, rather than scaling a single hardware device to handle potential loads.

[0047] In another alternative embodiment, FIG3 illustrates, in block diagram, an example of using the computer terminal 10 (or mobile device) shown in FIG1 above as a service mesh. FIG3 is a structural block diagram of a service mesh according to an embodiment of the present disclosure. As shown in FIG3, the service mesh 300 is mainly used to facilitate secure and reliable communication between multiple microservices. Microservices refer to decomposing an application into multiple smaller services or instances and distributing them across different clusters / machines.

[0048] As shown in Figure 3, a microservice may include application service instance A and application service instance B, which together form the functional application layer of service mesh 300. In one implementation, application service instance A runs as a container / process 308 on machine / workload container group 314 (Pod), and application service instance B runs as a container / process 310 on machine / workload container group 316 (Pod).

[0049] In one implementation, application service instance A can be a product query service, and application service instance B can be a product order placement service.

[0050] As shown in Figure 3, application service instance A and grid proxy (sidecar) 303 coexist in machine / workload container group 314, and application service instance B and grid proxy 305 coexist in machine / workload container group 316. Grid proxy 303 and grid proxy 305 form the data plane layer of service mesh 300. Grid proxy 303 and grid proxy 305 run as containers / processes 304 and 306 respectively, and can receive requests 312 for product query services. Grid proxy 303 and application service instance A can communicate bidirectionally, and grid proxy 305 and application service instance B can also communicate bidirectionally. Furthermore, grid proxy 303 and grid proxy 305 can also communicate bidirectionally with each other.

[0051] In one implementation, traffic from application service instance A is routed to the appropriate destination via mesh proxy 303, and network traffic from application service instance B is routed to the appropriate destination via mesh proxy 305. It should be noted that the network traffic mentioned here includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), high-performance, general-purpose open-source frameworks (Google Remote Procedure Call, gRPC), and open-source in-memory data structure storage systems (Redis).

[0052] In one implementation, the functionality of the extended data plane layer can be achieved by writing custom filters for the proxy (Envoy) in service mesh 300. The service mesh proxy configuration can enable the service mesh to correctly proxy service traffic, achieving service interoperability and service governance. Mesh proxies 303 and 305 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability.

[0053] As shown in Figure 3, the service mesh 300 also includes a control plane layer. This control plane layer can consist of a set of services running in a dedicated namespace, managed by a managed control plane component 301 within machine / workload container groups (machine / Pods) 302. As shown in Figure 3, the managed control plane component 301 communicates bidirectionally with mesh agents 303 and 305. The managed control plane component 301 is configured to perform control and management functions. For example, it receives telemetry data from mesh agents 303 and 305 and can further aggregate this telemetry data. The managed control plane component 301 can also provide a user-facing Application Programming Interface (API) for these services, facilitating easier manipulation of network behavior and providing configuration data to mesh agents 303 and 305.

[0054] In the above operating environment, this disclosure provides a lock update method for a distributed system as shown in Figure 4. Figure 4 is a flowchart of a lock update method for a distributed system according to an embodiment of this disclosure. As shown in Figure 4, the method includes:

[0055] Step S402: In response to the node receiving the state transition signal, determine the node's current lock holding state, and determine the node's target lock holding state based on the state transition signal;

[0056] In distributed system control, the aforementioned state transition signal is a signal used to indicate changes in system state or behavior. It can be sent by the system administrator or control node to coordinate the behavior of each node in the system.

[0057] The current lock holding state mentioned above refers to the actual holding status of the distributed lock when the node receives the state transition signal. This can include holding no lock, holding only a centralized distributed lock, holding only a multi-active distributed lock, or holding both a centralized distributed lock and a multi-active distributed lock.

[0058] The target lock holding state mentioned above refers to the lock holding state that a node is expected to transition to based on the state transition signal. This state transition is a crucial control point for the lock management system during the distributed system upgrade process. It can include holding no lock, holding only a centralized distributed lock, holding only a multi-active distributed lock, or holding both a centralized distributed lock and a multi-active distributed lock simultaneously.

[0059] In one alternative embodiment, when a node receives a signal indicating a change in lock state, the system first identifies the node's current state of holding the distributed lock, and then determines the lock holding state to which it should transition based on the signal. These steps form the starting point for lock state transitions, ensuring that the node has a clear understanding of its own lock state and a clear target for the state transition before updating its lock state.

[0060] For example, when the signal is 1, it means that the node needs to enter a dual-lock holding state (holding both a centralized distributed lock and a multi-active distributed lock simultaneously). If the current node only holds a centralized distributed lock, then the target state is to hold both types of locks simultaneously.

[0061] Step S404: Based on the current lock holding state and the target lock holding state, perform a lock update operation in the node and obtain the execution result;

[0062] The execution result indicates whether the node successfully performed the lock update operation.

[0063] In a distributed system, the lock update operation described above is a lock acquisition, release, or transition operation performed in response to a state transition signal. The result of this operation indicates whether a node can successfully hold or release the lock according to the target state.

[0064] The above execution result is the result of the lock update operation, reflecting whether the node lock state transition was successful, and is used for subsequent state judgment and control.

[0065] In one alternative embodiment, a corresponding lock update operation can be performed based on the node's current and expected lock holding states, such as attempting to acquire a new lock or release an old lock. The above steps are crucial for lock state transitions; by executing specific lock update operations, the node attempts to transition from its current lock holding state to a target lock holding state, while simultaneously monitoring the result of the operation.

[0066] For example, during the dual-lock holding phase, a node needs to acquire both a centralized distributed lock and a multi-active distributed lock simultaneously. If the current node already holds a centralized distributed lock, it will attempt to acquire a multi-active distributed lock. If the operation succeeds, it will enter the dual-lock holding state; otherwise, it will remain in the centralized distributed lock holding state.

[0067] Step S406: In response to the execution result that the node has successfully performed the lock update operation, the current lock holding state is transferred to the target lock holding state, and the lock update result is obtained.

[0068] The lock update result described above is the state after the node lock holding state is successfully updated according to the state transition signal and the execution result. It is a direct reflection of the effectiveness of the online lock upgrade mechanism.

[0069] In one optional embodiment, if the lock update operation is successful, the node formally enters the target lock holding state, completing a state transition. The above steps are confirmation steps for the lock state transition, ensuring that the node only changes its lock holding state upon successful operation, thereby avoiding uncertainties and errors during the state transition process.

[0070] For example, if a node successfully acquires a multi-active distributed lock, its state changes from holding only a centralized distributed lock to holding both a centralized distributed lock and a multi-active distributed lock, marking a key success point in the state transition.

[0071] The above process constitutes the execution flow of the distributed lock online upgrade mechanism. From receiving the state transition signal and determining the state transition target, to executing the lock update operation and confirming the state transition based on the result, a closed-loop control mechanism is formed, ensuring the smooth transition of lock states and data security in the distributed system. Through this mechanism, the distributed system can effectively upgrade its lock type online without interrupting service, significantly improving the efficiency of system upgrades and user experience, while ensuring data consistency, avoiding abnormal scenarios such as "dual holding of a lock," and enhancing the reliability and stability of the system.

[0072] By introducing explicit state transition signals and a Finite State Machine (FSM) coordination mechanism, data consistency is ensured during lock type upgrades in distributed systems. Specifically, avoiding "dual-holding of a lock" (i.e., two different nodes simultaneously holding the lock on the same resource) hinges on ensuring the orderliness and atomicity of state transitions, even in environments with concurrent operations across multiple nodes. The following key steps in the upgrade process visually illustrate this process:

[0073] Initial state: All nodes hold only unupgraded locks.

[0074] Upon receiving a state transition signal (e.g., signal 1), the target state is dual-holding of an unupgraded lock and an upgraded lock.

[0075] The node first attempts to acquire the upgraded lock. If successful, it enters a temporary state of "holding the unupgraded lock and attempting to acquire the upgraded lock". If it fails, the node remains in the initial state and will not perform any further operations.

[0076] In the temporary state, the node further attempts to maintain the unupgraded lock and tries to acquire the upgraded lock. If successful, it officially enters the double-lock holding state; if it fails or the unupgraded lock is lost, the node rolls back to the initial state.

[0077] Upon receiving a subsequent state transition signal (e.g., signal 3), the target state changes to holding only the upgraded lock.

[0078] When a node is in a double-lock state, it begins attempting to release the unupgraded lock. If the unupgraded lock is successfully released, the node enters a state where it only holds the upgraded lock; if the release fails or the upgraded lock is lost, the node reverts to the double-lock holding state.

[0079] In the above process, the FSM mechanism and unified signal control ensure the orderliness and atomicity of state transitions. That is, all nodes perform state transitions according to unified signal instructions, and there is clear logical control for the transitions between each state. In this way, even in a multi-node concurrent environment, the logical design of the state transitions ensures that only one node can successfully acquire or release the lock at any given time, thereby avoiding the abnormal situation of "double-holding a lock".

[0080] For example, suppose a distributed system has two nodes, A and B. Resource partition P is initially held by node A with a non-upgraded lock. When the system decides to upgrade the non-upgraded lock to an upgraded lock, a state transition signal is broadcast, and all nodes receive signal 1. Nodes A and B simultaneously attempt to acquire the upgraded lock. Due to the uniqueness of the upgraded lock, if node A successfully acquires the upgraded lock, node B will fail. Node A enters a dual-lock holding state, while node B remains in a state holding only the non-upgraded lock until the system proceeds to the next state transition.

[0081] Under system control, node A further releases the unupgraded lock, entering a state holding only the upgraded lock. If releasing the unupgraded lock fails, node A will revert to the dual-lock holding state, waiting for the next state transition opportunity. Node B will not attempt to acquire the upgraded lock until it receives a further state transition signal; instead, it will operate with the unupgraded lock, thus avoiding the situation where two nodes simultaneously hold both types of locks.

[0082] In one alternative embodiment, the nodes in the distributed system act as the executing agents, first responding to a state transition signal. The state transition signal is an instruction issued by the system control center, instructing the node to transition from its current lock-holding state to another predetermined target state. Upon receiving the signal, the node first checks what type of distributed lock it currently holds (e.g., a centralized distributed lock or a multi-active distributed lock), and then, based on the signal's indication, determines the state it should transition to (e.g., a dual-lock holding state or a single-lock holding state). This process ensures that the node has an accurate understanding of its own state and a clear target for transition before executing the lock state transition.

[0083] After determining the current lock holding state and the target lock holding state, the node begins to execute the specific lock update operation. This operation may involve acquiring a new lock, releasing an old lock, or simultaneously acquiring and releasing a lock to achieve a lock type conversion. The node performs the corresponding lock operation based on its current lock holding state and the expected target state. Upon completion of the operation, an execution result is obtained, indicating success or failure, to determine whether the node has successfully updated the lock state as expected.

[0084] Finally, based on the result of the lock update operation, if the node successfully executes the lock update operation, its current lock holding state will officially transition to the target lock holding state. The result of this transition process is the lock update result. A successful transition means that the node has completed the lock update according to the expected state transition signal, thereby realizing the online upgrade or downgrade of the distributed lock type.

[0085] A closed-loop control mechanism, from signal reception and status assessment to operation execution and result confirmation, ensures the accuracy and efficiency of online upgrades for distributed locks. Through this mechanism, the system can smoothly and continuously change lock types without restarting nodes, avoiding service interruptions while maintaining data consistency and security, thus enhancing the reliability of the distributed system and the user experience.

[0086] Through the above steps, in response to a node receiving a state transition signal, the node's current lock holding state is determined, and the target lock holding state is determined based on the state transition signal. Based on the current and target lock holding states, a lock update operation is performed on the node, yielding an execution result indicating whether the node successfully executed the lock update operation. In response to the execution result indicating successful lock update, the current lock holding state is transitioned to the target lock holding state, resulting in a lock update result. This improves the lock update efficiency in the distributed system. It's noteworthy that the explicit state transition signal and accurate determination of the current lock holding state enable nodes to update their lock states. Under this mechanism, precise lock update operations can be performed based on the node's current lock holding state and the target lock holding state indicated by the signal. Through a unified signal-driven and state machine coordination mechanism, the inconsistency problem caused by multiple nodes simultaneously operating on lock states is effectively avoided. Specifically, this disclosure ensures that all nodes undergo state transitions under the same instruction through global signal synchronization control, avoiding lock state conflicts caused by local information asynchrony. This guarantees the accuracy and consistency of the lock update process, significantly improving the effectiveness of lock updates and the overall stability of the distributed system. By controlling state transitions and lock update operations, it effectively coordinates the holding and releasing of locks in the distributed environment, enhancing the reliability and efficiency of the locking mechanism, thereby solving the technical problem of poor lock update performance in distributed systems in related technologies.

[0087] In the above embodiments of this disclosure, determining the target lock holding state of a node based on a state transition signal includes: determining the target lock holding state as a first lock holding state in response to a first transition signal, wherein the first lock holding state indicates that a first type of lock is stored in the node; determining the target lock holding state as a second lock holding state in response to a second transition signal, wherein the second lock holding state indicates that both a first type of lock and a second type of lock are stored in the node; and determining the target lock holding state as a third lock holding state in response to a third transition signal, wherein the third lock holding state indicates that a second type of lock is stored in the node.

[0088] The aforementioned first, second, and third transition signals are part of the distributed system's state control mechanism, used to instruct nodes how to change their lock holding state. Specifically, the first transition signal indicates that the node should enter a single-lock holding state, the second transition signal indicates that the node should enter a double-lock holding state, and the third transition signal indicates that the node should enter another single-lock holding state. This mechanism coordinates node state transitions through different signal types to adapt to the needs of distributed lock upgrades or downgrades.

[0089] The first type of lock mentioned above can be a centralized distributed lock, while the second type can be a multi-active distributed lock. In a distributed system, the choice of lock type directly affects the control method for resource access. Centralized distributed locks typically rely on a centralized service for lock allocation and management, while multi-active distributed locks allow lock management to be performed on multiple active service nodes, enhancing the system's disaster recovery capabilities and performance. Through an online upgrade mechanism, nodes can switch between different types of locks as needed to adapt to changes in system architecture or modification requirements.

[0090] When a node receives a specific state transition signal, it determines the target lock holding state based on the signal type. For example, upon receiving the first transition signal (signal 0), the node's target state is to hold only the first type of lock; upon receiving the second transition signal (signal 1), the target state is to hold both the first and second type of locks; and upon receiving the third transition signal (signal 3), the target state is to hold only the second type of lock.

[0091] The steps described above allow for the upgrading or downgrading of lock types in distributed systems without service interruption. Through signal-driven state machine transitions, nodes can smoothly transition from one lock type to another, thereby improving system architecture or enhancing disaster recovery capabilities while maintaining continuous service availability.

[0092] For example, in a lock upgrade scenario of a distributed system, the system may only use the first type of lock for resource scheduling. When the system detects an increase in disaster recovery requirements, the operations and maintenance team will issue a second transition signal (signal 1), instructing all nodes to enter a dual-lock holding state, that is, simultaneously acquiring the first type of lock and the second type of lock. This state transition operation does not require restarting the nodes. After receiving the signal, the nodes will attempt to acquire the second type of lock while maintaining the first type of lock. If successful, the node will enter the dual-lock holding state. Subsequently, when the system has completed the deployment and verification of the second type of lock, the operations and maintenance team will issue a third transition signal (signal 3). At this time, the target state of the nodes is to hold only the second type of lock. Based on their current dual-lock holding state, the nodes will attempt to release the first type of lock and enter the state of holding only the second type of lock, completing the lock type upgrade.

[0093] The upgrade process of locks in a distributed system can be controlled by configuring signals, ensuring that the mutual exclusion and consistency of data access are not affected during the upgrade process, while avoiding the risk of interruption caused by multiple service restarts, thus improving upgrade efficiency and user experience.

[0094] In the above embodiments of this disclosure, based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, including: in response to the current lock holding state being a first lock holding state and the target lock holding state being a second lock holding state, controlling the node to acquire a second type of lock, and detecting whether the node simultaneously possesses a first type of lock and a second type of lock to obtain a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type of lock and a second type of lock, determining the execution result as the node successfully executing the lock update operation.

[0095] The first lock holding state mentioned above can refer to the lock holding state before the system upgrade, that is, the un-upgraded lock state, such as the state of holding only a centralized distributed lock. The second lock holding state mentioned above can refer to the target state that the node is expected to reach during the lock upgrade process, that is, the dual lock holding state, which means that the node needs to hold both the first type of lock and the second type of lock simultaneously.

[0096] Based on state transition signals, nodes attempt to change their lock holding state, including acquiring a new lock, releasing an old lock, or both simultaneously. The execution result reflects the success or failure of the lock update operation and is used to determine subsequent state transition actions.

[0097] The first detection result mentioned above is the result of the node detecting whether it successfully holds both the first type of lock and the second type of lock during the execution of the lock update operation. This result is the key basis for judging whether the lock update operation is successful.

[0098] First, based on the first transfer signal, the node attempts to acquire the second type of lock, and after acquisition, checks whether it simultaneously holds both the first and second type of locks. If the first detection result shows that the node successfully holds both types of locks simultaneously, then the lock update operation can be determined to be successful. If the first detection result shows that the node does not simultaneously hold both types of locks, then the lock update operation can be determined to be unsuccessful.

[0099] Nodes can dynamically adjust their lock holding state at runtime without restarting, significantly reducing the possibility of service interruptions. The dual-lock phase ensures mutual exclusion of data access during the upgrade process, avoiding situations such as "double-holding a lock" that could lead to data inconsistencies. The first detection result serves as the criterion for determining the success or failure of the lock update operation, providing a mechanism to ensure the correctness and reliability of node state transitions.

[0100] For example, initially, all nodes in the system are in the first lock-holding state. When the system is ready to upgrade to the third lock-holding state, the signal driven by the system is first configured to 1 (the second transition signal), indicating that all nodes should enter the second lock-holding state. After receiving signal 1, the node begins to perform a lock update operation, attempting to acquire the second type of lock. If the node successfully acquires the second type of lock, it can perform a first check to check whether it simultaneously holds both the first and second type of locks. If the first check result is true, that is, the node does indeed hold both types of locks simultaneously, it means that the lock update operation is successful, and the node can continue with subsequent processing while maintaining the holding of both locks until the entire system completes the upgrade process.

[0101] By using finite state machines and signal-driven mechanisms, the system can be upgraded online and smoothly from one lock type to another, avoiding service interruptions while ensuring data security and consistency during the upgrade process. This significantly improves the upgrade efficiency and user experience of the distributed system.

[0102] In the embodiments disclosed above, based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, including: in response to the current lock holding state being a first lock holding state and the target lock holding state being a third lock holding state, the control node acquires a second type lock and detects whether the node simultaneously possesses a first type lock and a second type lock, obtaining a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type lock and a second type lock, the first lock holding state is transferred to the second lock holding state according to the received second transfer signal, and the second lock holding state is determined to be the current lock holding state; based on the node releasing the first type lock, the node is detected whether it has successfully released the first type lock, obtaining a second detection result; in response to the second detection result indicating that the node has successfully released the first type lock, the execution result is determined to be that the lock update operation was successfully performed on the node.

[0103] The aforementioned third lock holding state refers to the lock holding state that the node ultimately achieves in the distributed lock upgrade scenario. It is usually the state after the upgrade process is completed, where the node only holds the upgraded lock type, such as the second type lock.

[0104] The first detection result mentioned above is the result of checking whether the node holds both the first and second type locks after attempting to acquire the second type lock, and is used to verify whether the first phase of the lock update operation was successful.

[0105] The second detection result mentioned above is the result of the node performing the release operation of the first type of lock after the first detection result is confirmed, and checking whether the operation is successful. It is used to verify whether the second phase of the lock update operation is successful.

[0106] The above steps mainly describe the process of a node transitioning from a first-lock holding state to a third-lock holding state. This process can be divided into two main stages: first, attempting to acquire the second type of lock and verifying whether it has successfully entered a dual-lock holding state; second, executing the release of the first type of lock and verifying whether the release was successful; and finally ensuring that the node only holds the upgraded lock type.

[0107] When a node is in a state without an upgraded lock (current lock holding state is the first lock holding state), and the target state is to hold only the upgraded lock (third lock holding state), the node first attempts to acquire the second type of lock. Then, the node performs a first check to see if it simultaneously holds both the first and second type of locks. If the check is true, the node has successfully entered a dual-lock holding state, indicating that the first-phase lock update operation was successful. Next, based on the received second transition signal (i.e., the signal transitioning from the dual-lock state to the state of holding only the upgraded lock), the node transitions from the first lock holding state to the second lock holding state (i.e., the dual-lock holding state) and confirms that the dual-lock holding state is the current lock holding state. Then, based on the current dual-lock holding state, the node begins to release the first type of lock, while simultaneously performing a second check to see if the release of the first type of lock was successful.

[0108] If the second detection result is true, that is, the node has successfully released the first type of lock, the execution result is determined to be that the node has successfully performed the lock update operation. This means that the node ultimately only holds the second type of lock, that is, it has reached the third lock holding state.

[0109] For example, at the start of the distributed system, all nodes hold only type 1 locks (first lock holding state). The system administrator configures a signal of 1 (second transition signal), indicating that all nodes should enter a dual-lock holding state (second lock holding state), that is, simultaneously holding both type 1 and type 2 locks. Upon receiving signal 1, a node attempts to acquire the second type lock. If successful, the node performs a first check to verify whether it simultaneously holds both type 1 and type 2 locks. If the check result indicates simultaneous holding of both locks (first check result is true), then the first phase of the lock update operation is successful. Subsequently, the system administrator further configures a signal of 2 (third transition signal), indicating that the node should enter a state holding only type 2 locks (third lock holding state). Based on the current dual-lock holding state, the node begins to release the type 1 lock. Once released successfully, the node performs a second check to confirm whether the type 1 lock has been successfully released. If the check result indicates that the type 1 lock has been successfully released (second check result is true), then the execution result is determined to be that the node has successfully performed the lock update operation, and the node now holds only the type 2 lock, completing the online upgrade of the lock type.

[0110] Nodes can smoothly upgrade from a single lock-holding state to a state holding only the upgraded lock at runtime without restarting, reducing the possibility of service interruption. The dual-lock phase ensures data consistency during the upgrade process, avoiding the "double-holding" problem and enhancing data security. Through signal-driven state machine control, the node's state transition process is traceable and controllable, ensuring the reliability and stability of lock upgrades.

[0111] The above steps not only avoid service interruptions and ensure mutual exclusion and consistency of data access, but also provide institutional guarantees through finite state machines and signal-driven mechanisms, ensuring the efficiency, reliability and stability of online lock type upgrades in distributed systems.

[0112] In the above embodiments of this disclosure, based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, including: in response to the current lock holding state being a third lock holding state and the target lock holding state being a second lock holding state, acquiring a first type of lock based on the node, and detecting whether the node simultaneously has a first type of lock and a second type of lock to obtain a first detection result; in response to the first detection result being that the node simultaneously has a first type of lock and a second type of lock, determining that the execution result is that the lock update operation was successfully performed on the node.

[0113] When a node is in a third-lock holding state (holding only a second-type lock), and the target state is a second-lock holding state (i.e., a dual-lock holding state, holding both a first-type lock and a second-type lock), the node begins attempting to acquire a first-type lock. After acquiring the first-type lock, the node performs a first check to see if it simultaneously holds both a first-type lock and a second-type lock. If the first check is true, the node has successfully entered a dual-lock holding state, marking the success of the first phase of the lock update operation. Finally, based on the first check being true, the execution result is determined to be that the node has successfully performed the lock update operation, meaning the node is now in a dual-lock holding state, laying the foundation for subsequent lock operations (such as releasing the old lock or completely switching to the new lock).

[0114] For example, in a lock degradation scenario in a distributed system, all server nodes initially hold only type 2 locks. The system administrator configures a signal of 0 (first transition signal), indicating that all nodes should enter a dual-lock holding state (second lock holding state), that is, simultaneously holding both type 1 and type 2 locks. Nodes respond to signal 0 and begin attempting to acquire the type 1 lock. Once acquired successfully, the node performs a first check to confirm whether it simultaneously holds both type 1 and type 2 locks. If the first check result is true, the node has successfully entered a dual-lock holding state, marking the successful execution of the first part of the lock update operation, laying the foundation for subsequent steps of releasing the type 2 lock and fully restoring to the type 1 lock.

[0115] Nodes can smoothly transition from holding only the upgraded lock to holding both locks at runtime, minimizing project disruptions. The dual-lock phase ensures data consistency during degradation, avoiding data inconsistencies or "double-holding" issues and enhancing data security. Through signal-driven state machine control, the node's state transition process is traceable and manageable, ensuring the reliability and stability of distributed lock degradation.

[0116] In the embodiments of this disclosure above, based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, including: in response to the current lock holding state being a third lock holding state and the target lock holding state being a first lock holding state, acquiring a first type lock based on the node, and detecting whether the node simultaneously possesses a first type lock and a second type lock to obtain a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type lock and a second type lock, transferring the third lock holding state to the second lock holding state according to the received second transfer signal, and determining the second lock holding state as the current lock holding state, releasing the second type lock based on the node, and detecting whether the node successfully releases the second type lock to obtain a third detection result; in response to the third detection result indicating that the node successfully releases the second type lock, determining the execution result as a successful lock update operation performed on the node.

[0117] The lock update operation described above is a change in the lock holding state based on the state transition signal, including acquiring a new lock, releasing the old lock, or both simultaneously, to achieve the target lock holding state.

[0118] The first detection result mentioned above is the result of whether the detection node successfully transitioned from holding only the upgraded lock (third lock holding state) to holding both the pre-upgrade and upgraded locks (second lock holding state) during the lock update operation.

[0119] The aforementioned second transfer signal is used to indicate that a node should transfer from a double-lock holding state (second lock holding state) to a state holding only the lock before the upgrade (first lock holding state).

[0120] The third detection result mentioned above is the result of checking whether the node successfully holds only the lock type before the upgrade (first type lock) after releasing the upgraded lock type (second type lock) in the dual-lock holding state.

[0121] In distributed lock degradation scenarios, firstly, based on the node's current state of holding only the second type of lock, an attempt is made to release the lock and check whether it has successfully entered a dual-lock holding state (i.e., simultaneously holding both the first and second type of locks). Secondly, after ensuring the node is successfully in a dual-lock holding state, the second type of lock is released, and a check is made to ensure it is successfully holding only the first type of lock. Through these steps, distributed lock type degradation can be smoothly achieved without restarting the node, reducing the possibility of service interruption. Simultaneously, the introduction of the dual-lock phase ensures data access consistency and security, avoiding situations such as "double-holding a lock" that could lead to data inconsistency or security issues. Furthermore, the use of state machines and signal-driven mechanisms provides controllability and traceability of state transitions, enhancing the stability and reliability of distributed system upgrades or degradation processes.

[0122] A third state, "simultaneously holding both type 1 and type 2 locks," is introduced into the lock update process. This stage ensures that during the upgrade from a non-upgraded lock to an upgraded lock, all running nodes must simultaneously hold both types of locks. Thus, before acquiring the upgraded lock, no node can release the non-upgraded lock independently, thereby avoiding the "dual-holding" problem.

[0123] By detecting whether a node simultaneously holds both Type 1 and Type 2 locks (i.e., the first detection result), we can ensure that during the upgrade process, the node will not retain both types of locks due to inconsistencies in state updates, thus avoiding data security risks. Once a dual-lock state is detected, we transfer the lock holding state from the third state to the second state based on the received second transition signal. At this stage, we determine that the node only holds the upgraded lock, and further ensure a smooth transition of lock types by releasing the Type 2 lock (i.e., the unupgraded lock).

[0124] The above-described double-lock detection and release process not only resolves potential conflicts during lock updates, but also ensures that nodes successfully release un-upgraded locks through a third detection result. This avoids resource occupation and conflicts caused by un-upgraded locks not being released correctly, thereby improving the overall stability and security of the distributed system during the lock upgrade process.

[0125] By establishing clear state transition logic and detection steps, the orderly execution of lock update operations is ensured, avoiding state inconsistencies caused by disordered lock update steps, and further guaranteeing the smoothness and controllability of lock upgrades in distributed systems.

[0126] For example, in a lock downgrade scenario in a distributed system, all nodes have successfully upgraded and hold only the second type of lock (third lock holding state). Now, due to some reason (such as performance update or architecture adjustment), the system needs to downgrade the distributed lock, causing the nodes to revert to holding only the first type of lock (first lock holding state). Responding to the second transition signal (signal 3), the node begins attempting to acquire the first type of lock and performs a first check to see if it has successfully entered a dual-lock holding state, i.e., simultaneously holding both the first and second type of locks. If the first check result is true, meaning the node has successfully held both lock types simultaneously, then the node's state machine will, according to the signal-driven mechanism, transition from the third lock holding state (holding only the second type of lock) to the second lock holding state (dual lock holding state), and confirm the dual lock holding state as the current state.

[0127] Next, based on the dual-lock holding state, the node further releases the second type of lock and performs a third check to see if it has successfully held only the first type of lock. If the third check result is true, meaning the node has successfully released the second type of lock and holds only the first type of lock, then it can be determined that the node has successfully performed the lock update operation, and the lock downgrade process is complete.

[0128] Nodes can perform lock type downgrade operations while running, avoiding service interruptions caused by restarts and ensuring service continuity. A dual-lock holding phase ensures data consistency during downgrades, preventing data access conflicts or security issues and enhancing data security. A signal-driven state transition mechanism provides controllability and traceability of operations, ensuring the reliability and stability of lock upgrades or downgrades.

[0129] For example, a node initially holds only the second type of lock, and the system needs to downgrade the distributed lock to holding only the first type of lock. The system administrator configures signal 2, instructing all nodes to acquire the first type of lock and enter a dual-lock holding state (i.e., simultaneously holding both the first and second type of locks). The node responds to signal 3 and begins attempting to release the second type of lock. Once the release is successful, the node performs a first check to confirm whether it has entered a dual-lock holding state. If the check shows that the node does indeed simultaneously hold both the first and second type of locks (the first check result is true), the node's state machine will, driven by the signal, transition from the state of holding only the second type of lock to the dual-lock holding state, and confirm the dual-lock holding state as the current state.

[0130] Then, based on the dual-lock holding state, the node further releases the second type of lock and performs a third check to see if it has successfully transitioned to holding only the first type of lock (i.e., successfully transitioning from the dual-lock holding state to holding only the first type of lock). If the third check result is true, meaning the node has successfully released the second type of lock and holds only the first type of lock, then the execution result can be determined as the node successfully performing the lock update operation, i.e., the distributed lock degradation process is successfully completed. This process not only avoids service interruption and ensures data access consistency and security, but also provides controllability and traceability of state transitions through finite state machines and signal-driven mechanisms, making the distributed lock degradation operation efficient, reliable, and smooth.

[0131] In the above embodiments of this disclosure, transferring the third lock holding state to the second lock holding state according to the received second transfer signal, and determining the second lock holding state as the current lock holding state, includes: transferring the node's third lock holding state to the second lock holding state according to the received second transfer signal; after a preset time interval from the time point of receiving the second transfer signal, detecting the distributed system to obtain a fourth detection result, wherein the fourth detection result is used to indicate whether multiple nodes in the distributed system have successfully transferred from the third lock holding state to the second lock holding state; and determining the second lock holding state as the current lock holding state in response to the first detection result indicating that multiple nodes in the distributed system have successfully transferred from the third lock holding state to the second lock holding state.

[0132] In the distributed lock update mechanism disclosed herein, the second transfer signal, the third lock holding state, the second lock holding state, and the fourth detection result constitute a signal-driven state transition process to ensure that all nodes in the distributed system can smoothly and safely transition from the current lock holding state to the new state without affecting the continuous operation of the system and the consistency of the data.

[0133] The aforementioned second transfer signal is used to indicate that the node is transferring from the third lock holding state to the second lock holding state.

[0134] The fourth detection result mentioned above is used to verify whether all nodes have successfully transitioned to the target lock-holding state (second lock-holding state) after the lock-holding state transfer is completed. This detection result is a key indicator for confirming the success of the overall lock update operation.

[0135] After receiving the second transition signal, a node begins attempting to transition from the third lock-holding state (holding only the second type of lock) to the second lock-holding state (holding both the first and second types of locks simultaneously). Using the time of receiving the second transition signal as the starting point, the system administrator or operations operator sets a preset time period. After this time period ends, the entire distributed system is checked to confirm whether all nodes have successfully transitioned from the state of holding only the second type of lock to the state of holding both the first and second types of locks simultaneously.

[0136] If the fourth detection result confirms that all nodes have successfully transitioned to the dual-lock holding state, then the second lock holding state (i.e., the state of simultaneously holding the first type of lock and the second type of lock) can be determined as the current lock holding state of all nodes.

[0137] For example, in a lock upgrade scenario of a distributed system, all nodes are currently in a third-type lock holding state (holding only second-type locks). The operations operator wants to upgrade the system to a dual-type lock holding state, where each node simultaneously holds both first-type and second-type locks, in order to proceed with the subsequent full second-type lock holding phase. A second transition signal is configured to instruct all nodes to enter the second-type lock holding state. Nodes respond to the signal and begin attempting to acquire second-type locks to achieve the dual-type lock holding state. After a preset time period (e.g., 5 minutes, not limited here, can be set according to actual conditions), the operations operator checks the entire system to observe whether all nodes have successfully entered the dual-type lock holding state, i.e., whether they simultaneously hold both first-type and second-type locks. If the fourth check shows that all nodes have successfully entered the dual-type lock holding state, then it can be confirmed that the second-type lock holding state is the current lock holding state of all nodes; that is, all nodes now simultaneously hold both first-type and second-type locks, laying a solid foundation for subsequent lock upgrade steps.

[0138] Through the above mechanism, the lock-and-hold upgrade process in the distributed system does not require service restarts, reducing service interruption time during the upgrade process and ensuring the continuity of system upgrades. The dual-lock holding phase avoids the risk of "double-holding a lock," ensuring the consistency and security of data access. The fourth detection result provides monitoring and verification of system state transitions, ensuring the integrity and consistency of state transitions.

[0139] In the above embodiments of this disclosure, the method further includes: in response to the execution result that the node has not successfully performed the lock update operation, performing a lock release operation on the node or other nodes in the distributed system other than the node based on a preset interface to obtain the operation result; and transferring the current lock holding state to the target lock holding state according to the operation result to obtain the lock update result.

[0140] The execution result mentioned above refers to the result after the node attempts to perform a lock update operation, including both success and failure.

[0141] The aforementioned preset interface is a special interface designed internally by the system. It is used to safely release the lock held by the node when the lock update operation fails, or to release the locks of other nodes in the distributed system when necessary, so as to avoid inconsistencies in system state or data access conflicts.

[0142] The above operation results are the results of lock release operations performed on nodes or other nodes in the system through preset interfaces. They are used to confirm whether the lock release was successful and to determine whether to continue the upgrade process or require further processing.

[0143] The lock update result described above represents whether the lock holding state of a node in the entire distributed system has successfully transitioned to the target lock holding state after a series of lock update operations, including possible lock release operations.

[0144] After a node attempts to execute a lock update operation, it checks the execution result to determine whether it has successfully transitioned from the current lock-holding state to the target lock-holding state. If the execution result indicates that the node has failed to execute the lock update operation, i.e., the lock update has failed, a lock release operation is performed on the node or other nodes in the system based on a preset interface to prevent data access conflicts or system state inconsistencies, thus obtaining the operation result. Based on the result of the lock release operation, it checks whether the lock-holding state of all nodes has been transitioned to the target lock-holding state, thus obtaining the lock update result.

[0145] For example, in a distributed lock upgrade scenario, suppose some nodes fail when attempting to transition from a state holding only a Type 1 lock (the current lock holding state) to a state holding both Type 1 and Type 2 locks (the target lock holding state). The system mechanism detects this result and identifies the lock update operation as a failure. At this point, the system will perform a lock release operation on the failed nodes based on a preset interface, for example, safely releasing the Type 1 lock to avoid the "dual-holding" problem and prevent data inconsistency. After the operation is completed, the system checks the result to confirm whether the lock holding state of all nodes has transitioned to the target state, i.e., the dual-lock holding state. If, after the lock release operation, the lock holding state of all nodes (including the failed nodes) has successfully transitioned to the target lock holding state, then the lock update result can be determined as successful, meaning the entire distributed system has upgraded from a state holding only a Type 1 lock to a state holding both Type 1 and Type 2 locks.

[0146] The above steps smoothly handle abnormal situations during lock updates, and lock release operations prevent data inconsistencies such as "double-holding of a lock," thus enhancing system security. They ensure that the lock holding state of all nodes remains consistent, avoiding global inconsistencies caused by abnormal lock states on some nodes in a distributed system. Even in the event of a lock update failure, lock release and state transitions minimize the impact on service continuity.

[0147] During the upgrade process, suppose some nodes fail to acquire the second type of lock due to network latency, hardware failure, or other reasons, resulting in a failed lock update operation. In this case, the system will detect that the node failed to perform the lock update operation. Based on a preset interface, it will release the first type of lock on these failed nodes. Simultaneously, it will check the entire system to confirm whether the lock holding state of all nodes except the failed nodes has been transferred to the target state. If all failed nodes successfully release the first type of lock, and all other nodes in the system except the failed nodes have successfully entered the dual-lock holding state, then the system will determine the lock update result as successful. This achieves the upgrade from holding only the first type of lock to holding both the first and second type of locks, laying the foundation for subsequent lock management operations.

[0148] This mechanism not only ensures the consistency and security of state transitions in the distributed system, but also improves the stability and reliability of lock update operations through exception handling and state reset, significantly reducing service interruption time and enhancing the overall performance and user experience of the distributed system.

[0149] In the above embodiments of this disclosure, after transferring the current lock holding state to the target lock holding state based on the execution result and obtaining the lock update result, the method further includes: determining the target type lock corresponding to the target lock holding state; and masking other types of locks besides the target type lock.

[0150] The target lock holding state described above is the lock holding state that a node expects to achieve after the distributed lock update operation is completed. This could be holding only the upgraded lock type, such as holding only the second type of lock; or it could be the downgraded lock holding state, such as holding only the first type of lock.

[0151] The target type lock mentioned above is the lock type corresponding to the target lock holding state, that is, the lock type that the node should hold after the lock update operation is completed.

[0152] The aforementioned shielding refers to an isolation or disabling operation performed on lock types that are no longer needed after a distributed lock update operation is completed, in order to ensure that subsequent operations in the system only affect the target type of lock and are not affected by other types of locks.

[0153] After the lock update operation is completed, meaning the current lock holding state has successfully transitioned to the target lock holding state, the target lock type to be held in the system is determined based on the target lock holding state. Locks of other types besides the target lock type are masked to prevent subsequent operations from affecting or interfering with the updated target lock type, thus maintaining the logical consistency of the system.

[0154] For example, in a lock update scenario of a distributed system, if the target lock holding state is holding only a second type of lock (multi-live lock), then the target type lock is the second type lock. Once all nodes have successfully transitioned from a dual-lock holding state to a state holding only the second type of lock, the system administrator will determine the second type lock as the target type lock. To ensure system consistency and stability, the system administrator will then perform a masking operation on the first type of lock (the original state lock), that is, disable the first type of lock at the system level. This ensures that subsequent lock operations (such as allocation, release, and update) only target the second type of lock and do not affect the first type of lock, avoiding confusion in lock operations and potential data inconsistency issues.

[0155] The masking operation ensures that all nodes are only affected by the target lock type after a lock update, avoiding lock type confusion and maintaining the logical consistency of the distributed system. Subsequent lock operations (such as allocation and release) are only performed on the target lock type, improving the efficiency and accuracy of lock operations. By masking lock types that are no longer needed, the potential attack surface is reduced, enhancing the security of the distributed system.

[0156] In the above embodiments of this disclosure, the method further includes: in response to the execution result that the node has failed to perform the lock update operation, performing a rollback operation on the node based on the current lock holding state and the target lock holding state.

[0157] The above execution results are the results after the node performs the distributed lock update operation, including whether it successfully transitions from the current lock holding state to the target lock holding state.

[0158] The aforementioned rollback operation is an operation performed by the system to restore the node to its original lock-holding state or a more stable state when the execution result indicates that the node has failed to perform the lock update operation.

[0159] When the system detects that the node has failed to perform the lock update operation, it will execute a rollback operation based on the node's current lock holding state and the expected target lock holding state. The goal of the rollback operation is to ensure that the node is restored to a stable and secure lock holding state, avoiding system performance degradation or data consistency issues caused by the uncertainty of the lock holding state.

[0160] For example, in a lock upgrade scenario in a distributed system, if the target lock holding state is holding only the second type of lock, and some nodes fail to transition from a dual-lock holding state (holding both the first and second type of locks simultaneously) to a state holding only the second type of lock, the system will perform a rollback operation on these nodes. The rollback operation may involve releasing the second type of lock and retrying to acquire the first type of lock, ensuring that the nodes return to a dual-lock holding state or a state holding only the first type of lock to maintain system stability and data consistency. System administrators can set a signal to indicate the rollback operation (e.g., set it to 0) and observe whether all nodes successfully roll back to a stable lock holding state.

[0161] When a lock update operation fails, the rollback mechanism can quickly restore the node to a more stable state, preventing overall system performance degradation due to abnormal lock holding states of some nodes. The rollback operation ensures data access consistency and security, preventing data conflicts or anomalies caused by inconsistent lock states. Through rollback operations based on signals and the current lock holding state, system administrators can flexibly handle lock update issues without restarting nodes, improving operational flexibility and efficiency.

[0162] For example, the signal can be configured to be 2, instructing all nodes to transition from a dual-lock holding state (holding both type 1 and type 2 locks simultaneously) to a target state holding only type 2 locks, thus completing the distributed lock upgrade. If, during the transition, some nodes fail to release the type 1 lock and hold only type 2 locks due to network latency, hardware failure, or other reasons, the system will detect this result, indicating that the node failed to perform the lock update operation. The system will immediately perform a rollback operation on these nodes, which may include releasing the type 2 lock and attempting to reacquire the type 1 lock, ensuring that the nodes return to a stable state of dual-lock holding or holding only type 1 locks. The system administrator can confirm whether all nodes have successfully rolled back to a stable and consistent lock holding state by observing the fourth detection result. Once all nodes have successfully rolled back, the system administrator can consider restarting the nodes or reconfiguring the signal to retry the lock holding state upgrade, ensuring the ultimate success of the distributed lock update operation while guaranteeing the stability and data consistency of the system throughout the upgrade process. This mechanism demonstrates the important role of technological innovation in handling complex state transition problems in distributed systems, improving the reliability and efficiency of lock update operations.

[0163] In the embodiments disclosed above, a rollback operation is performed on a node based on the current lock holding state and the target lock holding state, including: in response to the current lock holding state being a first lock holding state and the target lock holding state being a second lock holding state, rolling the node back to the first lock holding state; in response to the current lock holding state being a first lock holding state and the target lock holding state being a third lock holding state, releasing a second type of lock by the node to obtain a first release result, and in response to the first release result indicating that the node has successfully released the second type of lock, rolling the node back to the first lock holding state; in response to the current lock holding state being a third lock holding state and the target lock holding state being a second lock holding state, rolling the node back to the third lock holding state; in response to the current lock holding state being a third lock holding state and the target lock holding state being a first lock holding state, releasing a first type of lock by the node to obtain a second release result, and in response to the second release result indicating that the node has successfully released the first type of lock, rolling the node back to the third lock holding state.

[0164] If the current lock holding state does not match the target lock holding state, and the current state is the first lock holding state (e.g., holding only the first type of lock) and the target state is the second lock holding state (e.g., holding both locks), then the node state is directly rolled back to the first lock holding state, that is, the current state remains unchanged.

[0165] If the current lock holding state is the first lock holding state, and the target state is the third lock holding state (e.g., holding only the second type of lock), then the second type of lock needs to be released based on the node, and the result of the first release needs to be checked. If the node successfully releases the second type of lock, then the node state is rolled back to the first lock holding state (e.g., holding only the first type of lock).

[0166] If the current lock holding state is the third lock holding state and the target state is the second lock holding state, then the node state will be rolled back to the third lock holding state. This usually means keeping the current state unchanged or making appropriate state adjustments to ensure the consistency of the system.

[0167] If the current lock holding state is the third lock holding state and the target state is the first lock holding state, then the first type of lock needs to be released based on the node, and the second release result needs to be checked. If the node successfully releases the first type of lock, then the node state is rolled back to the third lock holding state (e.g., holding only the second type of lock).

[0168] For example, in a lock upgrade scenario of a distributed system, when the goal is to upgrade all nodes from the first lock-holding state (holding only the first type of lock) to the second lock-holding state (holding both the first and second type of locks), if some nodes fail to acquire the second type of lock, the system will detect this and perform a rollback operation. For these nodes, rollback means maintaining the holding of the first type of lock, i.e., returning to the first lock-holding state. If the goal is to upgrade from the first lock-holding state to the third lock-holding state (holding only the second type of lock), but some nodes fail when trying to acquire the second type of lock, the system will instruct the nodes to release the second type of lock. Here, the node used to release the second type of lock can be the failed node or any other node; there is no limitation here. The system checks the result of the first release. If the release is successful, the node will roll back to the state of holding only the first type of lock, i.e., the first lock-holding state, and wait for subsequent operations or a restart. If the goal is to downgrade from a third-lock holding state (holding only a second-type lock) to a second-lock holding state (dual-lock holding state) or a first-lock holding state (holding only a first-type lock), and some nodes are unable to release the second-type lock, the rollback operation may involve maintaining the second-type lock holding state unchanged, i.e., remaining in the third-lock holding state, or making appropriate adjustments to ensure system state consistency. When the goal is to downgrade from a third-lock holding state (holding only a second-type lock) to a first-lock holding state (holding only a first-type lock), if some nodes fail to successfully release the first-type lock, the system will check the second release result. If the first-type lock release is successful, the nodes will roll back to the state of holding only the second-type lock, i.e., the third-lock holding state, maintaining the consistency of other nodes in the system.

[0169] By following the steps above, the consistency of lock holding states across all nodes is ensured. Even if a lock update operation fails, a stable and consistent state can be restored through a rollback operation. This avoids data security issues caused by inconsistent lock holding states, such as the risk of "dual holding of a single lock." The rollback operation can be flexibly executed based on different combinations of the current and target lock holding states, improving the controllability and flexibility of lock update operations.

[0170] For example, nodes initially all hold a first-type lock (holding only a first-type lock). A signal can be set to 1 to instruct all nodes to enter a second-type lock holding state (holding both first-type and second-type locks simultaneously). If some nodes fail to acquire a second-type lock, these nodes will perform a rollback operation based on their current lock holding state (holding only a first-type lock) and the target lock holding state (holding both first-type and second-type locks simultaneously), maintaining their first-type lock holding state and awaiting further intervention or a retry of the upgrade operation. On the other hand, suppose the system administrator wants to downgrade all nodes from a third-type lock holding state (holding only a second-type lock) to a first-type lock holding state. During attempts to release the first-type lock, if some nodes fail, they will perform a rollback operation, maintaining their second-type lock holding state, thus maintaining the consistency and stability of the lock holding state in the system.

[0171] This mechanism demonstrates the importance of technological innovation in the field of distributed systems. It not only improves the efficiency and reliability of lock update operations, but also enhances the overall performance and user experience of distributed systems by ensuring state consistency and data security.

[0172] The master-slave model is a common distributed system architecture pattern. In this model, the master node is responsible for coordinating and managing the allocation of resources throughout the system, while the slave nodes (servers) are responsible for loading the resources allocated by the master node. A common form of resource allocation in distributed systems is partitioning. Partitioning divides the data space into smaller blocks, allowing for the allocation and processing of data for specific tasks within the distributed system. Different partitions can be loaded by servers, enabling parallel processing of tasks. This architecture also ensures high availability; when a server fails, the master can schedule the failed server's partitions for normal servers to load and reprocess, thus achieving failover.

[0173] To ensure the mutual exclusion of partitions and the security of data during scheduling, distributed systems need to guarantee that a single partition is loaded and processed by only one server at a time to avoid conflicts during data writes. A centralized distributed lock is a common choice for achieving this. Servers must first "acquire" the lock for the corresponding partition before they are eligible to load or perform read / write operations on it. The centralized distributed lock provider guarantees that the same lock will not be issued to multiple servers.

[0174] The infrastructure of a distributed system can provide a wide range of distributed collaboration services, such as service normals, centralized distributed locks, and metadata management. As distributed systems iterate and upgrade, there may be a need to switch from one type of centralized distributed lock to another. For example, cloud file storage may need to upgrade its centralized distributed locks to multi-active distributed locks for disaster recovery. Centralized and multi-active distributed locks are implemented independently and without relation. Therefore, an incorrect upgrade process could result in different servers holding both types of centralized distributed locks, each with read and write rights to a partition, leading to the risk of "dual-holding of a lock." "Dual-holding of a lock" means that different servers can simultaneously read and write data on the same partition, potentially causing data security problems.

[0175] To achieve secure lock switching, this disclosure introduces a "dual-lock" phase. In this phase, the server needs to simultaneously acquire both the centralized distributed lock and the multi-active distributed lock corresponding to the partition. During the upgrade, the server needs to start from the phase of holding only the centralized distributed lock, then transition to the "dual-lock" phase, and finally gradually transition to the phase of holding the multi-active distributed lock. To ensure data security while avoiding service interruptions caused by restarts, this disclosure designs an online upgrade mechanism for centralized distributed locks based on a finite state machine. This mechanism achieves online upgrades while ensuring that abnormal scenarios such as "dual-holding of a single lock" do not occur during the upgrade, thus avoiding multiple service interruptions.

[0176] The core idea of ​​this disclosure is to maintain three phases: single-held centralized distributed lock, dual-held centralized distributed lock, and multi-active distributed lock. The online upgrade scheme is implemented using a Finite State Machine (FSM) and signal-driven mechanisms. The FSM can define multiple consecutive states between stages to cover possible cases, such as attempting to acquire a multi-active distributed lock while holding a centralized distributed lock. The signal-driven process needs a listener role to monitor external signals and uses the signal-driven state machine to perform state transitions.

[0177] Figure 5 is a schematic diagram of an online upgrade mechanism for a centralized distributed lock using a finite state machine according to an embodiment of this disclosure. As shown in Figure 5, the system may include an upgrade plan, a distributed lock (centralized distributed lock), and an upgrade distributed lock (multi-active distributed lock). The server node may include a scheduler, a lock manager, a listener, and a finite state automaton (DFA state machine). The listener in the server node polls the configuration file. The scheduler can call back a predefined function from the upgrade plan to determine the load partition. The scheduler can lock the DFA state machine, which can lock or unlock the lock manager. The lock manager can lock or unlock both the centralized distributed lock and the multi-active distributed lock. The listener can poll the configuration file, and when it detects a configuration signal from the configuration file, it can trigger the finite state automaton to perform a state transition via a trigger.

[0178] The plan represents the upgrade plan, which can be a signal from the operating system or a configuration from the operations and maintenance system, used to indicate the start of the lock upgrade or downgrade process. The server represents the service node running in the distributed system, responsible for executing tasks and holding the lock. The scheduler, as the server's scheduling module, decides to load or unload partitions by subscribing to the plan. The lock manager manages the acquisition and release of locks, operating centralized or multi-active distributed locks according to the state machine's instructions. The DFA State Machine is responsible for determining the actions of the lock management module based on received signals and the current state.

[0179] The Listener listens for configuration signals (such as signals on the cluster management system), triggers the signal to the state machine, and drives the state transition. The DFA State Machine and Lock Manager represent the state machine issuing instructions to acquire or release the lock according to the current state. The Lock Manager operates the lock according to these instructions, and the state machine also receives feedback to confirm the result of the instruction execution.

[0180] The state machine has multiple states, starting from Initial, progressing through different stages from attempting to acquire the lock to holding the lock, and then to unlocking, ultimately returning to the initial state or terminating in a single-lock state. State transitions are driven by semaphores (0, 1, 2, 3), ensuring that the server follows a predefined order in the lock escalation process, avoiding interruptions caused by directly restarting the service. The configuration file may store parameters related to the state machine, such as semaphore values, used for state machine initialization or as references during state transitions.

[0181] Figure 5 illustrates how key components collaborate throughout the upgrade process, and how the state machine controls lock acquisition and release via signal-driven mechanisms, ultimately achieving a centralized-distributed lock online upgrade mechanism without service interruption. This design ensures the reliability, continuity, and security of the upgrade process.

[0182] Signals are implemented by configuring cluster-level service flags. The Listener module polls the flags to identify the signal status. Three types of signals can be defined: signal 0, the state machine needs to enter the single-held centralized distributed lock state; signal 1, the state machine eventually enters the dual-held state, that is, it has both a centralized distributed lock and a multi-active distributed lock; signal 3, the state machine eventually enters the single-held multi-active distributed lock state.

[0183] Figure 6 is a schematic diagram of a state machine according to an embodiment of the present disclosure. As shown in Figure 6, the specific process is as follows:

[0184] State 0 (S0): Initialization.

[0185] This is the initial stage, the state before attempting to acquire the lock before loading the partition:

[0186] Upon receiving signal 0, the state transitions to state 1 (S1);

[0187] Upon receiving signal 1, the state transitions to state 5 (S5);

[0188] Upon receiving signal 3, the state transitions to state 6 (S6).

[0189] State 1: Attempting to acquire a centralized distributed lock.

[0190] Transition from state 0, attempting to preempt the centralized distributed lock:

[0191] Successfully acquired the centralized distributed lock, state transition to state 2 (S2);

[0192] If the centralized distributed lock is not acquired, the state will roll back to state 0.

[0193] State 6: Attempting to acquire a multi-active distributed lock.

[0194] Transitioning from state 0, attempting to preempt the multi-active distributed lock:

[0195] Successfully acquired the multi-active distributed lock, and transitioned to state 7 (S7);

[0196] Unable to acquire the multi-active distributed lock, the state rolls back to state 0.

[0197] State 5: Attempting to acquire a centralized distributed lock and a multi-active distributed lock.

[0198] Transition from state 0, attempting to simultaneously preempt both the centralized distributed lock and the multi-active distributed lock:

[0199] Successfully acquired both locks, state transition to state 4 (S4);

[0200] If no lock is acquired, the state reverts to state 0.

[0201] State 2: Holding a centralized distributed lock.

[0202] The terminated state, i.e., holding only a centralized distributed lock:

[0203] Upon receiving signal 1, the state transitions to state 3 (S3).

[0204] State 3: Attempting to acquire a multi-active distributed lock while holding a centralized distributed lock.

[0205] Given a centralized distributed lock, attempt to preempt a multi-active distributed lock:

[0206] Successfully acquired the multi-active distributed lock, and transitioned to state 4;

[0207] Unable to acquire the multi-active distributed lock, the state reverts to state 2.

[0208] State 7: Holding a multi-active distributed lock.

[0209] The terminated state, i.e., holding only a multi-active distributed lock:

[0210] Upon receiving signal 1, the state transitions to state 8 (S8).

[0211] State 8: Attempting to acquire a centralized distributed lock while holding a multi-active distributed lock.

[0212] If you already hold a multi-active distributed lock, attempt to preempt the centralized distributed lock:

[0213] Successfully acquired the centralized distributed lock, state transition to state 4;

[0214] Unable to acquire centralized distributed lock, state rollback to state 7.

[0215] State 4: Simultaneously holding both centralized distributed locks and multi-active distributed locks.

[0216] The terminated state refers to simultaneously holding both a centralized distributed lock and a multi-active distributed lock:

[0217] Upon receiving signal 0, the state transitions to state 10 (S10) to release the centralized distributed lock;

[0218] Upon receiving signal 3, the state transitions to state 9 (S9) to release the multi-active distributed lock.

[0219] State 10: Release the centralized distributed lock while holding a multi-active distributed lock.

[0220] While simultaneously holding both a centralized distributed lock and a multi-active distributed lock, attempt to release the centralized distributed lock:

[0221] Successfully released the centralized distributed lock, transitioned to state 2, and now holds the multi-active distributed lock;

[0222] Unable to release the centralized distributed lock, the state rolls back to state 4 to hold both the centralized distributed lock and the multi-active distributed lock.

[0223] State 9: Release the multi-active distributed lock while holding the centralized distributed lock.

[0224] When holding both a centralized distributed lock and a multi-active distributed lock, attempt to release the multi-active distributed lock.

[0225] Successfully released the multi-active distributed lock, and transitioned to state 7 (holding a centralized distributed lock);

[0226] Unable to release the multi-active distributed lock, the state reverts to state 4 (holding both a centralized distributed lock and a multi-active distributed lock).

[0227] The above steps explain the meaning of each state in the state machine and the state transition rules based on different received signals.

[0228] Figure 7 is a schematic diagram of a loading partition according to an embodiment of the present disclosure. As shown in Figure 7, the specific process is as follows:

[0229] In state 0 (S0), the method of acquiring the lock is determined based on the signal represented by the current signal flag (sem flag).

[0230] For example, a signal of 1 means that a partition can only be loaded after acquiring both a centralized distributed lock and a multi-active distributed lock.

[0231] Regardless of the service phase, if a failover occurs, the state transition always starts from state 0, without affecting the logic of loading partitions.

[0232] The initial state S0 is the preparation state of the node before loading the partition. In this state, the node will decide its next action based on the currently received signal (sem flag): whether to try to acquire a centralized distributed lock, acquire both a centralized distributed lock and a multi-active distributed lock simultaneously, or directly try to acquire a multi-active distributed lock.

[0233] Signal 0: The node will attempt to acquire only the centralized distributed lock (state S1). If successful, it will enter state S2 (holding only the centralized distributed lock). If unsuccessful, it will roll back to S0.

[0234] Signal 1: The node will attempt to acquire both the centralized distributed lock and the multi-active distributed lock simultaneously (state S5). If successful, it will enter state S4 (holding both the centralized distributed lock and the multi-active distributed lock simultaneously). If unsuccessful, it will roll back to S0.

[0235] Signal 3: The node will attempt to acquire only the multi-active distributed lock (state S6). If successful, it will enter state S7 (holding only the multi-active distributed lock). If unsuccessful, it will roll back to S0.

[0236] Figure 8 is a schematic diagram of a centralized distributed lock upgrade process according to an embodiment of the present disclosure. As shown in Figure 8, the specific process is as follows:

[0237] In step 0, the signal flag (sem flag) can be configured to be 0, which is the default behavior. It preempts the centralized distributed lock, as described in the partition loading process for state 0. If a node (Server) fails over during the process, it will still preempt the centralized distributed lock by default. That is, the failure will not result in a "double holding of a lock" situation.

[0238] Step 1: Configure the sem flag to 1, meaning it needs to preempt both the centralized distributed lock and the multi-active distributed lock. For partitions in state 2 (already holding the centralized distributed lock), the node transitions to state 3 (preempting the multi-active distributed lock). This action does not affect the partition's operational logic, including checking / renewing the lease. Depending on the result, the node transitions to state 4 or reverts to state 2. For example, in the partition loading process described as state 0, if a node fails over, it needs to preempt both the centralized and multi-active distributed locks. This ensures that the failover does not result in a "dual-holding" state; different service nodes are in different semaphore flags (0 or 1), and there will be no conflict with the behavior of service nodes with a semaphore flag of 0.

[0239] In step 1, it can be observed that the signal flags of all service nodes in the cluster become 1, there are no nodes with a signal flag of 0, and the centralized distributed lock and multi-active distributed lock of the partition are held by the same service node.

[0240] Step 2 allows configuring the sem flag to be 3, indicating a need to preempt the multi-active distributed lock. Service nodes in state 4 (dual-holding state) transition to state 9 (releasing the centralized distributed lock) for partitions. This action does not affect the partition's operational logic, including checking / renewing the lease. Depending on the result, the transition can proceed to state 7 or back to state 4. For example, in the partition loading process described for state 0, if a service node fails over and needs to preempt the multi-active distributed lock, different service nodes with different semaphore flags (1 or 3) will not conflict with the behavior of service nodes with semaphore flag 3.

[0241] Figure 9 is a schematic diagram of a multi-active distributed lock degradation process according to an embodiment of the present disclosure. As shown in Figure 9, the specific process is as follows:

[0242] Step 0 allows configuring the signal (sem) to be 3, which means that the multi-active distributed lock needs to be preempted. This is similar to the description of state 0 in the load partition process. During this process, if a server fails over, it needs to preempt the multi-active distributed lock, meaning that the failover will not result in a "dual-holding of a lock" state.

[0243] Step 1: Configure SEM to 1, meaning it needs to acquire both the centralized distributed lock and the multi-active distributed lock. For partitions in state 7 (already holding the multi-active distributed lock), the server transitions to state 8 (acquiring the centralized distributed lock). This action does not affect the partition's operational logic, including check / renew lease. Depending on the result, it transitions to state 4 or rolls back to state 7, as described in the load partition process for state 0. During this process, if a server fails over, it needs to acquire both the centralized and multi-active distributed locks. Different servers are in different SEM flags (1 or 3), and their behavior will not conflict with the server with SEM set to 3.

[0244] In step 1, it was observed that the sem flag of all cluster servers became 1, and there was no server with a sem flag of 3. The centralized distributed lock / multi-active distributed lock of the partition was held by the same server.

[0245] Step 2 can be configured with sem set to 0, meaning the server needs to acquire the centralized distributed lock. For partitions in state 4 (dual lock holding), the server performs an action to transition to state 10 (releasing the multi-active distributed lock). This action does not affect the partition's operational logic, including check / renew lease. Depending on the result, the server transitions to state 2 or rolls back to state 4, as described in the load partition process for state 0. During this process, if a server fails over and needs to acquire the centralized distributed lock, different servers will be in different sem flags (0 or 1), and this will not conflict with the behavior of servers with sem set to 0.

[0246] This disclosure aims to avoid "dual-holding of a lock," where the same partition is loaded by different servers, causing data security issues. Under a state machine mechanism, this means avoiding situations where different processes have SEM flags of 0 and 2 respectively (as this would cause different processes to compete for both the centralized and multi-active distributed locks). The SEM flag is configured by the operations team. Taking an upgrade as an example, switching from SEM flag 1 to 2 requires observation and verification for a certain period. Specifically, this involves confirming that all flags on the machines are consistent (i.e., all flags are signal 1); and confirming that the partition locks are held by the same process. For example, under SEM flag 1, the centralized and multi-active distributed locks are held by the same process. The dual-lock phase will not affect existing code logic, so the observation period can be extended.

[0247] The code requires exiting the lock for unexpected sem flags, specifically through polling, which only provides a partial fallback. After upgrading to a single-hold multi-active distributed lock, a masking function can be used to permanently disable the old centralized distributed lock.

[0248] Figure 10 is a schematic diagram of a state exit according to an embodiment of the present disclosure. As shown in Figure 10, when the signal in S2 is 3, the signal in S7 is 0, or any state implements the callback of any lock, the final result is exit. For unexpected signals, exit can be implemented through polling.

[0249] During the upgrade, if the preemption of the multi-active distributed lock fails, the server cannot load successfully, potentially resulting in deadlock or rollback. In a deadlock scenario, the centralized distributed lock and the multi-active distributed lock are held by service node A and service node B respectively, with both attempting to preempt the other lock. This seemingly deadlocked scenario can be handled manually by adding an interface to securely release one of the locks. Regarding rollback, after the upgrade, a failure of the multi-active distributed lock itself causes the preemption to fail, requiring a rollback. This is related to the currently configured signal flags. For steps 1 (where the current sem flag is 1), a quick rollback to sem 0 followed by a server restart is possible. For steps 2 (where the current sem flag is 2), a degradation process needs to be completed, with observation time in between.

[0250] This disclosure utilizes finite state machines and a signal-driven mechanism to construct an efficient online centralized distributed lock upgrade mechanism. Compared to traditional methods involving multiple restarts, this approach eliminates service interruptions caused by frequent restarts, ensuring the smoothness and continuity of system upgrades. The finite state machine allows for the definition of the states of different nodes in the distributed system, and flexibly adjusts the lock holding method according to the needs of different stages. The signal-driven mechanism provides a non-intrusive means to trigger transitions between different states, enabling the entire system to upgrade based on real-time responses.

[0251] The above methods not only improve the efficiency of the upgrade process and reduce the impact on user project continuity, but also significantly reduce the operational complexity of the system during upgrades. As the system scales and complexity increases, this disclosure provides a more intelligent and reliable solution for the management of centralized distributed locks.

[0252] This disclosure implements an efficient and flexible online centralized-distributed lock upgrade process by employing a finite state machine and a signal-driven mechanism. By introducing a dual-lock phase, it ensures that the server simultaneously holds both a centralized distributed lock and a multi-active distributed lock during the upgrade process, effectively avoiding the "dual-holding of a single lock" problem. This mechanism provides significant data security. Signal-driven operation enables dynamic state switching without requiring a server restart, ensuring the continuous availability of the distributed system during the upgrade and significantly reducing the risk of service interruptions. Furthermore, the flexible rollback mechanism and gradual state transitions provide strong support for the stability of the distributed system, ensuring seamless switching during the lock upgrade process and overall high availability.

[0253] This disclosure utilizes a finite state machine and signal-driven mechanism to implement an advanced and flexible online centralized distributed lock upgrade process. By introducing a dual-lock phase, it ensures that the server simultaneously holds both the lock service and the upgrade lock service during the upgrade process, effectively avoiding the "dual-holding" problem. This mechanism provides significant data security. Signal-driven operation enables dynamic state switching without restarting the service, ensuring continuous availability of the distributed system during upgrades and significantly reducing the risk of service interruptions. Furthermore, the flexible rollback mechanism and gradual state transitions provide strong support for the stability of the distributed system, ensuring seamless switching during the lock upgrade process and overall high availability.

[0254] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0255] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited to the described order of actions, because according to this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this disclosure.

[0256] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. Based on this understanding, the technical solutions of this disclosure, in essence, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this disclosure.

[0257] According to embodiments of this disclosure, a lock update method for a distributed system is also provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that presented here. Figure 11 is a flowchart of a lock update method for a distributed system according to an embodiment of this disclosure. As shown in Figure 11, the method includes:

[0258] Step S1102: Obtain the state transition signal of the node in the distributed system by calling the first interface, determine the current lock holding state of the node, and determine the target lock holding state of the node based on the state transition signal;

[0259] The first interface includes a first parameter, and the parameter value of the first parameter includes a state transition signal.

[0260] The aforementioned first interface can be an interface for data interaction between the cloud server and the client. It can pass the state transition signal into the interface function as the first parameter of the interface function, thereby achieving the purpose of uploading the state transition signal to the cloud server.

[0261] Step S1104: Based on the current lock holding state and the target lock holding state, perform a lock update operation in the node and obtain the execution result;

[0262] The execution result indicates whether the lock update operation was successfully performed on the node.

[0263] Step S1106: Based on the execution result, transfer the current lock holding state to the target lock holding state to obtain the lock update result;

[0264] Step S1108: Output the lock update result by calling the second interface.

[0265] The second interface includes a second parameter, the value of which includes the lock update result.

[0266] The aforementioned second interface can be an interface for data interaction between the cloud server and the client. The cloud server can pass the lock update result to the interface function as the second parameter of the interface function, thereby achieving the purpose of sending the lock update result to the client.

[0267] Through the above steps, the state transition signal of the node in the distributed system is obtained by calling the first interface to determine the current lock holding state of the node, and the target lock holding state of the node is determined based on the state transition signal. The first interface includes a first parameter, the value of which includes the state transition signal. Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain the execution result, which indicates whether the lock update operation was successfully performed on the node. Based on the execution result, the current lock holding state is transferred to the target lock holding state to obtain the lock update result. The lock update result is output by calling the second interface, which includes a second parameter, the value of which includes the lock update result. This improves the lock update effect in the distributed system. It is easy to note that the clear state transition signal and the accurate judgment of the current lock holding state enable the node to update the lock state. Under this mechanism, when a node receives a state transition signal, it can perform a precise lock update operation based on its current lock holding state and the target lock holding state indicated by the signal. This avoids the inconsistency problem caused by multiple nodes operating on the lock state simultaneously, thereby ensuring the accuracy and consistency of lock state updates. This significantly improves the effect of lock updates and the overall stability of the system in the distributed system. Through controlled state transitions and lock update operations, the holding and releasing of locks in the distributed environment are effectively coordinated, enhancing the reliability and efficiency of the lock mechanism. This solves the technical problem of poor lock update performance in distributed systems in related technologies.

[0268] According to an embodiment of this disclosure, a lock update device for a distributed system for implementing the above-described lock update method for a distributed system is also provided. FIG12 is a schematic diagram of a lock update device for a distributed system according to an embodiment of this disclosure. As shown in FIG12, the device 1200 includes: a determination module 1202, an execution module 1204, and a transfer module 1206.

[0269] The determination module is used to determine the current lock holding state of the node in response to the node receiving the state transition signal, and to determine the target lock holding state of the node based on the state transition signal; the execution module is used to perform a lock update operation in the node based on the current lock holding state and the target lock holding state, and obtain the execution result, wherein the execution result is used to indicate whether the node has successfully executed the lock update operation; the transition module is used to transition the current lock holding state to the target lock holding state in response to the execution result indicating that the node has successfully executed the lock update operation, and obtain the lock update result.

[0270] It should be noted that the aforementioned determining module 1202, execution module 1204, and transfer module 1206 correspond to steps S402 to S406 in the above embodiments. The three modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the aforementioned modules or units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned modules may also be part of a device and run in the computer terminal 10 provided in the above embodiments.

[0271] In the above embodiments of this disclosure, the determining module is used to determine the target lock holding state as a first lock holding state in response to a state transition signal being a first transition signal, wherein the first lock holding state indicates that a first type of lock is stored in the node; to determine the target lock holding state as a second lock holding state in response to a state transition signal being a second transition signal, wherein the second lock holding state indicates that both a first type of lock and a second type of lock are stored in the node; and to determine the target lock holding state as a third lock holding state in response to a state transition signal being a third transition signal, wherein the third lock holding state indicates that a second type of lock is stored in the node.

[0272] In the above embodiments of this disclosure, the execution module is used to control the node to acquire a second type of lock in response to the current lock holding state being a first lock holding state and the target lock holding state being a second lock holding state, and to detect whether the node simultaneously possesses a first type of lock and a second type of lock, thereby obtaining a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type of lock and a second type of lock, the execution result is determined to be that the node successfully performed the lock update operation.

[0273] In the above embodiments of this disclosure, the execution module is configured to, in response to the current lock holding state being a first lock holding state and the target lock holding state being a third lock holding state, control the node to acquire a second type of lock and detect whether the node simultaneously possesses a first type of lock and a second type of lock, thereby obtaining a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type of lock and a second type of lock, transfer the first lock holding state to the second lock holding state according to the received second transfer signal, determine the second lock holding state as the current lock holding state, release the first type of lock based on the node, and detect whether the node successfully releases the first type of lock, thereby obtaining a second detection result; in response to the second detection result indicating that the node successfully releases the first type of lock, determine the execution result as a successful lock update operation performed on the node.

[0274] In the above embodiments of this disclosure, the execution module is used to respond to the current lock holding state being a third lock holding state and the target lock holding state being a second lock holding state, to acquire a first type of lock based on the node, and to detect whether the node simultaneously has a first type of lock and a second type of lock, thereby obtaining a first detection result; in response to the first detection result being that the node simultaneously has a first type of lock and a second type of lock, the execution result is determined to be that the lock update operation was successfully performed on the node.

[0275] In the above embodiments of this disclosure, the execution module is configured to, in response to the current lock holding state being a third lock holding state and the target lock holding state being a first lock holding state, acquire a first type of lock based on the node, and detect whether the node simultaneously possesses a first type of lock and a second type of lock, thereby obtaining a first detection result; in response to the first detection result indicating that the node simultaneously possesses a first type of lock and a second type of lock, transfer the third lock holding state to the second lock holding state according to the received second transfer signal, and determine that the second lock holding state is the current lock holding state; release the second type of lock based on the node, and detect whether the node successfully releases the second type of lock, thereby obtaining a third detection result; in response to the third detection result indicating that the node successfully releases the second type of lock, determine that the execution result is that the lock update operation was successfully performed on the node.

[0276] In the above embodiments of this disclosure, the execution module is used to transfer the third lock holding state of a node to the second lock holding state according to the received second transfer signal; after a preset time interval from the receiving of the second transfer signal as the starting time point, the distributed system is detected to obtain a fourth detection result, wherein the fourth detection result is used to indicate whether multiple nodes in the distributed system have successfully transferred from the third lock holding state to the second lock holding state; in response to the first detection result indicating that multiple nodes in the distributed system have successfully transferred from the third lock holding state to the second lock holding state, the second lock holding state is determined as the current lock holding state.

[0277] In the above embodiments of this disclosure, the execution module is further configured to respond to the execution result that the node has failed to perform the lock update operation, perform a lock release operation on the node or other nodes in the distributed system other than the node based on a preset interface, and obtain the operation result; and transfer the current lock holding state to the target lock holding state according to the operation result, and obtain the lock update result.

[0278] In the above embodiments of this disclosure, the determining module is further configured to determine the target type lock corresponding to the target lock holding state; and to mask other types of locks besides the target type lock.

[0279] In the embodiments described above, the device further includes a rollback module.

[0280] The rollback module is used to perform a rollback operation on the node based on the current lock holding state and the target lock holding state when the execution result is that the node has failed to perform the lock update operation.

[0281] In the embodiments described above, the rollback module is further configured to: roll back the node to the first lock holding state in response to the current lock holding state being the first lock holding state and the target lock holding state being the second lock holding state; roll back the node to the first lock holding state in response to the current lock holding state being the first lock holding state and the target lock holding state being the third lock holding state, based on the node releasing the second type of lock to obtain a first release result, and roll back the node to the first lock holding state in response to the first release result indicating that the node has successfully released the second type of lock; roll back the node to the third lock holding state in response to the current lock holding state being the third lock holding state and the target lock holding state being the second lock holding state; and roll back the node to the third lock holding state in response to the current lock holding state being the third lock holding state and the target lock holding state being the first lock holding state, based on the node releasing the first type of lock to obtain a second release result, and roll back the node to the third lock holding state in response to the second release result indicating that the node has successfully released the first type of lock.

[0282] According to an embodiment of this disclosure, a lock update device for a distributed system for implementing the above-described lock update method for a distributed system is also provided. FIG13 is a schematic diagram of a lock update device for a distributed system according to an embodiment of this disclosure. As shown in FIG13, the device 1300 includes: a determination module 1302, an execution module 1304, a transfer module 1306, and an output module 1308.

[0283] The system comprises the following modules: a determination module, an execution module, and an output module. The first module obtains the state transition signal of a node in the distributed system by calling a first interface to determine the node's current lock holding state and the target lock holding state based on the state transition signal. The first interface includes a first parameter whose value includes the state transition signal. The execution module performs a lock update operation on the node based on the current and target lock holding states, obtaining an execution result indicating whether the lock update operation was successfully performed on the node. The transfer module transfers the current lock holding state to the target lock holding state based on the execution result, obtaining a lock update result. The output module outputs the lock update result by calling a second interface, which includes a second parameter whose value includes the lock update result.

[0284] It should be noted that the aforementioned determining module 1302, execution module 1304, transfer module 1306, and output module 1308 correspond to steps S1102 to S1108 in the above embodiments. The four modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the aforementioned modules or units may be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned modules may also be part of a device and run in the computer terminal 10 provided in the above embodiments.

[0285] It should be noted that the preferred embodiments involved in the above embodiments of this disclosure are the same as the solutions, application scenarios and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0286] Embodiments of this disclosure can provide an electronic device, which can be any one of a group of electronic devices. Optionally, in this embodiment, the aforementioned electronic device can also be replaced with a terminal device such as a mobile terminal.

[0287] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0288] In this embodiment, the computer terminal described above can execute the program code in the method.

[0289] Optionally, FIG14 is a structural block diagram of an electronic device according to an embodiment of the present disclosure. As shown in FIG14, the electronic device A may include: one or more (only one is shown in the figure) processors 102, memory 104, memory controller, and peripheral interface, wherein the peripheral interface is connected to a radio frequency module, an audio module, and a display.

[0290] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this disclosure. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0291] The processor can invoke information and application programs stored in memory via the transmission device to perform the following steps: in response to a node receiving a state transition signal, determine the node's current lock holding state and determine the node's target lock holding state based on the state transition signal; based on the current lock holding state and the target lock holding state, perform a lock update operation in the node and obtain an execution result, wherein the execution result indicates whether the node has successfully performed the lock update operation; in response to the execution result indicating that the node has successfully performed the lock update operation, transition the current lock holding state to the target lock holding state and obtain the lock update result.

[0292] It will be understood by those skilled in the art that the structure shown in Figure 14 is merely illustrative, and the electronic device may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. Figure 14 does not limit the structure of the aforementioned electronic device. For example, electronic device A may include more or fewer components (such as a network interface, a display device, etc.) than shown in Figure 14, or may have a different configuration than that shown in the figure.

[0293] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0294] Embodiments of this disclosure also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the method provided in the above embodiments.

[0295] Optionally, in this embodiment, the storage medium may be located in any one of the electronic devices in the group of electronic devices in the computer network, or in any one of the mobile terminals in the group of mobile terminals.

[0296] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: in response to a node receiving a state transition signal, determining the node's current lock holding state, and determining the node's target lock holding state based on the state transition signal; performing a lock update operation in the node based on the current lock holding state and the target lock holding state, and obtaining an execution result, wherein the execution result is used to indicate whether the node has successfully performed the lock update operation; in response to the execution result indicating that the node has successfully performed the lock update operation, transferring the current lock holding state to the target lock holding state, and obtaining the lock update result.

[0297] Embodiments of this disclosure also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0298] Embodiments of this disclosure also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0299] Embodiments of this disclosure also provide a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it implements the method provided in the above embodiments.

[0300] In the above embodiments of this disclosure, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0301] In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0302] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0303] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0304] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0305] The above description is only a preferred embodiment of this disclosure. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles of this disclosure, and these improvements and modifications should also be considered within the scope of protection of this disclosure.

Claims

1. A lock update method for a distributed system, applied to any node in the distributed system, the method comprising: In response to the node receiving a state transition signal, the current lock holding state of the node is determined, and the target lock holding state of the node is determined based on the state transition signal; Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, wherein the execution result is used to indicate whether the node has successfully executed the lock update operation; In response to the execution result that the node has successfully executed the lock update operation, the current lock holding state is transferred to the target lock holding state, and the lock update result is obtained.

2. The lock update method for a distributed system according to claim 1, wherein, Determining the target lock holding state of the node based on the state transition signal includes: In response to the state transition signal being a first transition signal, the target lock holding state is determined to be a first lock holding state, wherein the first lock holding state is used to indicate that the node stores a first type of lock; In response to the state transition signal being a second transition signal, the target lock holding state is determined to be a second lock holding state, wherein the second lock holding state indicates that the node simultaneously stores the first type of lock and the second type of lock; In response to the state transition signal being a third transition signal, the target lock holding state is determined to be a third lock holding state, wherein the third lock holding state is used to indicate that the node stores a lock of the second type.

3. The lock update method for a distributed system according to claim 2, wherein, Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain the execution result, including: In response to the current lock holding state being the first lock holding state and the target lock holding state being the second lock holding state, the node is controlled to acquire the second type of lock, and it is detected whether the node simultaneously possesses the first type of lock and the second type of lock to obtain a first detection result; In response to the first detection result indicating that the node simultaneously possesses both the first type of lock and the second type of lock, the execution result is determined to be that the node successfully performed the lock update operation.

4. The lock update method for a distributed system according to claim 2, wherein, Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain the execution result, including: In response to the current lock holding state being the first lock holding state and the target lock holding state being the third lock holding state, the node is controlled to acquire the second type of lock, and it is detected whether the node simultaneously possesses the first type of lock and the second type of lock to obtain a first detection result; In response to the first detection result that the node simultaneously possesses both the first type of lock and the second type of lock, the first lock holding state is transferred to the second lock holding state according to the received second transfer signal, and the second lock holding state is determined as the current lock holding state. The node releases the first type of lock, and it is detected whether the node successfully releases the first type of lock to obtain the second detection result. In response to the second detection result indicating that the node has successfully released the first type of lock, the execution result is determined to be that the lock update operation has been successfully performed on the node.

5. The lock update method for a distributed system according to claim 2, wherein, Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain the execution result, including: In response to the current lock holding state being the third lock holding state and the target lock holding state being the second lock holding state, the first type of lock is obtained based on the node, and it is detected whether the node simultaneously has the first type of lock and the second type of lock, to obtain a first detection result; In response to the first detection result that the node simultaneously possesses both the first type of lock and the second type of lock, the execution result is determined to be that the lock update operation was successfully executed on the node.

6. The lock update method for a distributed system according to claim 2, wherein, Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain the execution result, including: In response to the current lock holding state being the third lock holding state and the target lock holding state being the first lock holding state, the first type of lock is obtained based on the node, and it is detected whether the node simultaneously has the first type of lock and the second type of lock, to obtain a first detection result; In response to the first detection result that the node simultaneously possesses both the first type of lock and the second type of lock, the third lock holding state is transferred to the second lock holding state according to the received second transfer signal, and the second lock holding state is determined as the current lock holding state. The node releases the second type of lock, and it is detected whether the node successfully releases the second type of lock to obtain the third detection result. In response to the third detection result indicating that the node has successfully released the second type of lock, the execution result is determined to be that the lock update operation has been successfully performed on the node.

7. The lock update method for a distributed system according to claim 6, wherein, The process of transferring the third lock holding state to the second lock holding state based on the received second transfer signal, and determining the second lock holding state as the current lock holding state, includes: The node is transferred from the third lock holding state to the second lock holding state according to the received second transfer signal; Starting from the time point of receiving the second transfer signal, after a preset time interval, the distributed system is detected to obtain a fourth detection result, wherein the fourth detection result is used to indicate whether multiple nodes in the distributed system have successfully transferred from the third lock holding state to the second lock holding state. In response to the fourth detection result indicating that multiple nodes in the distributed system have successfully transitioned from the third lock holding state to the second lock holding state, the second lock holding state is determined as the current lock holding state.

8. The lock update method for a distributed system according to any one of claims 1 to 7, wherein, The method further includes: In response to the execution result that the node failed to execute the lock update operation, a lock release operation is performed on the node or other nodes in the distributed system other than the node based on a preset interface to obtain the operation result; Based on the operation result, the current lock holding state is transferred to the target lock holding state to obtain the lock update result.

9. The lock update method for a distributed system according to any one of claims 1 to 7, wherein, After transferring the current lock holding state to the target lock holding state based on the execution result and obtaining the lock update result, the method further includes: Determine the target type lock corresponding to the target lock holding state; Mask all lock types other than the target lock type.

10. The lock update method for a distributed system according to any one of claims 2 to 7, wherein, The method further includes: In response to the execution result that the node has failed to execute the lock update operation, a rollback operation is performed on the node based on the current lock holding state and the target lock holding state.

11. The lock update method for a distributed system according to claim 10, wherein, Based on the current lock holding state and the target lock holding state, a rollback operation is performed on the node, including: In response to the current lock holding state being the first lock holding state and the target lock holding state being the second lock holding state, the node is rolled back to the first lock holding state; In response to the current lock holding state being the first lock holding state and the target lock holding state being the third lock holding state, a first release result is obtained based on the node releasing the second type of lock. In response to the first release result being that the node successfully released the second type of lock, the node is rolled back to the first lock holding state. In response to the current lock holding state being the third lock holding state and the target lock holding state being the second lock holding state, the node is rolled back to the third lock holding state. In response to the current lock holding state being the third lock holding state and the target lock holding state being the first lock holding state, a second release result is obtained based on the node releasing the first type of lock. In response to the second release result being that the node has successfully released the first type of lock, the node is rolled back to the third lock holding state.

12. The lock update method for a distributed system according to any one of claims 1-7, wherein, The current lock holding state is used to indicate the actual holding status of the distributed lock by the node after receiving the state transition signal.

13. The lock update method for a distributed system according to any one of claims 1-7, wherein, The target lock holding state is used to represent the lock holding state that the node is expected to transition to based on the state transition signal.

14. The lock update method for a distributed system according to any one of claims 2-7, wherein, The first type of lock is a centralized distributed lock, and the second type of lock is a multi-active distributed lock.

15. The lock update method for a distributed system according to any one of claims 2-7, wherein, The first lock holding state is the lock holding state before the system upgrade, and the second lock holding state is the target state that the node is expected to reach during the lock upgrade process.

16. The lock update method for a distributed system according to any one of claims 2-7, wherein, The third lock holding state is the lock holding state reached by the node.

17. The lock update method for a distributed system according to claim 9, wherein, The target type lock is the lock type held by the node after the lock update operation is completed.

18. A lock update method for a distributed system, applied to any node in the distributed system, the method comprising: By calling the first interface to obtain the state transition signal of the node in the distributed system, the current lock holding state of the node is determined, and the target lock holding state of the node is determined based on the state transition signal. The first interface includes a first parameter, and the parameter value of the first parameter includes the state transition signal. Based on the current lock holding state and the target lock holding state, a lock update operation is performed in the node to obtain an execution result, wherein the execution result is used to indicate whether the lock update operation was successfully performed in the node; Based on the execution result, the current lock holding state is transferred to the target lock holding state to obtain the lock update result; The lock update result is output by calling the second interface, wherein the second interface includes a second parameter, and the value of the second parameter includes the lock update result.

19. An electronic device comprising: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 18.

20. A computer-readable storage medium comprising a stored executable program, wherein, When the executable program is executed, it controls the device containing the storage medium to perform the method described in any one of claims 1 to 18.

Images