Micro-service leader election method and system based on distributed coordination

Abstract

The invention relates to the technical field of distributed computing and micro-service architecture, in particular to a micro-service leader election method and system based on distributed coordination, and the method comprises the steps: deploying a plurality of micro-service copies in a container environment, and carrying out the routing request through a load balancing server, all micro-service copies share a distributed coordination storage instance as a coordination center, and on this basis, the micro-service leader election method comprises the following steps: S1, all micro-service copies attempt to acquire a distributed lock through a distributed lock acquisition command of the coordination center at the same time; s2, successfully obtaining a micro-service copy of the distributed lock as a Leader copy, and taking other micro-service copies as Follower copies; and S3, the Leader copy renews the lock every fixed interval, and the free count is updated. According to the method, distributed coordination storage is used as a coordination mechanism, and it is ensured that only one micro-service copy provides service for the outside in a specific scene.

Description

Technical Field

[0001] This invention relates to the fields of distributed computing and microservice architecture technology, specifically to a microservice leader election method and system based on distributed coordination. Background Technology

[0002] In modern microservice architectures, to achieve high availability and load balancing, multiple replicas of the same service are typically deployed, and these replicas provide services to the outside world through a load balancer. This multi-replica design is efficient and reliable in most scenarios, but there are specific needs: some services (such as operations involving state synchronization or exclusive resources) are expected to be exposed in a "single-service" mode, that is, only one replica acts as the working replica (Leader) to actually handle requests, while other replicas act as backups (Followers) to avoid concurrency conflicts, state inconsistencies, or resource contention issues.

[0003] In existing technologies, load balancers typically distribute requests evenly across all replicas, failing to differentiate between working replicas and leading to potential duplicate executions or data inconsistencies. Meanwhile, while existing leader election mechanisms (such as consensus algorithms based on dedicated coordination services) can achieve leader election, they are complex to deploy, rely on additional coordination services, and increase system overhead and maintenance difficulty. In containerized environments, there is a lack of lightweight election schemes based on general-purpose coordination storage, making it difficult to efficiently handle replica failover, term renewal, and re-election processes.

[0004] For example, when a working copy fails, existing multi-replica systems may experience service interruptions or multiple leader contention, affecting system stability, as detailed below:

[0005] (1) The election process is costly and time-consuming;

[0006] (2) Lack of fine-grained control over tenure management and heartbeat detection;

[0007] (3) Not suitable for lightweight deployment requirements in microservices. Summary of the Invention

[0008] To address the technical problems of existing leader election mechanisms, which, while capable of leader election, suffer from complex deployment, reliance on additional coordination services, increased system overhead and maintenance difficulty, and inefficient handling of replica failover, term re-election, and re-election processes, this invention provides a microservice leader election method and system based on distributed coordination. Utilizing distributed coordination storage as the coordination mechanism, it ensures that only one microservice replica provides services to the outside world in specific scenarios, and supports failover, term management, and re-election processes. It is suitable for high-availability service architectures in cloud computing and containerized deployment environments.

[0009] The technical solution adopted in this invention is to provide a microservice leader election method based on distributed coordination, which includes deploying multiple microservice replicas and a distributed coordination storage instance in a container environment, routing requests through a load balancer server, and having all microservice replicas share a distributed coordination storage instance as a coordination center, which is used to store leader information.

[0010] Based on this, the microservice leader election method includes the following steps:

[0011] S1. All microservice replicas simultaneously attempt to acquire commands through the distributed lock of the coordination center, obtain the distributed lock of the Leader information in the coordination center, and attach an expiration time as the heartbeat interval.

[0012] S2. The microservice replica that successfully acquires the distributed lock is used as the Leader replica, and the Leader information stored in the coordination center is updated. Other microservice replicas are used as Follower replicas, and the coordination center is polled periodically to check the Leader status.

[0013] S3, the Leader replica renews the lock at fixed intervals and updates the term count. If renewal fails, it actively releases the lock and initiates a new election.

[0014] The Leader information includes leader information, tenure data, and a distributed lock.

[0015] The leader information includes the microservice replica ID, IP address, and port.

[0016] The container environment uses key space isolation.

[0017] A system for a microservice leader election method based on distributed coordination includes a microservice replica module, a distributed coordination module, an election engine module, and a routing module;

[0018] The microservice replica module is used to deploy multiple microservice replicas, and all microservice replicas share the distributed coordination storage instance in the distributed coordination module.

[0019] The distributed coordination module is used to deploy distributed coordination storage instances, which serve as the coordination center for all microservice replicas and store Leader information;

[0020] The election engine module is used to elect a leader replica from multiple microservice replicas through a preset leader election mechanism.

[0021] The routing module is used to handle routing requests for microservice replicas through a load balancer server.

[0022] The beneficial effects of this invention are that it provides a microservice leader election method and system based on distributed coordination. Utilizing the atomicity and high performance of distributed coordination storage, it achieves low election latency, supports horizontal scaling, requires no additional dedicated coordination service, and is suitable for stateful microservices, such as configuration centers or resource management services. It has the following advantages:

[0023] 1. By utilizing atomic operations of distributed coordinated storage, including lock acquisition and expiration extension, efficient leader election and heartbeat management can be achieved, avoiding the overhead of complex consensus algorithms.

[0024] 2. Dynamically link with the load balancer server, exposing only a single working copy to achieve a pseudo-monolithic microservice model.

[0025] 3. Combining expiration time and polling detection ensures rapid fault switching and supports increasing tenure to prevent interference from old leaders. Attached Figure Description

[0026] Figure 1 This is a flowchart of the method of the present invention;

[0027] Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0028] like Figure 1 As shown, this invention provides a microservice leader election method based on distributed coordination, including deploying multiple microservice replicas and a distributed coordination storage instance in a container environment, routing requests through a load balancer, and having all microservice replicas share a single distributed coordination storage instance as a coordination center, which stores leader information. The leader information includes leader information, term data, and a distributed lock. The leader information includes the microservice replica ID, IP address, and port. The container environment uses key space isolation.

[0029] Based on this, the microservice leader election method includes the following steps:

[0030] S1. All microservice replicas simultaneously attempt to acquire commands through the distributed lock of the coordination center, obtain the distributed lock of the Leader information in the coordination center, and attach an expiration time as the heartbeat interval.

[0031] The distributed lock acquisition command uses the SET command with NX and PX / EX options, based on the LockTakeAsync method of the StackExchange.Redis component. In distributed scenarios, it attempts to set a key to a specific value, such as a unique identifier, to ensure that only one client can successfully set the key. For example, the SET command can be used to implement a distributed lock, guaranteeing that only one client can hold the lock at a time in a distributed environment, thus avoiding data inconsistency issues caused by concurrent access.

[0032] S2. The microservice replica that successfully acquires the distributed lock is used as the Leader replica, and the Leader information stored in the coordination center is updated. Other microservice replicas are used as Follower replicas, and the coordination center is polled periodically to check the Leader status.

[0033] The Leader state refers to the state of the coordination center in a distributed scenario, including being awaiting election, successfully elected (during term), re-elected (renewed term), and exiting term. Follower replicas can query this state to determine whether a new leader election should be held.

[0034] S3, the Leader replica renews the lock at fixed intervals and updates the term count. If renewal fails, it actively releases the lock and initiates a new election.

[0035] Renewal locks refer to a mechanism in distributed scenarios where, if a microservice replica acquires a lock but fails to complete its task within the lock's expiration period, the lock's validity period is automatically extended to ensure that the microservice replica can continue to hold the lock and complete its task.

[0036] To better understand this invention, the following examples provide further illustration.

[0037] For example, you need to deploy a microservice named config-service in a container orchestration platform. It contains three microservice replicas, namely instance 1, instance 2 and instance 3. A load balancer is used as the routing component, and a distributed coordination storage instance is used as the coordination center.

[0038] (1) Environment preparation: Deploy a distributed coordinated storage instance, with key space isolation: the service key prefix is ​​config-service:, each microservice replica runs the service application, and integrates a distributed lock client.

[0039] (2) Start election: When the service starts, each microservice replica performs a distributed lock acquisition operation, waits for 0 seconds, and holds the lock for a fixed time of 30 seconds; if instance 1 succeeds, it enters the Leader mode and updates the Leader information stored in the distributed coordination instance, including instance ID, IP, port and current term; if instance 2 and instance 3 fail, they enter the Follower mode and check the lock status every 5 seconds.

[0040] (3) Leader operation: Instance 1 acts as a Leader replica, renews the lock every 5 seconds, and extends the expiration time to 30 seconds. The load balancer server is configured with a script to query the distributed coordination storage to obtain the Leader IP / port and only route requests to the Leader replica.

[0041] (4) Term of Renewal: Initial term = 1. If renewal is successful, the term is increased; if it fails, the lock is released and a message subscription mechanism is used to broadcast the notification.

[0042] (5) Failover: After instance 1 crashes or the distributed lock expires, instances 2 and 3 detect this and immediately initiate an election. Instance 2, sorted by ID, succeeds first and updates the Leader information, with a term of 2. The load balancer automatically switches routes. The switching time is short, ensuring zero interruption.

[0043] State synchronization: The Leader replica maintains the shared state, and the Follower replica synchronizes changes through a subscription mechanism of the distributed coordinated storage.

[0044] The present invention also provides a system for a microservice leader election method based on distributed coordination, including a microservice replica module, a distributed coordination module, an election engine module, and a routing module;

[0045] The microservice replica module is used to deploy multiple microservice replicas, and all microservice replicas share the distributed coordination storage instance in the distributed coordination module.

[0046] The distributed coordination module is used to deploy distributed coordination storage instances, which serve as the coordination center for all microservice replicas and store Leader information;

[0047] The election engine module is used to elect a leader replica from multiple microservice replicas through a preset leader election mechanism.

[0048] The routing module is used to handle routing requests for microservice replicas through a load balancer server.

Claims

1. A microservice leader election method based on distributed coordination, characterized in that: This includes deploying multiple microservice replicas and a distributed coordination storage instance in a container environment, routing requests through a load balancer, and having all microservice replicas share a single distributed coordination storage instance as a coordination center, which is used to store Leader information. Based on this, the microservice leader election method Includes the following steps, S1. All microservice replicas simultaneously attempt to acquire commands through the distributed lock of the coordination center, obtain the distributed lock of the Leader information in the coordination center, and attach an expiration time as the heartbeat interval. S2. The microservice replica that successfully acquires the distributed lock is used as the Leader replica, and the Leader information stored in the coordination center is updated. Other microservice replicas are used as Follower replicas, and the coordination center is polled periodically to check the Leader status. S3, the Leader replica renews the lock at fixed intervals and updates the term count. If renewal fails, it actively releases the lock and initiates a new election.

2. The microservice leader election method based on distributed coordination according to claim 1, characterized in that: The Leader information includes leader information, tenure data, and a distributed lock.

3. The microservice leader election method based on distributed coordination according to claim 1, characterized in that: The leader information includes the microservice replica ID, IP address, and port.

4. The microservice leader election method based on distributed coordination according to claim 1, characterized in that: The container environment uses key space isolation.

5. A system for the microservice leader election method based on distributed coordination as described in any one of claims 1-4, characterized in that: This includes a microservice replica module, a distributed coordination module, an election engine module, and a routing module; The microservice replica module is used to deploy multiple microservice replicas, and all microservice replicas share the distributed coordination storage instance in the distributed coordination module. The distributed coordination module is used to deploy distributed coordination storage instances, which serve as the coordination center for all microservice replicas and store Leader information; The election engine module is used to elect a leader replica from multiple microservice replicas through a preset leader election mechanism. The routing module is used to handle routing requests for microservice replicas through a load balancer server.

Images