CN114625489B

CN114625489B - Access request response method, device and distributed system

Info

Publication number: CN114625489B
Application number: CN202210296635.5A
Authority: CN
Inventors: 罗剑明; 严祥光; 安凯歌
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2022-03-24
Filing date: 2022-03-24
Publication date: 2024-07-30
Anticipated expiration: 2042-03-24
Also published as: CN114625489A

Abstract

The embodiment of the specification provides an access request response method, an access request response device and a distributed system, wherein the access request response method comprises the following steps: when disconnection with a main node is detected, stopping writing data in a data log into an application queue, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting node consistency judgment conditions; matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded; responding to the first access request, and returning a response result to the first client. The scheme can ensure that the availability of the distributed system is higher when the distributed system is disconnected with the main node.

Description

Access request response method, device and distributed system

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to an access request response method.

Background

With the increasing demands for processing efficiency, data disaster recovery, reliability, and the like, distributed systems are widely used.

In the related technology, a user can send an access request through a client connected with a slave node of a distributed system, and then a master node in the distributed system initiates consistency processing of target data corresponding to the access request by using a consistency protocol, and the target data is stored under the condition that the target data accords with a consistency condition so as to ensure consistency of the data in the distributed system. In a specific application, the master node is likely to switch: the current master node is unavailable due to the downtime of the equipment or the version update and the like, and a new master node needs to be selected. At this time, in order to prevent consistency anomalies caused by unavailability of the master node, each slave node disconnects all clients connected and empties the pending access requests so that the clients resend the access requests to the distributed system.

However, after the disconnection, in order to reconnect to send an access request, the client needs to send a large number of reconnection requests to the distributed system, which easily causes a problem that the performance of the distributed system is greatly reduced, or even a problem that a crash is not available. Thus, there is a need to provide a more useful solution.

Disclosure of Invention

In view of this, the present embodiment provides an access request response method. One or more embodiments of the present specification also relate to an access request responding apparatus, a distributed system, a computing device, a computer-readable storage medium, and a computer program that solve the technical drawbacks of the prior art.

According to a first aspect of embodiments of the present disclosure, there is provided an access request response method applied to a slave node of a distributed system, including:

when disconnection with a main node is detected, stopping writing data in a data log into an application queue, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting node consistency judgment conditions;

matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded;

responding to the first access request, and returning a response result to the first client.

According to a second aspect of embodiments of the present specification, there is provided an access request response apparatus applied to a slave node of a distributed system, comprising:

the stopping module is configured to stop writing data in the data log into the application queue when disconnection with the master node is detected, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting the node consistency judgment condition;

The matching module is configured to match the access request in the waiting queue with the data in the application queue, and keep the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded;

and the response module is configured to respond to the first access request and return a response result to the first client.

According to a third aspect of embodiments of the present specification, there is provided a distributed system comprising:

slave node, master node and client;

The slave node is configured to stop writing data in a data log into an application queue when disconnection with the master node is detected, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting node consistency judgment conditions; matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded; responding to the first access request, and returning a response result to the first client;

The client is configured to receive the response result.

According to a fourth aspect of embodiments of the present specification, there is provided a computing device comprising:

A memory and a processor;

The memory is configured to store computer-executable instructions that, when executed by the processor, perform the steps of the access request response method described above.

According to a fifth aspect of embodiments of the present specification, there is provided a computer-readable storage medium storing computer-executable instructions which, when executed by a processor, implement the steps of the above-described access request response method.

According to a sixth aspect of the embodiments of the present specification, there is provided a computer program, wherein the computer program, when executed in a computer, causes the computer to perform the steps of the above-described access request response method.

According to the embodiment of the specification, when the slave node of the distributed system detects disconnection with the master node, writing data in a data log into an application queue is stopped, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting the node consistency judgment condition; matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded; responding to the first access request, and returning a response result to the first client.

In this way, when the data is disconnected from the master node, the data in the data log is stopped from being written into the application queue, and the problem of consistency abnormality caused by feeding back the data which is uncertain whether the master node performs node consistency judgment to the client side when the master node is disconnected is avoided. On the basis, normal feedback can be carried out on the data written into the application queue, so that connection between the first client ends corresponding to the first access request matched with the data in the application queue can be maintained, the first access is responded, and a return result is returned to the first client ends. Therefore, the method can avoid consistency abnormality caused by disconnection of all clients and response abnormality to each access request under the condition that connection of all clients is not required to be disconnected, thereby greatly reducing the pressure of the distributed system caused by reconnection after disconnection of all clients and ensuring the working performance of the distributed system. Therefore, the scheme can ensure that the availability of the distributed system is higher when the distributed system is disconnected with the master node.

Drawings

FIG. 1 is a schematic service framework of a distributed system provided in one embodiment of the present description;

FIG. 2 is a flow chart of an access request response method provided by one embodiment of the present disclosure;

FIG. 3 is an architectural diagram illustration of a distributed system in a multi-layered asynchronous queue scenario provided by one embodiment of the present description;

FIG. 4 is a diagram illustrating an example state of each asynchronous queue after a master node and a slave node are disconnected in a multi-layered asynchronous queue scenario according to one embodiment of the present disclosure;

FIG. 5 is an exemplary diagram of an application result of an access request response method in a multi-layer asynchronous queue scenario according to one embodiment of the present disclosure;

Fig. 6 is a diagram illustrating an example of a processing procedure of an access request in a scenario in which a role type of a slave node is a master node type in an access request response method according to an embodiment of the present disclosure;

FIG. 7 is a schematic diagram of an access request responding device according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a distributed system according to one embodiment of the present disclosure;

FIG. 9 is a block diagram of a computing device provided in one embodiment of the present description.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present description. This description may be embodied in many other forms than described herein and similarly generalized by those skilled in the art to whom this disclosure pertains without departing from the spirit of the disclosure and, therefore, this disclosure is not limited by the specific implementations disclosed below.

The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present specification refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that, although the terms first, second, etc. may be used in one or more embodiments of this specification to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first may also be referred to as a second, and similarly, a second may also be referred to as a first, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "in response to a determination" depending on the context.

First, terms related to one or more embodiments of the present specification will be explained.

Quorum: the number of elements in each server set of the distributed system is usually odd. The Server is a node in the distributed system, and each Server maintains a memory database of the distributed system, and transaction logs and snapshot data which are stored in a lasting mode. Quorum may also be referred to as a node set of a distributed system.

Master node (Leader): the master server selected by at least half of the servers in the node set of the distributed system is responsible for making proposals for transaction operations (Proposal), and synchronizing data targeted by the transaction operations to the servers in the distributed system. Where transactional operations are operations that "write" or the like can change the consistency of data in the distributed system, i.e., can change the state of the distributed system. In a specific application, the above-described operation may be in the form of an access request, for example, the write operation may be a write-type access request.

Slave node (Follower): the slave server in the node set of the distributed system directly responds to non-transaction operations such as reading of a user, forwards transaction operations such as writing of the user to the master node for processing, receives a proposal (Proposal) from the master node, correspondingly updates a transaction log and a mirror image local to the slave node, and modifies the state of the memory database.

Consistency protocol: for maintaining consistency of data stored by nodes in the distributed system, i.e., for making the data stored by nodes in the distributed system uniform. In this specification, a consistency protocol of a distributed system in which one master node exists.

State machine (STATE MACHINE): the state record of the memory database is generally obtained by performing structured storage on log data in a memory.

Failover (failover): when an active service or application terminates unexpectedly, a redundant or standby server, system, hardware, or network is quickly enabled to work over the active service or application.

In a specific application, when a master node is disconnected from a slave node, for example, when the master node is down, the software version of the master node is updated, and the network between the master node and the slave node is unavailable, the master node needs to be switched, and the master node is unavailable. And the master node is responsible for transactional operation, initiates system consistency judgment of data aimed at by the transactional operation, and can ensure the consistency of the data in the distributed system. The node consistency judgment is as follows: the master node initiates consistency judgment of target data aimed by the access request to each slave node according to a consistency protocol, namely, makes proposal. In this proposal, the master node synchronizes the target data, i.e. resolves, to each slave node, which verifies the received target data: judging whether the target data meets the preset check condition, recording the target data meeting the preset check condition in a data log, and sending a feedback result of whether the resolution is agreed to the master node. Wherein for each resolution sent by the master node, the slave node typically agrees with the resolution, and the slave node disagrees with the resolution unless it falls behind or is abnormal. On the basis, after the master node determines to obtain the consent of most slave nodes to the resolution based on the received feedback result, the master node sends a commit request of the resolution to each slave node which agrees to the resolution, and the slave node writes target data in the data log into an application queue according to the received commit request. Thus, the application queue records data that satisfies node consistency: the recorded data is identical in each node of the distributed system. Therefore, in order to prevent consistency exception caused by unavailability of the master node, the connection between each slave node and the client in the distributed system is disconnected, so as to trigger reconnection of the client. Therefore, in the case of hundreds of thousands of connections, the server is prone to breakdown caused by avalanche access pressure: and cannot be recovered. To this end, a layer of Proxy (Proxy) may be added between the client and the distributed system for forwarding the client request. In this way, the agent can stop interaction with the clients when the master node is switched, and connection reconnection caused by the master node switching can be reduced without disconnecting all the clients. However, this approach is prone to the problem of inconsistent nodes of the distributed system accessed by the proxy before and after the switching of the master node caused by failover, and in the scenario that the client has a requirement for consistency of the access request sequence, the consistency of the client sequence cannot be ensured.

In addition, the disconnection easily causes the problem of lost locks of clients that rob to the distributed locks. Wherein, distributed lock refers to: a distributed coordination technique for scheduling a plurality of processes in a distributed system in order to prevent interference between the plurality of processes. The core idea of the distributed lock is: in a distributed system, a method can only be executed by one thread of one machine at a time. Thus, the client that preempts the distributed lock is the one machine or one thread.

As shown in fig. 1, fig. 1 shows a schematic service framework of a distributed system according to an embodiment of the present disclosure. Specifically, the method comprises the following steps: the distributed system ensures that distributed data has consistency, namely a Server set called Quorum, and the elements in the set are nodes in the distributed system, namely a Server. When the distributed system is started, the distributed system selects one server as a master node and the rest as slave nodes according to the current record information of each server. In a specific application, more than half of the slave nodes participate in the method, so that the master node can be elected. Each node includes a plurality of access requests that the master node may receive from a user via a client. In one case, the same client may require sequential consistency among multiple access requests of the client, that is, the client sequentially sends the access requests to nodes of the distributed system, and the nodes of the distributed system sequentially feed back the response results of the access requests to the client.

In view of the above, in the present specification, an access request response method is provided, and the present specification relates to an access request response apparatus, a distributed system, a computing device, and a computer-readable storage medium, which are described in detail in the following embodiments one by one.

Referring to fig. 2, fig. 2 shows a flowchart of an access request response method provided according to an embodiment of the present disclosure, which is applied to a slave node of a distributed system, and specifically includes the following steps:

And S202, stopping writing the data in the data log into an application queue when the disconnection with the main node is detected, wherein the data log records the data to be subjected to the node consistency judgment, and the application queue records the data meeting the node consistency judgment condition.

In a specific application, the master node is disconnected from the slave node, for example, the master node is down, the master node software version is updated, and the network between the master node and the slave node is unavailable. Illustratively, detecting a disconnection from the master node may include: and the slave node sends a heartbeat detection packet to the master node, and receives feedback of the master node when the heartbeat detection packet is not within a preset time period or when the heartbeat detection packet does not reach a sending frequency threshold value. Or, illustratively, detecting disconnection from the master node may include: the slave node receives a notification that the master node is performing a software version update. Any manner in which a disconnection from the master node may be detected may be used in the present description, and this embodiment is not limited in this regard. The node consistency judging condition comprises the following steps: the data stored in each node in the distributed system is the same. Therefore, the node consistency determination condition may specifically be a determination condition that satisfies consistency specified by the consistency protocol.

In the process of judging the consistency of the nodes, the master node initiates the consistency judgment of the target data aimed by the access request to each slave node according to the consistency protocol, namely, makes proposal. In this proposal, the master node synchronizes target data to each slave node, and each slave node verifies the received target data: judging whether the target data meets a preset check condition, recording the target data in a data log, and feeding back a check result to a master node; the master node obtains a judging result of whether the target data meets the node consistency based on the resolution result fed back by each slave node, and sends the judging result to each slave node, and the slave node performs processing of writing or not writing the target data in the data log into the application queue according to the received judging result. Thus, the data log records data to be subjected to node consistency judgment. Thus, the node consistency judgment is completed by judging whether the data aimed at by the access request meets the consistency judgment condition. Accordingly, the application queue records data meeting the node consistency judging condition, which means that the application queue records data meeting the node consistency.

For example, in the case that the master node and the slave node are normally connected, in order to persist data meeting the node consistency judging condition, the slave node invokes the consistency protocol module to complete the node consistency judging, and obtains that the data recorded in the data log meets the node consistency condition, and then the consistency protocol module pushes the data aimed by the access request to the application queue. Under the condition that the master node is disconnected from the slave nodes, the master node cannot feed back information to the slave nodes, and the slave nodes cannot obtain the node consistency judging result of the data recorded in the data log. Then, whether the data recorded in the data log completes the above-mentioned node consistency judgment is in a Fuzzy (Fuzzy) state for the slave node: may or may not be completed. Therefore, when the connection is disconnected, the data in the data log is stopped from being written into the application queue, namely the consistency protocol module stops pushing the data aimed at by the access request to the application queue, so that the problem of abnormal consistency caused by responding to the access request corresponding to the data based on the data which is judged by incomplete node consistency and feeding back the response result to the client can be prevented. In addition, in consideration of the fuzzy state, before the distributed system elects a new master node, the data recorded in the data log can be regarded as the data to be subjected to the node consistency judgment.

S204, matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded.

In a specific application, the wait queue records access requests to be responded to. Therefore, the access request in the waiting queue is matched with the data in the application queue, and the data aiming at the first access request which is successfully matched is the data which completes the node consistency judgment and meets the node consistency judgment condition. Therefore, the first access request can be responded, and the connection of the first client corresponding to the first access request successfully matched can be maintained without disconnection under the condition of disconnection with the master node. And, for the connection of the second client corresponding to the second access request which is not successfully matched with the application queue, the processing mode can be disconnected or maintained. In one case, after disconnecting from the second client, the client may be triggered to reconnect, thereby resending the second access request, and the slave node may then respond to the second access request if a new master node is elected. At this time, the connection with the second client is disconnected, so that the problem that the user waits because the second client waits for selecting a new master node and cannot respond timely can be avoided, and the negative influence of the disconnection of the master node on the user experience is reduced.

In an optional implementation manner, after the matching between the access request in the waiting queue and the data in the application queue, the access request response method provided in the embodiment of the present disclosure may further include the following steps: and maintaining the connection of the second client corresponding to the second access request which is not successfully matched. In the present embodiment, since the writing of the data in the data log into the application queue has been stopped by the above-described step S202, the data in the application queue are all data conforming to the consistency condition. In this way, when the connection with the second client is maintained, the second access request which is not successfully matched is not responded, and consistency exception is unlikely to happen. Therefore, the embodiment can ensure that each client does not need to be disconnected under the condition that the master node is disconnected, and the availability of the distributed system is higher. On the basis, under the condition of electing a new master node, the slave node can respond to the second access request again, and node consistency judgment can be carried out on the data aimed by the second access request again. In one case, different types of access requests have different consistency requirements, so performing step S204 may specifically include identifying the type of access request and then responding differently to the different types of access requests. Accordingly, different processes may be performed for the connection between clients corresponding to different types of access requests. The following description is provided in terms of alternative embodiments for ease of understanding and rational layout.

S206, responding to the first access request, and returning a response result to the first client.

In a specific application, responding to the first access request means that a response result of the first access request is obtained based on data successfully matched with the first access request in an application queue. For example, if the first access request is an operation of reading data, the data that is successfully matched may be used as a response result; if the first access request is an operation of writing data, information such as the successfully matched data is written in can be taken as a response result, which is reasonable. The specific response manner may be adapted to the application scenario, which is not limited in this embodiment. And, in a scenario where there is a sequential consistency requirement of access requests at the client, the consistency requirement is satisfied in response, and this will be described in detail in the form of alternative embodiments for ease of understanding and rational layout. In addition, after a new master node is elected, the role type of the slave node can have different response modes to the access request received by the slave node, and for convenience of understanding and reasonable layout, the following description will specifically describe the access request in the form of alternative embodiments.

In one embodiment of the present disclosure, when a slave node of a distributed system is disconnected from a master node, writing data in a data log into an application queue is stopped, so as to avoid a problem of consistency exception caused by feeding back data, which is not determined whether to perform node consistency judgment by the master node, to a client under a condition that the master node is disconnected. On the basis, normal feedback can be carried out on the data written into the application queue, so that connection between the first client ends corresponding to the first access request matched with the data in the application queue can be maintained, the first access is responded, and a return result is returned to the first client ends. Therefore, the method can avoid consistency abnormality caused by disconnection of all clients and response abnormality to each access request under the condition that connection of all clients is not required to be disconnected, thereby greatly reducing the pressure of the distributed system caused by reconnection after disconnection of all clients and ensuring the working performance of the distributed system. Therefore, the scheme can ensure that the availability of the distributed system is higher when the distributed system is disconnected with the master node.

In an optional implementation manner, the matching between the access request in the waiting queue and the data in the application queue may specifically include the following steps:

identifying a request type of the access request in the waiting queue, and matching the access request with the request type being a write type with data in the application queue;

accordingly, the responding to the first access request may specifically include the following steps:

based on the data successfully matched with the access request of the write type, a response result of the access request of the write type is obtained.

Wherein the request type of the access request is used for characterizing the operation of the access request on the data. By way of example, the request types of the access request may include: read type, write type, etc. In a specific application, the access request may include an identifier representing the request type (type), such as a read identifier of the read type and a write identifier of the write type. Thus, the slave node may identify the request type of the access request in the wait queue by reading that the access request in the wait queue contains a request type identification. Since write-type access requests, i.e., write requests, etc., can change the state of data in a distributed system, the coherency requirement of the write requests is a requirement for node coherency. This means that the data for which the write request is directed is recorded in the application queue if the consistency requirement is met. Thus, matching with the data in the application queue can be performed for access requests whose request type is a write type. In this way, the embodiment matches the access request with the application queue, which has the node consistency requirement, so that redundant matching of the queue which does not need to be matched can be reduced, and the more efficient effect of the access request is realized.

And, based on the data successfully matched with the access request of the write type, obtaining the response result of the access request of the write type can specifically include: generating information written in the successfully matched data to obtain a response result; or acquiring the storage position of the successfully matched data, and generating feedback information containing the storage position to obtain a response result. This is reasonable, and may be specifically responded according to the application requirement, which is not limited in this embodiment.

In an optional implementation manner, after stopping writing the data in the data log to the application queue, the access request response method provided by the embodiment of the present invention may further include the following steps:

Maintaining connection of a third client corresponding to a third access request, wherein the third access request is an access request with a request type of a read type;

And reading data matched with the third access request in the data locally stored in the slave node, obtaining a response result of the access request of the read type, and returning the response result to the third client.

In a specific application, the read-type access request, i.e. the read request, does not change the state of the data in the distributed system, and therefore there is no need for node consistency for the read request. Therefore, in this embodiment, the access request of the read type may directly read the data matching the third access request from the data stored locally in the node. For example, data matching the third access request is read from the state machine, and a response result of the read-type access request is obtained. For example, the read data may be directly used as a response result, or the read data may be packaged, etc. to obtain a response result of the read type access request. Accordingly, at this time, for the third client corresponding to the read-type access request, the connection can be maintained, so as to normally feed back the response result, thereby further reducing the number of clients that need to be disconnected under the condition of disconnection from the main contact, and realizing the effect of higher availability of the distributed system. Moreover, the third client is usually the client that robs to the distributed lock, so the connection of the client that robs to the distributed lock can be reduced to the greatest extent, and the risk of losing the lock is avoided.

In an optional implementation manner, after the matching between the data in the application queue and the access request with the request type being the write type is performed on the access request, the access request response method provided in the embodiment of the present disclosure may further include the following steps:

If the matching fails, starting from the access request of the current writing type, polling the access request in the waiting queue, and adding the client corresponding to each access request of the writing type into a client removing set;

and disconnecting the connection with the client contained in the client removal set.

In a specific application, if the corresponding data can be found in an application Queue (Apply Queue), that is, the matching is successful, the data can be applied to a state machine (STATEMACHINE), that is, the data is stored in the state machine, so as to implement persistent storage. In this way, the read request can be obtained directly from the state machine when it reads the data. If the match fails, the wait queue may be paused. Moreover, the access requests in the queue are usually processed according to a first-in first-out rule, so that the first matching failure indicates that none of the subsequent write requests is added to the application queue, and the matching must fail. Thus, at this time, the access requests in the waiting queue may be polled from the current write request, and clients corresponding to the respective access requests of the write type may be added to the client removal set. In this way, in this embodiment, from the first matching failure, the matching between the waiting queue and the application queue is no longer performed, and the client corresponding to the write-type access request is directly polled and removed, so that the time consumed in matching can be reduced, and the effect of higher response efficiency of the access request is achieved.

The second client corresponding to each access request of the write type is a second client, that is, the second client is added to the client removal set, for example, the client session id of the second client is added to the client removal set (RemoveClientSet). In this way, the present embodiment can realize disconnection of the connection with the second client.

In an optional implementation manner, any client side has a consistency requirement of the sequence of the access requests, the request identifiers of all the access requests of the same client side are set according to the sequence, and the data requested by the access requests correspond to the request identifiers; the number of the first access requests is a plurality;

obtaining a first access request queue containing each first access request based on the sequence of the request identifications of each first access request;

according to the first-in first-out principle, carrying out request identification matching on each first access request in the first access request queue and the data in the application queue, and obtaining a response result queue of each first access request based on the successfully matched data;

Correspondingly, the step of returning the response result to the first client may specifically include the following steps:

and returning the response result in the response result queue to the first client according to the first-in first-out principle.

In a specific application, the requirement of consistency of the access request existence sequence of any client means that any client sequentially sends the access request to the nodes of the distributed system, and the nodes of the distributed system sequentially feed back the response result of the access request to the client. Therefore, the sequential feedback of the response can be realized through the request identification of each access request which is set according to the sequence, and the access requests are processed by forming a queue according to the sequence, so that the requirement of the client for the consistency of the sequence is more reasonably met.

The following describes the access request response method in a multi-layer asynchronous queue scenario by taking an application of the access request response method provided in the present specification as an example with reference to fig. 3 and fig. 4. FIG. 3 illustrates an architectural diagram of a distributed system in a multi-layered asynchronous queue scenario provided by one embodiment of the present description.

Illustratively, in the distributed system shown in FIG. 3, client: the user may send an access request through the client. Duplicate: the copy for the master node to synchronize transaction requests, such as write requests, to the coherence protocol module coherent for node coherence determination by proposing. The copy is specifically a copy of the data for which the write request was proposed by the master node. The consistency protocol module present is used for realizing data collaboration among the nodes, namely, can be used for finishing node consistency judgment, and can be specifically realized according to a consistency protocol such as Raft, paxos and the like. Raft is a consistency algorithm, and mainly comprises three modules of master node election, log replication and security. Paxos is a coherence protocol that addresses how various processes in a distributed system agree on a certain value (resolution). In the present specification, the above resolution requires that each node record in a data log, and waits for a master node to determine whether or not consistent data is satisfied. Log module Log: the data, i.e. resolution, used for judging the consistency of the nodes is recorded in a data log. State machine STATE MACHINE: the data in the data log is subjected to node consistency judgment and is added to the application queue under the condition of consistency, and the successfully matched data can be added to the state machine under the condition that the data in the application queue is successfully matched with the access request in the waiting queue, so that the corresponding data can be directly obtained from the state machine for non-transaction requests such as read requests and the like. As shown in fig. 3, the above modules are applicable to nodes of distributed systems, where the proposal made by the master node is not made by the slave node, and therefore the slave node does not perform the steps of initiating the consistency proposal and replying as described above.

In the case where disconnection from the master node is not detected, taking the case where the slave node receives the access request as an example, the processing flow of the access request by the distributed system shown in fig. 3 includes the following steps:

① Request: the user sends an access request to the slave node. ② Put: the access requests are placed at the end of a request queue (Request Quoue) and the access requests from the access request queue are handled one by one in a first-in first-out manner. ③ Forward Request: if the currently processed access request is a transaction operation such as a write request, the transaction operation is forwarded to a master node for processing, and the access request ③ Put is Put at the end of a waiting Queue (Pending Queue); if the currently processed access request is a non-transaction access request such as a read, the currently processed access request is directly placed at the end of the waiting queue.

④ Propose: when the master node receives the access request forwarded from the slave node, the access request is firstly put into a proposal queue (Propose queue, which is not shown in fig. 3 for simplicity of illustration), the access request in the proposal queue is checked before being submitted, and if the check is successful, the data aimed at by the access request is submitted to a consistency protocol module (consistence) by using Replica; wherein, the checking may include: and verifying the validity of the request, such as whether the session of the client connection is expired, whether the access request has the right to operate the target path, and the like. ⑤ Consensus Protocol: the consistency protocol module performs node consistency determination according to the consistency protocol Consensus Protocol to obtain a resolution that may be recorded in the data log. ⑥ application: when a resolution is obtained based on the data for which the access request is intended, the data may be persisted in a data Log of the Log module Log. And notifying the master node of the event that the data has been submitted so that the master node confirms whether the data meets the node consistency judgment condition in each node.

⑦ On Apply: when the node consistency judging condition is met, the data in the data log is put at the end of an application Queue (Apply Queue). ⑧ Match & Apply: the data in the application queue is matched with the access request in the waiting queue (Pending Quoue), and if the matching can be successfully performed, the data is indicated to correspond to the access request sent by the client on the node. Thus, the successfully matched data may be applied to, i.e., stored in, the state machine, and responsive to the corresponding access request based on the data, a Response result is returned to the client. In addition, the numbers in each queue and log module in fig. 3 are identifications of access requests.

For the distributed system shown in fig. 3, when the master node is down or service is upgraded, the slave node is disconnected from the master node. In this regard, as shown in the exemplary diagram of the state of each asynchronous queue after the master node and the slave node are disconnected in the multi-layer asynchronous queue scenario provided in the embodiment of the present disclosure in fig. 4:

When the slave node is disconnected from the master node in the distributed system shown in fig. 3, the difference between the processing manner of disconnecting all clients is that this embodiment does not disconnect all clients, and does not empty the data in the request Queue Request Quoue and the wait Queue PendingQuoue, but makes the threads of the different queues suspend processing the access requests in the respective queues, and invokes the consistency protocol module (requests) to stop putting the data for the access requests into the application Queue (Apply Queue). At this point, the slave node enters the Fuzzy state. Referring to fig. 4, each access request contains the following fields: clientID, sessionID and requestID. Wherein clientID: for each client, the server assigns a unique corresponding session id to the client for marking the client. requestID: each client's access request will also have a requestID indicating its access request order, an ascending integer starting from 1, and for systems requiring client order consistency, the server needs to ensure that access request responses are returned to the clients in the order of the requestids. type: the types of access requests are largely divided into two main categories, read access requests (reads) and write access requests (writes). The read access request is a weak consistency read, and the data in the corresponding node state machine is directly read without a consistency protocol, so that the sequential consistency of the client is ensured. Write access requests need to be submitted by a Leader and synchronized to a number of nodes greater than a number threshold by a coherency protocol before being applied to the state machine.

In the case where the slave node enters the Fuzzy state, as shown in fig. 4: processing the data in each different step queue according to an uncertain access request removing mechanism and an access request processing maximum response principle: all access requests in the waiting Queue (Pending Queue), here the access request handling maximum response principle is introduced: according to the first-in first-out processing, for the read access request, directly reading data in the state machine, and returning a response result corresponding to the read data to the client; for write access requests, if a corresponding access request can be found in an application Queue (Apply Queue), then it is applied to the state machine (STATEMACHINE). If the corresponding access request cannot be found in the application Queue (Apply Queue), processing according to an uncertain access request removal mechanism: waiting for the queue to suspend processing; and polling the access requests in the queue from the current write access request, adding the session IDs of all the write access requests to the client removal set (RemoveClientSet), wherein the element in the client set waiting for the queue to have no corresponding write access request in FIG. 4 is session3. This is an unknown state because the client removes access requests in the collection that may have been sent to the original Leader, but the Leader may not have been submitted or has been submitted to the coherency protocol module. If no commit occurs, the waiting queue may be caused to wait for the access request to correspond, and be in a waiting state. Thus, the closed connection with the client in the client removal set (RemoveClientSet) may be closed. And, find all access requests that the session corresponds to in the client remove set in the access request Queue (Request Quoue) and waiting Queue (Pending Queue) to remove, in order to prevent the duplicate access request from appearing after reconnecting the removed client.

When the above removal of the access request is completed, only the read access request which is not removed remains in the waiting Queue (Pending Queue), and the read access request may directly read the state machine data without performing node consistency judgment. For data in an application Queue (Apply Queue), according to a normal processing manner, all the data in the application Queue find a corresponding access request in a waiting Queue (Pending Queue) according to a first-in first-out manner, and Apply the access request to a state machine (STATEMACHINE). And, after the access request queue (Request Quoue) removes all access requests of removing the set session, the client access request is normally received and put at the tail of the queue until the consistency protocol module elects a new master node, and the access request processing is performed. And, for clients that are not removing the collection, the connection remains normal and the access request continues to be sent.

Based on the processing of the embodiment of fig. 4, as shown in an example graph of an application result of an access request response method in a multi-layer asynchronous queue scenario provided in an embodiment of the present specification in fig. 5, the example graph is as follows: the slave (Follower) node at least keeps the client connection in a certain state by introducing the Fuzzy mode and normally receives the access request, so that the problem that the service end is not available due to the fact that the connection of all the clients is disconnected when the slave node is disconnected with the master node is solved, and the problem that the service end is involved in processing a large number of reconnection requests is solved. As shown in fig. 5, TCP connection is maintained for clients client1, client2, client4, so that client1, client2, client4 can normally obtain response results. Among them, TCP is a transmission control protocol, english holly Transmission Control Protocol, which is a connection-oriented, reliable transport layer communication protocol based on byte streams. Further, depending on the characteristics of the client of the distributed lock, when the distributed lock is not released, only a heartbeat access request (read access request) is generally sent to maintain the validity of the distributed lock. Therefore, by introducing an uncertain access request removal mechanism and an access request processing maximum response principle, the connection of the client terminal robbing the distributed lock can be reduced to the greatest extent, and the risk of losing the lock is avoided.

In an optional implementation manner, after the disconnection from the master node is detected, the access request response method provided by the embodiment of the present disclosure may further include the following steps:

Identifying the role type of the slave node when detecting that a new master node is elected;

and determining a verification mode corresponding to the role type, and verifying the access request in the waiting queue according to the verification mode.

In particular applications, the role types of nodes in a distributed system may characterize differences in node functionality. And, the difference of node functions in the distributed system is reflected in different verification modes of the access request. Therefore, after the master node is switched, the slave node has different roles and different verification modes on the request. Therefore, the problem of abnormal verification when the node performs access request verification according to the role type before the new master node is selected can be avoided, and the effect of smoother master node switching is achieved.

Illustratively, detecting electing a new master node may include: and receiving a notification of the completion of the election of the master node sent by the consistency protocol module. Identifying the role type of the slave node may specifically include: the notification of the completion of the master node election may carry a node identifier of the master node, and the slave node may identify whether the node identifier is a node identifier of the slave node itself, if so, the role type of the slave node is the master node type, and if not, the role type of the slave node is the slave node type. And, determining a verification manner corresponding to the role type may specifically include: searching a pre-established corresponding relation between the role type and the verification mode to obtain the verification mode corresponding to the role type of the slave node.

In an optional implementation manner, the checking the access request in the waiting queue according to the checking manner may specifically include the following steps:

if the role type of the slave node is the master node type, the access request in the waiting queue is added to the queue to be checked, and the access request in the queue to be checked is checked according to the first-in first-out principle.

In a specific application, the verification may include: and verifying the validity of the request, such as whether the session of the client connection is expired, whether the access request has the right to operate the target path, and the like. In an exemplary manner, in connection with the description of the embodiment of fig. 4, as shown in an exemplary diagram of a processing procedure of an access request in a scenario where a role type of a slave node is a master node type in an access request response method provided in an embodiment of the present specification of fig. 6, the processing procedure is shown in the following example diagram: the original Follower role is changed to the Leader role, namely the slave node- > the master node, in which case the access requests in the access Request Queue (Request Queue) are sequentially inserted into the proposal Queue (Propose Quoue), and the access requests of the subsequent clients, for example, the access Request new Request of the client4 and the access requests forwarded by other Follower nodes, are all put into the tail of the proposal Queue according to the receiving order, and then the corresponding data is submitted to the coherence protocol module through Replica. And the client (session 3) with the connection closed will randomly reestablish connection with the serviceable node in the cluster. Therefore, the embodiment provides a smooth mechanism for coping with the switching of the master node, receives and stores the client access requests through the asynchronous queue, and realizes the process of converting Follower into a Leader without changing the access request sequence, thereby ensuring the consistency of the access request sequence of each client.

And if the role type of the slave node is the slave node type, sending the access request in the waiting queue to a new master node so that the new master node initiates verification of the access request in the waiting queue.

In this embodiment, the role of the slave node is unchanged, so that the access request in the waiting queue is still sent to the new master node in a manner under the normal processing flow, so that the new master node initiates verification of the access request in the waiting queue. The specific process of the new master node initiating the check of the access request in the waiting queue may be referred to the description of the embodiment of fig. 6, and the process is the same and will not be repeated here. In this way, in the scenario that the master node switches, that is, elects a new master node, the embodiment can ensure the processing of the access request under the condition that the role of the slave node is unchanged through node role identification.

Corresponding to the method embodiment, the present disclosure further provides an access request response device embodiment, and fig. 7 shows a schematic structural diagram of an access request response device provided in one embodiment of the present disclosure. As shown in fig. 7, the apparatus applied to a slave node of a distributed system includes:

A stopping module 702 configured to stop writing data in the data log into the application queue when disconnection from the master node is detected, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting the node consistency judgment condition;

A matching module 704, configured to match an access request in a waiting queue with data in an application queue, and maintain connection of a first client corresponding to a successfully matched first access request, where the waiting queue records the access request to be responded;

the response module 706 is configured to respond to the first access request and return a response result to the first client.

Optionally, the matching module 704 is further configured to:

after the access request in the waiting queue is matched with the data in the application queue, the connection of the second client corresponding to the second access request which is not successfully matched is maintained.

Optionally, the matching module 704 is further configured to:

accordingly, the response module 706 is further configured to:

Optionally, the response module 706 is further configured to:

Optionally, the matching module 704 is further configured to:

After matching the access request with the request type being the write type with the data in the application queue, if the matching fails, starting from the access request with the current write type, polling the access request in the waiting queue, and adding the client corresponding to each access request with the write type into the client removal set;

Optionally, the consistency requirement of the access request existence sequence of any client side is met, the request identifiers of all the access requests of the same client side are set according to the sequence, and the data requested by the access requests correspond to the request identifiers; the number of the first access requests is a plurality;

accordingly, the response module 706 is further configured to:

Optionally, the apparatus further includes: a verification module configured to:

Optionally, the verification module is further configured to:

The above is an exemplary scheme of an access request responding device of the present embodiment. It should be noted that, the technical solution of the access request response device and the technical solution of the access request response method belong to the same concept, and details of the technical solution of the access request response device, which are not described in detail, can be referred to the description of the technical solution of the access request response method.

Corresponding to the above method embodiments, the present disclosure further provides a distributed system embodiment, and fig. 8 shows a schematic structural diagram of a distributed system provided in one embodiment of the present disclosure. As shown in fig. 8, the distributed system 800 includes: a slave node 802, a master node 804, and a first client 806;

A slave node 802 configured to stop writing data in a data log into an application queue when disconnection from a master node 804 is detected, wherein the data log records data to be subjected to node consistency judgment, and the application queue records data meeting node consistency judgment conditions; matching the access request in the waiting queue with the data in the application queue, and maintaining the connection of the first client corresponding to the successfully matched first access request, wherein the waiting queue records the access request to be responded; responding to the first access request, and returning a response result to the first client 806;

the first client 806 is configured to receive the response result.

Optionally, the slave node 802 is further configured to:

Accordingly, slave node 802 is further configured to:

Optionally, the slave node 802 is further configured to identify a role type of the slave node when detecting election of a new master node after detecting disconnection from the master node;

Optionally, the slave node 802 is further configured to:

The above is a schematic solution of a distributed system of the present embodiment. It should be noted that, the technical solution of the distributed system and the technical solution of the access request response method belong to the same concept, and details of the technical solution of the distributed system, which are not described in detail, can be referred to the description of the technical solution of the access request response method.

Fig. 9 illustrates a block diagram of a computing device provided in accordance with one embodiment of the present specification. The components of computing device 900 include, but are not limited to, memory 910 and processor 920. Processor 920 is coupled to memory 910 via bus 930 with database 950 configured to hold data.

Computing device 900 also includes an access device 940, access device 940 enabling computing device 900 to communicate via one or more networks 960. Examples of such networks include public switched telephone networks (PSTN, public Switched Telephone Network), local area networks (LAN, local Area Network), wide area networks (WAN, wide Area Network), personal area networks (PAN, personal Area Network), or combinations of communication networks such as the internet. The access device 940 may include one or more of any type of network interface, wired or wireless, such as a network interface card (NIC, network Interface Controller), such as an IEEE802.11 wireless local area network (WLAN, wireless Local Area Networks) wireless interface, a worldwide interoperability for microwave access (Wi-MAX, worldwide Interoperability for Microwave Access) interface, an ethernet interface, a universal serial bus (USB, universal Serial Bus) interface, a cellular network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.

In one embodiment of the present description, the above-described components of computing device 900 and other components not shown in FIG. 9 may also be connected to each other, for example, by a bus. It should be understood that the block diagram of the computing device illustrated in FIG. 9 is for exemplary purposes only and is not intended to limit the scope of the present description. Those skilled in the art may add or replace other components as desired.

Computing device 900 may be any type of stationary or mobile computing device including a mobile computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), mobile phone (e.g., smart phone), wearable computing device (e.g., smart watch, smart glasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 900 may also be a mobile or stationary server.

Wherein the processor 920 is configured to execute computer-executable instructions that, when executed by the processor, implement the steps of the access request response method described above.

The foregoing is a schematic illustration of a computing device of this embodiment. It should be noted that, the technical solution of the computing device and the technical solution of the access request response method belong to the same concept, and details of the technical solution of the computing device, which are not described in detail, can be referred to the description of the technical solution of the access request response method.

An embodiment of the present disclosure also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described access request response method.

The above is an exemplary version of a computer-readable storage medium of the present embodiment. It should be noted that, the technical solution of the storage medium and the technical solution of the access request response method belong to the same concept, and details of the technical solution of the storage medium which are not described in detail can be referred to the description of the technical solution of the access request response method.

An embodiment of the present specification also provides a computer program, wherein the computer program, when executed in a computer, causes the computer to perform the steps of the above access request response method.

The above is an exemplary version of a computer program of the present embodiment. It should be noted that, the technical solution of the computer program and the technical solution of the access request response method belong to the same concept, and details of the technical solution of the computer program, which are not described in detail, can be referred to the description of the technical solution of the access request response method.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The computer instructions include computer program code that may be in source code form, object code form, executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.

It should be noted that, for simplicity of description, the foregoing method embodiments are all expressed as a series of combinations of actions, but it should be understood by those skilled in the art that the embodiments are not limited by the order of actions described, as some steps may be performed in other order or simultaneously according to the embodiments of the present disclosure. Further, those skilled in the art will appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily all required for the embodiments described in the specification.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and for parts of one embodiment that are not described in detail, reference may be made to the related descriptions of other embodiments.

The preferred embodiments of the present specification disclosed above are merely used to help clarify the present specification. Alternative embodiments are not intended to be exhaustive or to limit the invention to the precise form disclosed. Obviously, many modifications and variations are possible in light of the teaching of the embodiments. The embodiments were chosen and described in order to best explain the principles of the embodiments and the practical application, to thereby enable others skilled in the art to best understand and utilize the invention. This specification is to be limited only by the claims and the full scope and equivalents thereof.

Claims

1. An access request response method applied to a slave node of a distributed system comprises the following steps:

2. The access request response method according to claim 1, further comprising, after the matching of the access request in the waiting queue with the data in the application queue:

and maintaining the connection of the second client corresponding to the second access request which is not successfully matched.

3. The access request response method of claim 1, the matching of the access request in the wait queue with the data in the application queue, comprising:

identifying a request type of the access request in the waiting queue, and matching the access request with the write type as the request type with data in the application queue;

accordingly, the responding to the first access request includes:

And obtaining a response result of the access request of the write type based on the data successfully matched with the access request of the write type.

4. The access request response method of claim 3, further comprising, after the stopping writing the data in the data log to the application queue:

5. The access request response method according to claim 3, further comprising, after the matching with the data in the application queue is performed on the access request whose request type is a write type:

And disconnecting the connection between the client and the client contained in the client removing set.

6. The access request response method according to any one of claims 1 to 5, wherein, a consistency requirement of an access request existence sequence is given to any client, request identifiers of access requests of the same client are set according to the sequence, and data requested by the access requests correspond to the request identifiers; the number of the first access requests is a plurality;

accordingly, the responding to the first access request includes:

according to the first-in first-out principle, carrying out request identification matching on each first access request in a first access request queue and the data in the application queue, and obtaining a response result queue of each first access request based on the successfully matched data;

the returning the response result to the first client side comprises the following steps:

7. The access request response method according to any one of claims 1 to 5, further comprising, after the detecting of disconnection from the master node:

8. The access request response method according to claim 7, wherein said checking the access request in the waiting queue according to the checking method includes:

And if the role type of the slave node is the master node type, adding the access request in the waiting queue to a queue to be checked, and initiating check on the access request in the queue to be checked according to a first-in first-out principle.

9. The access request response method according to claim 7, wherein said checking the access request in the waiting queue according to the checking method includes:

and if the role type of the slave node is the slave node type, sending the access request in the waiting queue to the new master node so that the new master node initiates verification of the access request in the waiting queue.

10. An access request response apparatus applied to a slave node of a distributed system, comprising:

11. A distributed system, comprising: a slave node, a master node, and a first client;

the first client is configured to receive the response result.

12. A computing device, comprising:

A memory and a processor;

The memory is configured to store computer executable instructions, the processor being configured to execute the computer executable instructions, which when executed by the processor, implement the steps of the access request response method of any one of claims 1 to 9.

13. A computer readable storage medium storing computer executable instructions which when executed by a processor implement the steps of the access request response method of any one of claims 1 to 9.