CN108206779B - A cluster access system, method and device - Google Patents

Abstract

The embodiment of the invention provides a cluster access system, a cluster access method and a cluster access device, wherein in the method, a proxy server firstly receives a target request which is sent by a target client and used for accessing a target cluster; determining a first main node from all main nodes of a target cluster; sending the target request to the first host node; then receiving feedback information fed back by the first main node; judging whether the feedback information is steering information; if yes, analyzing the feedback information to obtain a node identifier as a first identifier; and sending the target request to the main node corresponding to the first identifier, so that the main node corresponding to the first identifier responds to the target request. In the scheme provided by the embodiment of the invention, the client is in communication connection with the cluster through the proxy server, the interaction between the client and the cluster is completed by the proxy server, the access operation required to be executed by the client is simple and not complicated, and the expansion of the cluster has no influence on the client.

Description

A cluster access system, method and device

technical field

The present invention relates to the field of computer technology, and in particular, to a cluster access system, method and device.

Background technique

A cluster is a group of independent computers interconnected by a high-speed network that form a group and are managed as a single system. When a client interacts with the cluster, the cluster acts like an independent server, providing unified services to the outside world. The cluster consists of multiple nodes, including the master node and the slave node. For a cluster without a central master node, each master node in the cluster has the same status in the entire cluster, and each master node can be responsible for processing a part of the client. ask.

In the prior art, a cluster access system usually includes: a client and a cluster, wherein, for a cluster without a central node, the client can directly communicate with all master nodes in the cluster, that is, the client can directly access any one of the clusters. Master node; such as common redis (an open source Key-Value (key-value) database) cluster.

Usually, the client can successfully access the cluster by using the above method. However, in practical applications, due to changes in actual requirements, the master nodes contained in the cluster may not meet the actual needs, and it is necessary to increase the master node to expand the cluster. . However, after the cluster is expanded, it may affect the client's access to the cluster. Generally, the client needs to be adjusted accordingly to adapt to the expansion of the cluster. The number of clients that can access the cluster is usually large and widely distributed. Therefore, customers The adjustment of the terminal has a wide range of influence, which increases the difficulty of expanding the cluster.

SUMMARY OF THE INVENTION

The purpose of the embodiments of the present invention is to provide a cluster access system, method and device, so as to avoid the impact on the client when the cluster is expanded. The specific technical solutions are as follows:

In order to achieve the above object, in a first aspect, an embodiment of the present invention provides a cluster access system, the cluster access system includes: a client, a proxy server, and a cluster, the proxy server, the client, and each master node in the cluster communication connection,

the client, configured to send a target request for accessing the target cluster to the proxy server;

the proxy server, configured to receive the target request sent by the client; determine a first master node from each master node of the target cluster; send the target request to the first master node; receive The feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request to the second master node; wherein, the second master node is the master node corresponding to the first identifier;

the first master node, configured to receive the target request sent by the proxy server, and generate feedback information for the target request; send the feedback information to the proxy server;

The second master node is configured to receive the target request sent by the proxy server and respond to the target request.

Preferably, the target request includes a target key value,

The proxy server is specifically used for:

Calculate the target hash value corresponding to the target key value; query whether the target hash value exists in the routing table; if so, determine that the primary node corresponding to the target hash value in the routing table is the first primary node ; if not, randomly determine a master node as the first master node from each master node of the target cluster, wherein the routing table stores the corresponding relationship between the hash value and the identifier of the master node.

Preferably, the proxy server is also used for:

receiving the request success information corresponding to the target request fed back by the third master node; generating a corresponding relationship between the second identifier and the target hash value; updating the generated corresponding relationship into the routing table; wherein, the The third master node is the master node that successfully executes the request command corresponding to the target request, and the second identifier is the identifier of the third master node.

Preferably, the proxy server is also used for:

After receiving the target request sent by the client, determine whether the target request is safe;

If yes, execute the step of determining the first master node from each master node of the target cluster.

Preferably, the proxy server is specifically used for:

Determine the type of the steering information; if the steering information is MOVED information, directly send the target request to the second master node; if the steering information is ASK information, send an ASKING command to the second master node, and then send the ASKING command to the second master node. The target request is sent to the second master node.

In a second aspect, an embodiment of the present invention provides a cluster access method, which is applied to a proxy server, and the method includes:

Receive the target request sent by the target client to access the target cluster;

determining a first master node from each master node of the target cluster;

sending the target request to the first master node;

receiving feedback information fed back by the first master node;

Determine whether the feedback information is steering information;

If yes, parse and obtain the node identifier from the feedback information as the first identifier; send the target request to the second master node, so that the second master node responds to the target request; wherein the first The second master node is the master node corresponding to the first identifier.

Preferably, the target request includes a target key value,

The step of determining the first master node from each master node of the target cluster includes:

Calculate the target hash value corresponding to the target key value,

query whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identity of the master node;

If yes, determine that the master node corresponding to the target hash value in the routing table is the first master node;

If not, randomly determine one master node as the first master node from among the master nodes of the target cluster.

Preferably, the method further includes:

Receive the request success information corresponding to the target request fed back by the third master node; wherein, the third master node is the master node that successfully executes the request command corresponding to the target request;

generating a correspondence between a second identifier and the target hash value, wherein the second identifier is the identifier of the third master node;

The generated corresponding relationship is updated into the routing table.

Preferably, after the step of receiving the target request sent by the target client for accessing the target cluster, the method further includes:

Determine whether the target request is safe;

If yes, execute the step of determining the first master node from each master node of the target cluster.

Preferably, the step of sending the target request to the second master node includes:

determining the type of steering information;

If the steering information is MOVED information, directly send the target request to the second master node;

If the steering information is ASK information, send an ASKING command to the second master node, and then send the target request to the second master node.

In a third aspect, an embodiment of the present invention provides a cluster access device, which is applied to a proxy server, and the device includes:

a first receiving module, configured to receive a target request sent by the target client for accessing the target cluster;

a determining module, configured to determine the first master node from each master node of the target cluster;

a first sending module, configured to send the target request to the first master node;

a second receiving module, configured to receive feedback information fed back by the first master node;

a first judging module for judging whether the feedback information is steering information;

A second sending module, configured to parse and obtain a node identifier from the feedback information when the determination result of the first determination module is yes, as the first identifier; and send the target request to the second master node , so that the second master node responds to the target request; wherein, the second master node is the master node corresponding to the first identifier.

Preferably, the target request includes a target key value,

The determining module includes:

a calculation sub-module for calculating the target hash value corresponding to the target key value,

a query sub-module for querying whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identity of the master node;

a first determination submodule, configured to determine the master node corresponding to the target hash value in the routing table as the first master node when the target hash value exists in the routing table;

The second determination submodule is configured to randomly determine a master node as the first master node from each master node of the target cluster when the target hash value does not exist in the routing table.

Preferably, the device further includes:

a third receiving module, configured to receive the request success information corresponding to the target request fed back by a third master node; wherein, the third master node is a master node that successfully executes the request command corresponding to the target request;

a generating module, configured to generate a correspondence between a second identifier and the target hash value, wherein the second identifier is the identifier of the third master node;

An update module, configured to update the generated corresponding relationship into the routing table.

Preferably, the device further includes:

The second judging module is configured to judge whether the target request is safe after receiving the target request sent by the target client for accessing the target cluster; if so, trigger the determining module.

Preferably, the second sending module is specifically used for:

In the case that the judgment result of the first judgment module is yes, analyze and obtain the node identification from the feedback information as the first identification; determine the type of the steering information; if the steering information is MOVED information, directly Send the target request to the second master node; if the steering information is ASK information, send an ASKING command to the second master node, and then send the target request to the second master node.

It can be seen from the above that in the cluster access system, method and device provided by the embodiments of the present invention, the proxy server first receives the target request sent by the target client for accessing the target cluster; node; send the target request to the first master node; then receive the feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information, as the first an identifier; sending the target request to the master node corresponding to the first identifier, so that the master node corresponding to the first identifier responds to the target request. Compared with the prior art, in the solution provided by the embodiment of the present invention, the client terminal communicates with the cluster through the proxy server. When the client needs to access the cluster, it only needs to send the request to the proxy server, and the proxy server completes the communication with the cluster. The interaction that the client needs to perform is simple and not cumbersome, and the expansion of the cluster has no impact on the client at all.

Description of drawings

In order to explain the embodiments of the present invention or the technical solutions in the prior art more clearly, the following briefly introduces the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings without creative efforts.

1 is a schematic structural diagram of a cluster access system in the prior art;

2 is a schematic structural diagram of a cluster access system according to an embodiment of the present invention;

3 is a schematic flowchart of a client accessing a cluster when the steering information described in the embodiment of the present invention is MOVED information;

4 is a schematic flowchart of a client accessing a cluster when the steering information in the embodiment of the present invention is ASK information;

FIG. 5 is a first schematic flowchart of a cluster access method provided by an embodiment of the present invention;

FIG. 6 is a second schematic flowchart of a cluster access method provided by an embodiment of the present invention;

FIG. 7 is a third schematic flowchart of a cluster access method provided by an embodiment of the present invention;

FIG. 8 is a fourth schematic flowchart of a cluster access method provided by an embodiment of the present invention;

FIG. 9 is a first structural schematic diagram of a cluster access device according to an embodiment of the present invention;

FIG. 10 is a schematic diagram of a second structure of a cluster access device according to an embodiment of the present invention;

FIG. 11 is a third schematic structural diagram of a cluster access device according to an embodiment of the present invention;

FIG. 12 is a schematic diagram of a fourth structure of a cluster access apparatus according to an embodiment of the present invention.

Detailed ways

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

The following briefly introduces the technical terms involved in the embodiments of the present invention.

Cluster: As mentioned earlier, a cluster is a group of independent computers interconnected by a high-speed network that form a group and are managed as a single system. A cluster consists of multiple nodes, including a master node and a slave node. For a cluster without a central master node, each master node in the cluster has the same status in the entire cluster, and each master node can be responsible for processing a part of client requests.

Taking the redis cluster as an example, the client's request command to access the cluster must contain a key value, and the hash value corresponding to the key value can be obtained through the hash algorithm. In addition, the key space of the redis cluster is divided into 16384 The 16384 hash slots here correspond to the hash values of 0 to 16383 respectively. The request corresponding to the master node in the cluster means that the hash value corresponding to the request is the hash value corresponding to the master node. within the value range.

It should be noted that, in order to ensure the high availability of data in the above-mentioned cluster without a central master node, a master-slave mode can be configured in the cluster, that is, one of the above-mentioned master nodes corresponds to at least one slave node, and the master node provides data to the clients of the cluster To access services, the slave node pulls data backup from the master node. When the master node goes down, it will elect a slave node from the slave nodes corresponding to the master node as the new master node, so as to ensure that the cluster does not work. It will hang, that is, to ensure that the entire cluster can still work normally in this case.

It should be emphasized that, in the cluster in this embodiment of the present invention, the number of master nodes is not limited, and may be one, or two or more.

The present invention will be briefly introduced below from the perspective of comparison with the prior art.

FIG. 1 is a schematic structural diagram of a cluster access system in the prior art.

As shown in Figure 1, the client directly communicates with each master node in the cluster, that is, the client can directly access any master node in the cluster, and the cluster includes master node 1, master node 2, ..., master node N. When a client sends a request to the cluster, it first determines the master node corresponding to the request, and then sends the request to the master node.

For example, for a redis cluster, each client can be configured with a routing table. The routing table records the correspondence between each hash value and the identity of the master node. The current cluster includes master nodes a, b, and c. Records in the routing table: Hash values of 0 to 5000 correspond to the identification of master node a, hash values of 5001 to 10000 correspond to the identification of master node b, and hash values of 10001 to 16383 correspond to the identification of master node c. It should be noted that the routing table The corresponding relationship between the hash value recorded in and the identification of the master node actually reflects the corresponding relationship between the above-mentioned hash slot and the master node.

When the client needs to send a request, it first calculates the hash value corresponding to the key value carried in the request through the hash algorithm, and then finds the host corresponding to the hash value from the above routing table. node and then send the request to the master node.

However, if a master node is added to the cluster, and the hash values corresponding to some master nodes change, the corresponding relationship between the hash value and the identifier of the master node in the routing table of the client can be adjusted at this time. Because the number of clients that can access the cluster is usually large and widely distributed, the adjustment of the client has a wide range of influence, which increases the difficulty of expanding the cluster.

As shown in the above example, the cluster includes master nodes a, b and c. The hash values of 0 to 5000 correspond to the ID of master node a, the hash values of 5001 to 10000 correspond to the ID of master node b, and the hash values of 10001 to 16383 correspond to master node c. Now a new master node d is added to the cluster. After adding master node d, the identifiers of the master nodes corresponding to the hash values 0 to 14000 remain unchanged, while the identifiers of the master nodes corresponding to the hash values 14001 to 16383 remain unchanged. Becomes the identity of the primary node d. For this reason, if any client wants to update the corresponding relationship in the local routing table, it needs to restart the client to complete the operation of updating the routing table.

There is a special case here. Before the current redis 3.0 version, the number of master nodes in the redis cluster is one, that is, redis is a single data node, and the client only needs to communicate with the only master node. In order to break through the capacity and performance limitations of a single data node, redis after redis 3.0 expands the cluster horizontally, that is, increases the number of master nodes in the cluster. For this reason, the client's access method can be changed to: according to the feedback of each master node routing information to select the master node corresponding to the request. In actual use, it means that the access logic of each client needs to be changed, that is, the code of the client needs to be changed.

In the solution provided by the embodiment of the present invention, a proxy server is configured in the cluster access system. As shown in FIG. 2 , the target cluster includes a first master node, a second master node, a master node 1, a master node 2, ..., a master node M, the client communicates with each master node in the target cluster through the proxy server, and the routing logic of the proxy server forwarding the client's request includes:

The proxy server first receives the target request sent by the target client for accessing the target cluster; determines the first master node from each master node of the target cluster; sends the target request to the first master node; and then receives the first master node The feedback information fed back by the node; determine whether the feedback information is steering information; if so, parse and obtain the node identification from the feedback information as the first identification; send the target request to the master node corresponding to the first identification, so that The master node corresponding to the first identifier responds to the target request.

It can be understood that, in this embodiment of the present invention, the client directly sends the target request to the proxy server, and when a master node is added to the cluster, it only affects the request forwarding logic of the proxy server, and has no effect on the client.

Taking the above special case as an example, before the current redis 3.0 version, redis is a single data node, the client only needs to communicate with the proxy server, and the proxy server can communicate with the only master node. Increasing the number of master nodes in the cluster At present, the client's access logic is to send the request to the proxy server. After increasing the number of master nodes in the cluster, the client's access logic is still to send the request to the proxy server, and the proxy server forwards the request to the target cluster This request, so the client does not need to make any modifications to realize the smooth migration of the cluster from a single data node to multiple data nodes.

It can be seen from the above that, compared with the prior art, in the solution provided by the embodiment of the present invention, the client is connected to the cluster through the proxy server. When the client needs to access the cluster, it only needs to send the request to the proxy server, and the proxy The server completes the interaction with the cluster, the access operations that the client needs to perform are simple and not cumbersome, and the expansion of the cluster has no impact on the client at all.

The embodiments of the present invention will be described in detail below through specific embodiments.

As shown in FIG. 2 , an embodiment of the present invention provides a cluster access system. The cluster access system includes: a client, a proxy server, and a cluster. The proxy server is connected to the client and each master node in the cluster in communication. The cluster described in the embodiment of the present invention is the above-mentioned cluster without a central master node, such as a redis cluster.

The client is configured to send a target request for accessing the target cluster to the proxy server.

Different from the prior art, in this embodiment of the present invention, the target request sent by the client is directed to the proxy server, rather than directly sent to the master node in the target cluster. In addition, it should be noted that in an actual application, the number of clients corresponding to a cluster is not limited, and may be in the thousands. In this embodiment of the present invention, for the sake of clarity, one client accesses the cluster in a manner to illustrate the entire cluster access system.

the proxy server, configured to receive the target request sent by the client; determine a first master node from each master node of the target cluster; send the target request to the first master node; receive The feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request to the second master node; wherein, the second master node is the master node corresponding to the first identifier.

The first master node is configured to receive the target request sent by the proxy server, generate feedback information for the target request, and send the feedback information to the proxy server.

The second master node is configured to receive the target request sent by the proxy server and respond to the target request.

It should be noted that the proxy server may randomly determine a master node from each master node of the target cluster as the first master node. For example, the current target cluster includes master nodes a, b, c, d and e. After receiving the target request, the proxy server randomly determines the master node a as the first master node.

It can be understood that if the first master node is currently the master node responsible for processing the target request, the feedback information returned by the first master node to the proxy server should be the request success information, and the entire cluster access process ends. Therefore, in the actual application process, it should be ensured as far as possible that the first master node determined by the proxy server is the correct master node responsible for processing the target request.

However, when the proxy server randomly determines the first master node, the probability that the randomly determined master node is the correct master node corresponding to the target request is extremely low. For example, if the target cluster contains 20 master nodes, then the randomly determined master node is the correct master node. The probability of the target request corresponding to the master node is only 5%.

Therefore, specifically, in order to find the master node corresponding to the target request as quickly as possible, in this embodiment of the present invention, a routing table may also be configured in the proxy server, and the routing table records the hash value and the identifier of the master node corresponding relationship. It should be noted that, in this case, the target request contains a target key value, and the proxy server can be specifically used for:

Calculate the target hash value corresponding to the target key value; query whether the target hash value exists in the routing table; if so, determine that the primary node corresponding to the target hash value in the routing table is the first primary node ; if not, randomly determine a master node as the first master node from each master node of the target cluster, wherein the routing table stores the corresponding relationship between the hash value and the identifier of the master node.

It should be noted that the target request sent by the client will contain a key value. In addition, it is well known to those skilled in the art that the calculation formula of the hash value can be:

HASH_SLOT=CRC16(key)mod 16384;

In the formula, HASH_SLOT represents the hash value, CRC16() represents the existing CRC16 algorithm, and the specific algorithm process is not described in detail in this embodiment of the present invention, key represents the target key value, and mod represents the modulo operation. It can be understood that the calculated hash value must be any integer from 0 to 16383, and the hash value of 0 to 16383 corresponds to the hash slot 1 to 16384 respectively.

For example, the target cluster includes master nodes a, b, c, d, e, and f, and the routing table records:

Hash values of 0 to 2730 correspond to the identification of master node a, hash values of 2731 to 5460 correspond to the identification of master node b, hash values of 5461 to 8190 correspond to the identification of master node c, and hash values of 8191 to 10920 correspond to the identification of master node d. ID, the hash values 10921-13650 correspond to the ID of the master node e, and the hash values 13700-16383 correspond to the ID of the master node f.

Assume that the proxy server parses the target key X from the currently received target request, and then calculates the hash value corresponding to the target key X through the above formula, namely:

CRC16(X)mod 16384=5113mod 16384=5113;

Since it is recorded in the routing table that the identifier of the master node corresponding to the hash value 5113 points to master node b, master node b is determined to be the first master node at this time.

Suppose the proxy server parses the target key Y from the target request currently received, and then calculates the hash value corresponding to the target key Y through the above formula, namely:

CRC16(Y)mod 16384=30066mod 16384=13682;

Since the identification of the master node corresponding to the hash value 13682 is not recorded in the routing table, the proxy server can randomly determine a master node from master nodes a, b, c, d, e and f as the first master node. For example, the master node c is randomly determined as the first master node.

Of course, in this embodiment of the present invention, the proxy server can also speed up finding the correct master node corresponding to the target request through other technical means, and is not limited to speeding up finding the correct master node corresponding to the target request by using the routing table configured in the proxy server Correct primary node.

When the first master node determined above is not the master node responsible for processing the target request, the first master node will send redirection information to the proxy server, also known as redirection error information, and the redirection information will contain the target request The corresponding hash value, and the identity of the master node responsible for processing the hash value, for example, the IP (Internet Protocol) address and TCP (Transmission Control Protocol) used by the master node. The port number.

It is well known to those skilled in the art that each master node in a cluster shares the associated information of each master node, and the associated information includes: the IP address and TCP port number used by each master node, and the hash value processed by each master node. groove. Therefore, when a master node x is not the master node responsible for processing the target request, after the master node x receives the target request, it will first calculate the hash value corresponding to the target key value carried in the target request, and then according to The above association information determines the master node responsible for processing the hash value; finally, the master node x will return the redirection information to the proxy server, and the redirection information includes the identification of the master node responsible for processing the hash value and the calculated hash value. value.

Therefore, in the embodiment of the present invention, in the steering information sent by the first master node, the master node corresponding to the identifier included in the steering information is the second master node.

For example, the redirection information fed back by the first master node includes: the identifier 127.0.0.1:8001, the node corresponding to the identifier is the master node x, the proxy server determines the master node x as the second master node, and then the proxy server sends the target request Sent to master node x.

It should be emphasized that the hash slots handled by each master node in the cluster may change. For example, when the number of master nodes in the cluster increases, some of the 16384 hash slots will be reassigned, so The corresponding relationship in the above routing table needs to be updated in time. Therefore, in this embodiment of the present invention, the proxy server may also be used for:

receiving the request success information corresponding to the target request fed back by the third master node; generating a corresponding relationship between the second identifier and the target hash value; updating the generated corresponding relationship into the routing table; wherein, the The third master node is the master node that successfully executes the request command corresponding to the target request, and the second identifier is the identifier of the third master node.

It can be understood that the third master node may be the above-mentioned first master node or the above-mentioned second master node. As long as it receives the target request, the master node that feeds back the request success information for the target request can be determined as: The third master node.

When the proxy server receives the request success information, the proxy server will generate the corresponding relationship between the identifier of the master node that feeds back the request success information, that is, the above-mentioned second identifier, and the target hash value. Obviously, if the generated corresponding relationship already exists in the routing table, the corresponding relationship does not need to be replaced; however, when the generated corresponding relationship does not exist in the routing table, if the target hash value is recorded in the routing table, Then the identifier corresponding to the target hash value in the replacement routing table is the second identifier. If the target hash value is not recorded in the routing table, a target hash value corresponding to the second identifier is added to the routing table. relation.

In this case, the updating of the routing table in the proxy server can be regarded as a self-learning process, and the proxy server automatically updates the routing table according to the successful access information in the actual application process.

For example, if the identifier of the third master node is 127.0.0.1:8002 and the target hash value is 1500, a corresponding relationship between the hash value 1500 and the identifier 127.0.0.1:8002 is generated. If the corresponding relationship between the hash value 1500 and the identifier 127.0.0.1:8002 is recorded in the routing table, the proxy server does nothing to the routing table; but if the identifier corresponding to the hash value 1500 recorded in the routing table is not the identifier 127.0 .0.1:8002, then replace the identifier corresponding to the hash value 1500 in the routing table with the identifier 127.0.0.1:8002; if the routing table records the correspondence about the hash value 1500, then in the routing table Added: The correspondence between the hash value 1500 and the identifier 127.0.0.1:8002.

It should be noted that, in the prior art, since the client and the nodes in the cluster are directly connected in communication, the client can directly send an illegal command request to the master node in the cluster, thereby attacking the cluster and causing damage to the cluster. For example, ordinary users directly send commands to manipulate and configure the cluster and other privileged commands through the client.

In this embodiment of the present invention, in order to exclude the above-mentioned illegal command request, on the basis of any of the above-mentioned embodiments, the proxy server can also be used to:

After receiving the target request sent by the client, determine whether the target request is safe; if so, execute the step of determining the first master node from each master node of the target cluster.

In this embodiment of the present invention, specific methods for judging whether the target request is safe may be various. For example, a firewall may be set to determine whether the target request is safe; more simply, the proxy server may determine whether the received target request is It has the allowed request format. Taking redis cluster as an example, the client sends a request to store data in the redis cluster. The format corresponding to such a request can be "set...", if the format of the currently received request is " assert...", it can be determined that the target request is not safe.

It can be understood that the proxy server is configured with a security detection mechanism, that is, after receiving the target request sent by the client, it will only send the target request to the cluster after the security of the target request is determined, which ensures the security of the cluster. Moreover, only the security detection mechanism needs to be configured in the proxy server, and the security detection mechanism occupies less resources.

It should be noted that, the steering information may include MOVED information and ASK information. Different types of steering information have different access logic to the proxy server. On the basis of any of the above embodiments, the proxy server can be specifically used for :

Determine the type of the steering information; if the steering information is MOVED information, directly send the target request to the second master node; if the steering information is ASK information, send an ASKING command to the second master node, and then send the ASKING command to the second master node. The target request is sent to the second master node.

It should be noted that the method used to determine the type of steering information belongs to the prior art, so the proxy server can determine the type of steering information through the prior art; in addition, MOVED information and ASK information are concepts in the prior art, and the two For the differences, reference may be made to the prior art, and the embodiments of the present invention will not be described in detail here. It is well known to those skilled in the art that, before sending ASK information to the master node, an ASKING command should be sent to the master node first.

FIG. 3 is a schematic flowchart of a client accessing a cluster when the steering information is MOVED information in an embodiment of the present invention.

In Figure 3, "set a2 1" is the request sent by the client 301, "-moved 127.0.0.1:7002" represents a MOVED message, and the MOVED message carries the identifier of the master node corresponding to the request, that is, "-moved 127.0.0.1:7002" 127.0.0.1:7002". The words "127.0.0.1:7000", "127.0.0.1:7001", "127.0.0.1:7002", "127.0.0.1:7003", "127.0.0.1:7004" and "127.0" on the right side of the main node in the figure .0.1:7005" respectively represent the identifiers of the corresponding master nodes 303

As shown in Figure 3, the client 301 first sends the request "set a2 1" to the proxy server 302, and then the proxy server determines the master node identified as "127.0.0.1:7001" as the first master node, and sends the request to the proxy server 302. "set a2 1" is sent to the first master node. Then the first master node calculates the hash value corresponding to the key value "a2", and finds that the hash slot corresponding to the hash value is processed by the master node identified as "127.0.0.1:7002", and then the first master node The node sends the MOVED message to the proxy server.

After receiving the steering information, the proxy server determines that the steering information is MOVED information, parses and obtains the identifier of the master node carried in the MOVED information, determines that the master node with the identifier "127.0.0.1:7002" is the second master node, and then The request "set a2 1" is sent to the second master node. After receiving the request, the second master node executes the request, stores "a2" as "1" according to the request command corresponding to the request, and returns the request success information "OK" to the proxy server. Finally, after receiving the request success information "OK", the proxy server sends the request success information to the client.

FIG. 4 is a schematic flowchart of a client accessing a cluster when the steering information is ASK information in an embodiment of the present invention.

In Figure 4, "set a2 1" is the request sent by the client 301, and "-ask 127.0.0.1:7002" represents an ASK message, which carries the identifier of the master node corresponding to the request, that is, "-ask 127.0.0.1:7002" 127.0.0.1:7002". In addition, the words "127.0.0.1:7000", "127.0.0.1:7001", "127.0.0.1:7002", "127.0.0.1:7003", "127.0.0.1:7004" and "127.0.0.1:7005" respectively represents the identifier of each corresponding master node 303 .

As shown in FIG. 4 , the client 301 first sends the request “set a2 1” to the proxy server 302, and then the proxy server 302 determines the master node 303 identified as “127.0.0.1:7000” as the first master node, and The request "set a21" is sent to the first master node. Then the first master node calculates the hash value corresponding to the key value "a2", and finds that the hash slot corresponding to the hash value is processed by the master node identified as "127.0.0.1:7002", and then the first master node The node sends ASK information to the proxy server.

After the proxy server receives the redirection information, it determines that the redirection information is ASK information, parses and obtains the master node identifier carried in the ASK information, and determines that the master node with the identifier "127.0.0.1:7002" is the second master node, and the proxy server First send an ASKING command "asking" to the second master node, and then the proxy server sends a request "set a2 1" to the second master node. After receiving the request, the second master node executes the request, stores "a2" as "1" according to the request command corresponding to the request, and returns the request success information "OK" to the proxy server. Finally, after receiving the request success information "OK", the proxy server sends the request success information to the client.

It can be seen from the above that in the solution provided by this embodiment, the proxy server first receives the target request sent by the target client for accessing the target cluster; determines the first master node from each master node of the target cluster; sends the target request to the target cluster. the first master node; then receive the feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request The master node corresponding to the first identifier is given, so that the master node corresponding to the first identifier responds to the target request. Compared with the prior art, in the solution provided by this embodiment, the client communicates with the cluster through the proxy server. When the client needs to access the cluster, it only needs to send the request to the proxy server, and the proxy server completes the communication with the cluster. Interaction, the access operations that the client needs to perform are simple and not cumbersome, and the expansion of the cluster has no impact on the client at all.

In addition, it should be noted that after adding a proxy server to the cluster access system, it is found through experiments that the addition of the proxy server does not affect the performance of the entire cluster access system.

It can be understood that the names of the first master node and the second master node determined by the proxy server in the foregoing embodiments are only given names for the convenience of explaining specific operations. In practical applications, according to the actual target request, any one of the cluster The master node may be determined as the first master node, and may also be determined as the second master node.

Similarly, the first identifier and the second identifier in the foregoing embodiments are given names for the convenience of describing specific operations, and only represent two different identifiers. In practical applications, for different requests, the same identifier may be either the first identifier or the above-mentioned second identifier.

In other embodiments of the present application, there are also limitations with names similar to those described above for the convenience of describing specific operations, which are all for convenience of expression and do not substantially limit what functions a certain device or network only has. Not listed here.

The embodiments of the present invention are briefly introduced below through a specific example.

Taking the redis cluster as an example, the client communicates with each master node in the redis cluster through a proxy server, and the proxy server is configured with a routing table, and the routing table stores the corresponding relationship between the hash value and the identity of the master node.

A client sends a request X to the proxy server, and the request X carries the key value y. After the proxy server receives the request X, it parses the key value y, and then calculates the corresponding key value y through the hash algorithm. the hash value z. Then the proxy server queries the routing table and finds that the identifier of the master node corresponding to the hash value z is the identifier m, and the proxy server sends the request X to the master node corresponding to the identifier m.

If the master node corresponding to the identifier m returns the request success information, the cluster access is completed. Of course, the proxy server will also send the received request success information to the client.

Corresponding to the above system embodiment, the embodiment of the present invention further provides a cluster access method, which is applied to a proxy server. As shown in FIG. 5 , the method includes:

S101: Receive a target request sent by a target client for accessing a target cluster;

S102: Determine a first master node from each master node of the target cluster;

S103: Send the target request to the first master node;

S104: Receive feedback information fed back by the first master node;

S105: Determine whether the feedback information is steering information;

In the case that the feedback information is steering information, step S106 is executed: the node identifier is obtained by parsing the feedback information as the first identifier; and the target request is sent to the second master node, so that the second master node responds to the A target request; wherein, the second master node is the master node corresponding to the first identifier.

In this embodiment of the present invention, the target request includes a target key value, which corresponds to the above-mentioned system embodiment, and is based on the method embodiment shown in FIG. 5 , as shown in FIG. The step of determining the first master node (S102) in step 1 may include:

S1021: Calculate the target hash value corresponding to the target key value,

S1022: Query whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identifier of the master node;

In the case that the query result of step S1022 is yes, step S1023 is executed: determine that the master node corresponding to the target hash value in the routing table is the first master node;

If the query result in step S1022 is no, step S1024 is executed: randomly determine one master node as the first master node from each master node of the target cluster.

Corresponding to the foregoing system embodiment and based on the method embodiment shown in FIG. 6 , as shown in FIG. 7 , the foregoing method may further include:

S107: Receive the request success information corresponding to the target request fed back by the third master node; wherein, the third master node is the master node that successfully executes the request command corresponding to the target request;

S108: Generate a correspondence between a second identifier and the target hash value, where the second identifier is the identifier of the third master node;

S109: Update the generated corresponding relationship to the above routing table.

Corresponding to the above system embodiment, on the basis of any one of the method embodiments shown in FIGS. 5 to 7 , as shown in FIG. 8 , the above step of receiving a target request sent by a target client for accessing a target cluster ( S101 ) After that, the method can also include:

S1010: Determine whether the target request is safe;

If yes, execute the above step of determining the first master node (S102) from each master node of the target cluster.

Corresponding to the foregoing system embodiment, on the basis of any of the method embodiments shown in FIGS. 5 to 7 , the foregoing step of sending the target request to the second master node includes:

determine the type of steering information described above;

If the steering information is MOVED information, directly send the target request to the second master node;

If the steering information is ASK information, send an ASKING command to the second master node, and then send the target request to the second master node.

It can be seen from the above that in the solution provided by this embodiment, the proxy server first receives the target request sent by the target client for accessing the target cluster; determines the first master node from each master node of the target cluster; sends the target request to the target cluster. the first master node; then receive the feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request The master node corresponding to the first identifier is given, so that the master node corresponding to the first identifier responds to the target request. Compared with the prior art, in the solution provided by this embodiment, the client communicates with the cluster through the proxy server. When the client needs to access the cluster, it only needs to send the request to the proxy server, and the proxy server completes the communication with the cluster. Interaction, the access operations that the client needs to perform are simple and not cumbersome, and the expansion of the cluster has no impact on the client at all.

Corresponding to the method embodiment shown in FIG. 5 , a cluster access apparatus provided by an embodiment of the present invention is applied to a proxy server. As shown in FIG. 9 , the apparatus includes:

The first receiving module 110 is configured to receive the target request sent by the target client for accessing the target cluster;

a determining module 120, configured to determine a first master node from each master node of the target cluster;

a first sending module 130, configured to send the target request to the first master node;

A second receiving module 140, configured to receive feedback information fed back by the first master node;

The first judgment module 150 is used for judging whether the feedback information is steering information;

The second sending module 160 is configured to analyze and obtain the node identifier from the feedback information when the determination result of the first determination module 150 is yes, as the first identifier; and send the target request to the second a master node, so that the second master node responds to the target request; wherein the second master node is the master node corresponding to the first identifier.

In this embodiment of the present invention, the target request includes a target key value. Corresponding to the method embodiment shown in FIG. 6 , on the basis of the apparatus embodiment shown in FIG. 9 , as shown in FIG. 10 , the determining module 120 , which can include:

The calculation submodule 1201 is used to calculate the target hash value corresponding to the target key value,

Inquiry submodule 1202, configured to inquire whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identification of the master node;

A first determination submodule 1203, configured to determine the primary node corresponding to the target hash value in the routing table as the first primary node when the target hash value exists in the routing table;

The second determining submodule 1204 is configured to randomly determine a master node as the first master node from each master node of the target cluster in the case that the target hash value does not exist in the routing table.

Corresponding to the method embodiment shown in FIG. 7 , on the basis of the apparatus embodiment shown in FIG. 10 , as shown in FIG. 11 , the apparatus may further include:

The third receiving module 170 is configured to receive the request success information corresponding to the target request fed back by a third master node; wherein, the third master node is the master node that successfully executes the request command corresponding to the target request;

A generating module 180, configured to generate a correspondence between a second identifier and the target hash value, wherein the second identifier is the identifier of the third master node;

The updating module 190 is configured to update the generated corresponding relationship into the routing table.

Corresponding to the method embodiment shown in FIG. 8 , on the basis of any of the apparatus embodiments shown in FIGS. 9 to 11 , specifically, as shown in FIG. 12 , the apparatus may further include:

The second judging module 1100 is configured to judge whether the target request is safe after receiving the target request sent by the target client for accessing the target cluster; if so, trigger the determining module 120 .

Corresponding to the method embodiment, on the basis of any of the apparatus embodiments shown in FIGS. 9 to 11 , specifically, the second sending module 160 may be specifically used for:

In the case that the judgment result of the first judgment module 150 is yes, the node identification is obtained by parsing from the feedback information as the first identification; the type of the steering information is determined; if the steering information is MOVED information, The target request is directly sent to the second master node; if the steering information is ASK information, an ASKING command is sent to the second master node, and then the target request is sent to the second master node.

It can be seen from the above that in the solution provided by this embodiment, the proxy server first receives the target request sent by the target client for accessing the target cluster; determines the first master node from each master node of the target cluster; sends the target request to the target cluster. the first master node; then receive the feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request The master node corresponding to the first identifier is given, so that the master node corresponding to the first identifier responds to the target request. Compared with the prior art, in the solution provided by this embodiment, the client communicates with the cluster through the proxy server. When the client needs to access the cluster, it only needs to send the request to the proxy server, and the proxy server completes the communication with the cluster. Interaction, the access operations that the client needs to perform are simple and not cumbersome, and the expansion of the cluster has no impact on the client at all.

As for the method and device embodiments, since they are basically similar to the system embodiments corresponding to the cluster access system, the description is relatively simple, and for related parts, please refer to some descriptions of the system embodiments.

It should be noted that, in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any relationship between these entities or operations. any such actual relationship or sequence exists. Moreover, the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device that includes a list of elements includes not only those elements, but also includes not explicitly listed or other elements inherent to such a process, method, article or apparatus. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in a process, method, article or apparatus that includes the element.

Each embodiment in this specification is described in a related manner, and the same and similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and for related parts, please refer to the partial descriptions of the method embodiments.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims (15)

1. A cluster access system, characterized in that the cluster access system comprises: a client, a proxy server and a cluster, the proxy server is communicatively connected with each master node in the client and the cluster, and the cluster is a centerless a cluster of master nodes, the client, configured to send a target request for accessing the target cluster to the proxy server; the proxy server, configured to receive the target request sent by the client; determine a first master node from each master node of the target cluster; send the target request to the first master node; receive The feedback information fed back by the first master node; determine whether the feedback information is steering information; if so, parse and obtain the node identifier from the feedback information as the first identifier; send the target request to the second master node; wherein, the second master node is the master node corresponding to the first identifier; the first master node, configured to receive the target request sent by the proxy server, and generate feedback information for the target request; send the feedback information to the proxy server; The second master node is configured to receive the target request sent by the proxy server and respond to the target request. 2. The system according to claim 1, wherein the target request includes a target key value, The proxy server is specifically used for: Calculate the target hash value corresponding to the target key value; query whether the target hash value exists in the routing table; if so, determine that the primary node corresponding to the target hash value in the routing table is the first primary node ; if not, randomly determine a master node as the first master node from each master node of the target cluster, wherein the routing table stores the corresponding relationship between the hash value and the identifier of the master node. 3. The system according to claim 2, wherein the proxy server is further used for: receiving the request success information corresponding to the target request fed back by the third master node; generating a corresponding relationship between the second identifier and the target hash value; updating the generated corresponding relationship into the routing table; wherein, the The third master node is the master node that successfully executes the request command corresponding to the target request, and the second identifier is the identifier of the third master node. 4. The system according to any one of claims 1-3, wherein the proxy server is further configured to: After receiving the target request sent by the client, determine whether the target request is safe; If yes, execute the step of determining the first master node from each master node of the target cluster. 5. The system according to any one of claims 1-3, wherein the proxy server is specifically used for: Determine the type of the steering information; if the steering information is MOVED information, directly send the target request to the second master node; if the steering information is ASK information, send an ASKING command to the second master node, and then send the ASKING command to the second master node. The target request is sent to the second master node. 6. A cluster access method, characterized in that, applied to a proxy server, the method comprising: Receive the target request sent by the target client to access the target cluster; determining a first master node from each master node of the target cluster; sending the target request to the first master node; receiving feedback information fed back by the first master node; Determine whether the feedback information is steering information; If yes, parse and obtain the node identifier from the feedback information as the first identifier; send the target request to the second master node, so that the second master node responds to the target request; wherein the first The second master node is the master node corresponding to the first identifier. 7. The method according to claim 6, wherein the target request includes a target key value, The step of determining the first master node from each master node of the target cluster includes: Calculate the target hash value corresponding to the target key value, query whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identity of the master node; If yes, determine that the master node corresponding to the target hash value in the routing table is the first master node; If not, randomly determine one master node as the first master node from among the master nodes of the target cluster. 8. The method according to claim 7, wherein the method further comprises: Receive the request success information corresponding to the target request fed back by the third master node; wherein, the third master node is the master node that successfully executes the request command corresponding to the target request; generating a correspondence between a second identifier and the target hash value, wherein the second identifier is the identifier of the third master node; The generated corresponding relationship is updated into the routing table. 9. The method according to any one of claims 6-8, wherein after the step of receiving the target request sent by the target client for accessing the target cluster, the method further comprises: Determine whether the target request is safe; If yes, execute the step of determining the first master node from each master node of the target cluster. 10. The method according to any one of claims 6-8, wherein the step of sending the target request to the second master node comprises: determining the type of steering information; If the steering information is MOVED information, directly send the target request to the second master node; If the steering information is ASK information, send an ASKING command to the second master node, and then send the target request to the second master node. 11. A cluster access device, characterized in that, applied to a proxy server, the device comprising: a first receiving module, configured to receive a target request sent by the target client for accessing the target cluster; a determining module, configured to determine the first master node from each master node of the target cluster; a first sending module, configured to send the target request to the first master node; a second receiving module, configured to receive feedback information fed back by the first master node; a first judging module for judging whether the feedback information is steering information; A second sending module, configured to parse and obtain a node identifier from the feedback information when the determination result of the first determination module is yes, as the first identifier; and send the target request to the second master node , so that the second master node responds to the target request; wherein, the second master node is the master node corresponding to the first identifier. 12. The apparatus according to claim 11, wherein the target request includes a target key value, The determining module includes: a calculation sub-module for calculating the target hash value corresponding to the target key value, a query sub-module for querying whether the target hash value exists in the routing table, wherein the routing table stores the corresponding relationship between the hash value and the identity of the master node; a first determination submodule, configured to determine the master node corresponding to the target hash value in the routing table as the first master node when the target hash value exists in the routing table; The second determination submodule is configured to randomly determine a master node as the first master node from each master node of the target cluster when the target hash value does not exist in the routing table. 13. The apparatus of claim 12, wherein the apparatus further comprises: a third receiving module, configured to receive the request success information corresponding to the target request fed back by a third master node; wherein, the third master node is a master node that successfully executes the request command corresponding to the target request; a generating module, configured to generate a correspondence between a second identifier and the target hash value, wherein the second identifier is the identifier of the third master node; An update module, configured to update the generated corresponding relationship into the routing table. 14. The device according to any one of claims 11-13, wherein the device further comprises: The second judging module is configured to judge whether the target request is safe after receiving the target request sent by the target client for accessing the target cluster; if so, trigger the determining module. 15. The apparatus according to any one of claims 11-13, wherein the second sending module is specifically configured to: In the case that the judgment result of the first judgment module is yes, analyze and obtain the node identification from the feedback information as the first identification; determine the type of the steering information; if the steering information is MOVED information, directly Send the target request to the second master node; if the steering information is ASK information, send an ASKING command to the second master node, and then send the target request to the second master node.

Images