System and method for implementing high availability of distributed services based on Paxos protocol

Abstract

The present invention discloses a system and method for achieving high availability of distributed services based on the Paxos protocol. The system includes a client and a server. The client is used to store an interface of an external system and accept access from a distributed business system to the server, so that the business service is registered on the server. The server is used to accept business service registrations from the distributed business system. The client is also used to define the current business service status as a follower after the business service registration is completed. By designing a client to store an external system interface and defining business services as three states: registrant, follower, and leader, the client and server can be linked to maintain whether the business service is alive and its survival status, thereby ensuring the strong consistency and high availability of distributed storage.

Description

Technical Field

[0001] The present invention relates to a method for implementing high availability of a distributed storage system. More specifically, the present invention mainly relates to a system and method for implementing high availability of distributed services based on the Paxos protocol. Background Art

[0002] The current mainstream approach to achieving high service availability is based on the Apache Zookeeper project. The Apache Zookeeper project implements distributed consistency based on the Zab protocol. Through atomic broadcast capabilities, it synchronizes information across all services, thereby achieving global consistency in the state of distributed services. Services register temporary nodes in Zookeeper. When a service disconnects, the temporary node is automatically deregistered. When other services discover that the temporary node does not exist, they proactively create a temporary node to achieve service migration. In the event of an abnormality such as a power outage or network disconnection, the temporary node determines through a heartbeat check that the temporary node has expired. Zookeeper proactively deregisters the temporary node, allowing other services to discover the loss and achieve service migration. However, existing distributed service high availability solutions can only mark whether a service is alive. They do not support the survival status of business services or the subordinate relationships between business services. Therefore, further research and improvement of methods for achieving high distributed service availability are necessary. Summary of the Invention

[0003] One of the purposes of the present invention is to address the above-mentioned deficiencies and provide a system and method for achieving high availability of distributed services based on the Paxos protocol, in order to solve technical problems in the prior art such as the lack of support for the survival status of business services and subordinate associations.

[0004] In order to solve the above technical problems, the present invention adopts the following technical solutions.

[0005] On the one hand, the present invention provides a system for achieving high availability of distributed services based on the Paxos protocol, the system comprising: a client, for storing an interface of an external system, accepting access to a server by a distributed business system, and completing registration of the business service in the server; a server, for accepting business service registration of the distributed business system; the client is further used to define the current business service state from the registrant to a follower after the business service registration is completed; the client is further used to define the current business service state as a leader after the business service in the follower state completes leader registration; the client is further used to return the follower and leader states to the registrant state when the business service in the distributed business system expires.

[0006] As a preferred embodiment, a further technical solution is: in the server: when the status of the business service is a registrant, when the validity expires, the business service has not yet joined the cluster and no action is required; when the status of the business service is a follower, when the validity expires, the business service has already joined the cluster, the current business service follower information is cancelled, and the current client returns to the registrant's business status; when the status of the business service is a leader, when the validity expires, the business service has already joined the cluster, the current business service leader information and follower information are cancelled, and the current client returns to the registrant's business status.

[0007] A further technical solution is: in the client: when the status of the business service is registrant, when the validity expires, the business service has not completed the registration and no action is required; when the status of the business service is follower, when the validity expires, the business service has completed the registration, so that the current server returns to the registrant's business status; when the status of the business service is leader, when the validity expires, the business service has completed the registration, so that the current server returns to the registrant's business status.

[0008] A further technical solution is that the client has a service status lifecycle monitoring module inside, which is used to maintain whether the service is alive and its survival status, and regularly poll whether the validity of the service has expired.

[0009] A further technical solution is: the client also has a callback interface; when the state of the current business service process changes, the callback parameters are the historical state and current state of the business service; when the state of other business service processes changes, the callback parameters are the business service label, historical state and current state; when a new business service is added, the callback parameter is the label of the current business service.

[0010] A further technical solution is: the label is the year label of the service method provided by the server to the business, and the year label is based on the current time of the server when the current client is sending the service.

[0011] Another aspect of the present invention provides a method for achieving high availability of distributed services based on the Paxos protocol, the method comprising:

[0012] Step A: The client stores the interface of the external system, accepts the distributed business system to access the server, and completes the registration of the business service in the server; the server accepts the business service registration of the distributed business system.

[0013] Step B: After the client completes the business service registration, the current business service status is defined by the registrant as a follower.

[0014] Step C: After the business service in the follower state completes the leader registration, the client defines the current business service state as the leader.

[0015] Step D: When the client's business service in the distributed business system expires, the follower and leader states are returned to the registrant state.

[0016] A further technical solution is: in the server: when the status of the business service is a registrant, when the validity expires, the business service has not yet joined the cluster and no action is required; when the status of the business service is a follower, when the validity expires, the business service has already joined the cluster, the current business service follower information is cancelled, and the current client returns to the registrant's business status; when the status of the business service is a leader, when the validity expires, the business service has already joined the cluster, the current business service leader information and follower information are cancelled, and the current client returns to the registrant's business status.

[0017] A further technical solution is: the method also includes in the client: when the status of the business service is registrant, when the validity expires, the business service has not completed registration and no action is required; when the status of the business service is follower, when the validity expires, the business service has completed registration, so that the current server returns to the registrant's business status; when the status of the business service is leader, when the validity expires, the business service has completed registration, so that the current server returns to the registrant's business status.

[0018] A further technical solution is that the client has a service status lifecycle monitoring module inside, which is used to maintain whether the service is alive and its survival status, and regularly poll whether the validity of the service has expired.

[0019] Compared with the existing technology, one of the beneficial effects of the present invention is: by designing the client storage external system interface and defining the business service into three states: registrant, follower and leader, the business service can be maintained and its survival and survival status can be determined through the linkage between the client and the server, so as to ensure the strong consistency and high availability of distributed storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 The figure is a schematic block diagram of a distributed service state storage unit for illustrating an embodiment of the present invention.

[0021] Figure 2 The figure is a schematic block diagram of a system structure for illustrating an embodiment of the present invention.

[0022] Figure 3A business service state transition diagram for illustrating an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The present invention will be further described below with reference to the accompanying drawings.

[0024] High availability of distributed services and further implementation of self-healing capabilities for distributed services. Distributed services require a foundational module to maintain service status independent of the business. Naturally, this foundational service cannot have single points of failure or consistency issues. Therefore, this foundational service is positioned as distributed service state storage. A relatively mature theory for addressing single points of failure and distributed consistency is the Paxos distributed consensus algorithm. Paxos theory has been in the industry for 17 years, and its reliability has been proven by numerous articles and projects. The Paxos algorithm was designed from the outset to address single points of failure, ensure strong consistency, and achieve high availability. Since then, the Paxos algorithm has theoretically met the technical and theoretical requirements for distributed service state storage.

[0025] Distributed service state storage will implement the Paxos algorithm in C++ to achieve distributed consistency. The engineering implementation of distributed service state storage will be based on the Multi Paxos algorithm, theoretically resulting in superior service performance compared to Basic Paxos. Multi Paxos optimizes consistency confirmation from two phases to a single phase in partial consistency scenarios.

[0026] As Figure 1 As shown, from the perspective of the distributed service state storage and business system integration architecture, the distributed service state storage service will be an independent service. After startup, it will be hosted in the business service process and start when the business service process starts. Each unit of the distributed service state storage service runs independently, and ultimately communicates with each other to form a distributed service state storage cluster. After the majority agreement is met, it will provide services externally.

[0027] The distributed service state storage cluster provides two modes: one is to provide external read and write services after the leader is elected, that is, to change the business service status. The other is to provide read and write services after the distributed service state storage cluster meets the majority, and there is a temporary leader in the cluster during the write process.

[0028] Since then, the distributed service state storage service supports the state storage of business services and meets the requirements of single point failure, consistency, and high availability. In addition, some design needs to be done on the external interface of the distributed service state storage service module, namely: the distributed service state storage client.

[0029] Considering that distributed business systems passively drive service state transitions in abnormal scenarios such as power outages and network disconnections, the distributed service state storage module requires further packaging. This module uses a registration-based approach to manage business service state, implementing event-driven state transitions and decoupling the complexity of circular dependencies in distributed scenarios. Distributed service state storage is implemented based on a B / S architecture. The server-side module supports business service module state storage, and the client completes the interaction between the business service module and the server-side module. While the distributed business system completes business service registration based on the distributed storage service client, it also needs to complete corresponding actions when declaring business service state transitions.

[0030] refer to Figure 2 As shown in the figure, the distributed service state storage consists of a client module (dynamic library) and a server module (executable program). The server stores distributed business system status data. The server has a built-in scheduled polling and checking module that monitors the distributed business system service status and triggers events when data changes, pushing these events to the client. The client's memory scheduled polling and checking module regularly sends heartbeat messages to the server, announcing the status of the distributed business system modules. The client receives events pushed by the server or triggered by the client's scheduled polling and checking module when it detects an anomaly.

[0031] Assume that there is a distributed business system that implements a historical data query system. The distributed business system implements high availability of the business system based on distributed service state storage. The business system needs to undergo the following integration process. When the distributed business system integrates the distributed service state storage, the distributed business system connects to the distributed service state storage client and implements the corresponding business system operations when the service state changes according to the needs of the distributed business system. The distributed service state storage defines the service state for each instance of the distributed business system: Registrant (Register), Follower (Follow), Leader (Leader). The changes between states can be referred to Figure 3 shown.

[0032] The above-mentioned distributed service state storage service client deploys 1+2n instance component clusters, and the distributed service state storage client is hosted in the distributed business system.

[0033] As mentioned above, the distributed service state store defines three states for business services:

[0034] Register: The default state of the distributed service state storage client is Register. At this time, the business service node is in the initialization process, and the distributed service state storage client defines the current service as not yet managed within the distributed business system cluster. The distributed service state storage client needs to assign an "age" to the current business lifecycle. This "age" serves as a unique identifier for the current business service in the client and marks its lifecycle. The identifier uses the current time of the server to which the client belongs.

[0035] Follower: The distributed service state storage client has completed registration and is in the Follow state. Both the client and server have confirmed state consistency. The distributed service state storage client defines that the current service is managed within the distributed business system cluster. Business services may have data inconsistencies and are therefore not available externally.

[0036] Leader: The distributed service state storage client has completed leader registration and is in the Leader state. Both the client and server have confirmed state consistency. The distributed service state storage client defines the current service as the leader. After the business service confirms the new leader and completes the corresponding actions, it provides external services.

[0037] exist Figure 3 In the distributed service state storage, the server accepts client registrations and defaults the state of the business service it assists to Register. After initialization, the client accesses the distributed service state storage service based on its configuration information to complete business service registration. Subsequently, after the business service assisted by the client completes registration, the server in the distributed service state storage is defined by the client as Follow. The client periodically scans for currently registered Follow services. If a timeout occurs, it deregisters itself and notifies the corresponding distributed business system. On the client side, after the business service it assists completes registration, it accesses the distributed service state storage service based on its own configuration information to complete the business service master registration. The client periodically repeats business service registration based on the configuration. The server also periodically scans for currently registered Follow / Leader services. If a timeout occurs, it deregisters itself and notifies the distributed state storage system.

[0038] The distributed service state storage module is hosted in the business system process. Distributed service state storage ensures the consistency of service state information in various abnormal situations. When a distributed service state storage service client encounters an abnormality, the client sets the expiration mode. When the expiration occurs, the client and server will perform the following actions:

[0039] Distributed service state storage-server:

[0040] When the business service status is Register and the validity period expires: The business service status is Register. The business service has not yet been added to the cluster and the business is not allowed to provide services externally. The business service in this state does not need to take any action.

[0041] When the validity of a business service in the Follow state expires: The business service is in the Follow state and has been added to the cluster. In this state, the current business service Follow information needs to be deregistered.

[0042] When the validity period of the business service expires in the Leader state, the business service has been added to the cluster. In this state, the Follow information and Leader information of the current business service need to be cancelled.

[0043] Distributed service state storage-client:

[0044] When the validity period of a business service expires in the Register state, the business service is in the Register state. The business service has not yet completed registration and is not allowed to provide services externally. In this state, the business service does not need to take any action.

[0045] The business service status is Follow. When the validity period expires: The business service status is Follow. The business service has completed registration. At this time, the business service status changes from Follow to Register.

[0046] When the business service status is Leader and the validity period expires: the business service status is Leader and the business service has completed registration, then the business service status changes from Leader to Register.

[0047] The distributed service state storage client not only assists the business system in completing business system registration, but also notifies the business system of state changes through function callbacks, driving the business system to make adjustments based on cluster conditions. The callback interface is as follows:

[0048] When the state of the current business service process instance changes, the callback function parameters are: historical state and current state.

[0049] When the status of other business service process instances changes, the callback function parameters are: business instance number, historical status, and current status.

[0050] A new business service process instance is added to the cluster. The callback function parameter is: business instance number.

[0051] Since existing distributed service high availability solutions can only mark whether a service is alive, they do not support the survival status of business services, the subordinate associations between business services, etc. Therefore, the present invention provides a distributed service status storage service system, which is divided into two parts: the server and the client.

[0052] The server is a cluster of 1+2n instance components. The server cluster stores service status information from external systems. Based on Paxos theory, the server cluster implements a distributed storage system to ensure strong consistency and high availability of stored information. The server also has a built-in service status lifecycle monitoring module to manage service status information from external systems. When external system services change, the built-in service status lifecycle monitoring module implements event-driven notifications, pushing these changes to all clients and server instances.

[0053] The client is the interface for storing external systems, providing a friendly interface for registering external system services; the client has a built-in service status lifecycle monitoring module to automatically maintain whether the business is alive and its survival status; and provides an event-driven interface to trigger the external system to complete related operations.

[0054] By collaborating with the distributed service state storage client and server, integrating external systems into the distributed service state storage requires only registering the service and the external system's service state transition events (the corresponding operational actions when the external service state changes). This makes it easy to achieve high availability for the business system. Furthermore, during integration, corresponding actions can be taken for different scenarios, simplifying the integration of business applications.

[0055] Based on the aforementioned embodiments of the present invention, it can be seen that the present invention provides a highly integrated, modular distributed service state storage that can be freely hosted in any process of a distributed business system, allowing for unlimited deployment. Furthermore, the present invention's technical solution manages three business service states: registrant, follower, and leader, supporting subordinate relationships within business organizations and ensuring consistent service provision to external services.

[0056] In addition to the above, it should be noted that references to "one embodiment," "another embodiment," "an embodiment," and the like in this specification refer to specific features, structures, or characteristics described in conjunction with that embodiment as included in at least one embodiment generally described in this application. The appearance of the same expression in multiple places in the specification does not necessarily refer to the same embodiment. Furthermore, when a specific feature, structure, or characteristic is described in conjunction with any embodiment, it is intended that such feature, structure, or characteristic, when implemented in conjunction with other embodiments, also falls within the scope of the present invention.

[0057] Although the present invention has been described herein with reference to a number of illustrative embodiments thereof, it will be understood that numerous other modifications and implementations may be devised by those skilled in the art that fall within the scope and spirit of the principles disclosed herein. More specifically, within the scope of the present disclosure, the drawings, and the claims, numerous variations and modifications may be made to the components and / or layout of the subject combination arrangement. In addition to variations and modifications to the components and / or layout, other uses will also be apparent to those skilled in the art.

Claims

1. A system for achieving high availability of distributed services based on the Paxos protocol, characterized by The system comprises: The client is used to store the interface of the external system, accept the distributed business system to access the server, and complete the registration of business services in the server; The server is used to accept business service registrations from distributed business systems; The client is further configured to define the current state of the business service as a follower from the registrant after the business service registration is completed; The client is further configured to define the current business service state as a leader after the business service in the follower state completes leader registration; The client is also used to return the follower and leader states of the business service to the registrant state when the business service in the distributed business system expires.

2. The system for achieving high availability of distributed services based on the Paxos protocol according to claim 1 is characterized in that In the server: When the business service is in the registrant state and its validity period expires, the business service has not yet been added to the cluster and no action is required. When the business service is in the follower state and the validity period expires, the business service has already joined the cluster, and the current business service follower information is cancelled, so that the current client returns to the registrant business state; When the business service is in the leader state, when validity expires, the business service has already joined the cluster, the current business service leader information and follower information are cancelled, and the current client returns to the registrant's business state.

3. The system for implementing high availability of distributed services based on the Paxos protocol according to claim 1 or 2, characterized in that In the client in question: When the status of the business service is registrant and the validity period expires, the business service has not yet completed registration and no action is required; When the business service is in the follower state and the validity period expires, the business service has completed registration, causing the current server to return to the registrant's business state; When the status of the business service is the leader, when the validity period expires, the business service has completed the registration, so that the current server returns to the business status of the registrant.

4. The system for implementing high-availability distributed services based on the Paxos protocol according to claim 3, characterized in that: The client has a service status lifecycle monitoring module inside, which is used to maintain whether the service is alive and its survival status, and regularly poll whether the validity of the service has expired.

5. The system for implementing high-availability distributed services based on the Paxos protocol according to claim 1 or 4, characterized in that: The client also has a callback interface; when the state of the current business service process changes, the callback parameters are the historical state and current state of the business service; when the state of other business service processes changes, the callback parameters are the business service label, historical state and current state; when a new business service is added, the callback parameter is the label of the current business service.

6. The system for implementing high-availability distributed services based on the Paxos protocol according to claim 5, characterized in that: The label is an era label issued by the server to the business service, and the era label is based on the current time of the server when the client is currently viewing the label.

7. A method for achieving high availability of distributed services based on the Paxos protocol, characterized in that The method includes: The client stores the interface of the external system, accepts the distributed business system to access the server, and completes the registration of business services in the server; The server accepts business service registrations from distributed business systems; After the client completes the registration of the business service, the current business service status is defined by the registrant as a follower; After the business service in the follower state completes the leader registration, the client defines the current business service state as the leader; When the client's business service in the distributed business system expires, the follower and leader states will be returned to the registrant state.

8. The method for achieving high availability of distributed services based on the Paxos protocol according to claim 7, characterized in that In the server: When the business service is in the registrant state and its validity period expires, the business service has not yet been added to the cluster and no action is required. When the business service is in the follower state and the validity period expires, the business service has already joined the cluster, and the current business service follower information is cancelled, so that the current client returns to the registrant business state; When the business service is in the leader state, when validity expires, the business service has already joined the cluster, the current business service leader information and follower information are cancelled, and the current client returns to the registrant's business state.

9. The method for achieving high availability of distributed services based on the Paxos protocol according to claim 7, characterized in that The method further comprises, in the client: When the status of the business service is registrant and the validity period expires, the business service has not yet completed registration and no action is required; When the business service is in the follower state and the validity period expires, the business service has completed registration, causing the current server to return to the registrant's business state; When the status of the business service is the leader, when the validity period expires, the business service has completed the registration, so that the current server returns to the business status of the registrant.

10. The method for achieving high availability of distributed services based on the Paxos protocol according to claim 7, characterized in that: The client has a service status lifecycle monitoring module inside, which is used to maintain whether the service is alive and its survival status, and regularly poll whether the validity of the service has expired.

Images