WO2020253596A1

WO2020253596A1 - High availability method and apparatus for redis cluster

Info

Publication number: WO2020253596A1
Application number: PCT/CN2020/095421
Authority: WO
Inventors: 杨永帮
Original assignee: 深圳前海微众银行股份有限公司
Priority date: 2019-06-21
Filing date: 2020-06-10
Publication date: 2020-12-24
Also published as: CN110224871B; CN110224871A

Abstract

The embodiments of the present invention relate to the field of Fintech. Disclosed are a high availability method and apparatus for a Redis cluster, the cluster comprising at least two Redis servers and monitoring assemblies correspondingly configured for the Redis servers. The method comprises: a monitoring assembly of a first Redis server detecting a connection link of each Redis server by initiating a detection thread; if the monitoring assembly of the first Redis server determines that a connection link of a second Redis server has a fault, initiating a vote; and the monitoring assembly of the first Redis server determining a slave Redis server with a voting result greater than or equal to half as a slave Redis server for switching with the second Redis server. In the present invention, the VIP drift of a fault of a Redis server is realized, and the cost is reduced.

Description

High-availability method and device for Redis cluster

Cross references to related applications

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on June 21, 2019, the application number is 201910540450.2, and the application name is "a high-availability method and device for Redis clusters", the entire content of which is incorporated by reference In this application.

Technical field

The present invention relates to the field of communication technology of financial technology (Fintech), and in particular to a high-availability method and device of a Redis cluster.

Background technique

With the development of computer technology, more and more technologies are applied in the financial field. The traditional financial industry is gradually transforming into Fintech. Redis cluster technology is no exception. However, due to the security and real-time requirements of the financial industry, There are also higher requirements for technology.

At present, in order to solve the performance problems caused by high concurrency, web application systems will adopt a caching layer between the web application system and the database. The most widely used is Redis (Redis is essentially a key-value memory database). As a buffer layer between software and traditional databases, Redis has simple operation commands. While ensuring the validity of data, it also guarantees high performance.

In the prior art, in order to achieve the high availability of Redis and reduce the service interruption time of the server, by protecting the service provided by the user's business program continuously, the impact of the software/hardware/man-made failure on the business is reduced to At a minimum, components need to be migrated for fault migration, multiple monitoring components are needed for server monitoring, too many components are required, and maintenance costs are high.

Summary of the invention

The embodiment of the present invention provides a high-availability method and device for a Redis cluster to solve the problem of too many components accessing the Redis database in the prior art and high maintenance cost.

The embodiment of the present invention provides a high-availability method for a Redis cluster. The cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the method includes:

The monitoring component of the first Redis server detects the connection link of each Redis server by initiating a detection thread;

If the monitoring component of the first Redis server determines that the connection link of the second Redis server is faulty, it initiates a vote; the second Redis server is the master Redis server;

If the monitoring component of the first Redis server determines that the slave Redis server whose voting result is greater than or equal to half is the first Redis server, the first Redis server is determined to be the slave that switches with the second Redis server Redis server;

The monitoring component of the first Redis server sets the VIP address of the first Redis server to the VIP address of the Redis cluster, so that clients that access the Redis cluster can access the first Redis cluster according to the modified VIP address. Redis server.

In a possible implementation manner, the monitoring component of the first Redis server setting the VIP address of the first Redis server to the VIP address of the Redis cluster includes:

Acquiring, by the monitoring component of the first Redis server, the parameters transmitted by the monitoring component of the second Redis server during failover;

If the monitoring component of the first Redis server determines that the source IP address in the parameter is the IP address of the second Redis server, it initiates an unbinding operation of the VIP address;

If the monitoring component of the first Redis server determines that the destination IP address in the parameter is the IP address of the first Redis server, it detects whether the VIP address of the Redis cluster is in a connected state;

If the monitoring component of the first Redis server does not receive the connection return message, it binds the VIP address of the first Redis server to the Redis cluster.

In a possible implementation manner, if the monitoring component of the first Redis server does not receive the connection return message, the method further includes:

The VIP address of the first Redis server is updated to the ARP cache, so that the gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.

In a possible implementation manner, the monitoring component of the first Redis server detects the connection link of each Redis server by initiating a detection thread, including:

The monitoring component of the first Redis server sends a heartbeat detection to each Redis server;

If the heartbeat detection is successful, the available connection link is determined from the Redis instance that succeeded in the heartbeat detection.

An embodiment of the present invention provides a high-availability device for a Redis cluster. The cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the device includes:

The monitoring unit is used to detect the connection link of each Redis server by initiating a detection thread;

The processing unit is configured to initiate a voting if it is determined that the connection link of the second Redis server is faulty; the second Redis server is the primary Redis server; if it is determined that the secondary Redis server whose voting result is greater than or equal to half is the first Redis Server, the first Redis server is determined to be the slave Redis server that switches with the second Redis server; the VIP address of the first Redis server is set to the VIP address of the Redis cluster, so that the The client of the Redis cluster accesses the first Redis server according to the modified VIP address.

In a possible implementation manner, the processing unit is specifically configured to:

Obtain the parameters transmitted by the monitoring component of the second Redis server during failover; if it is determined that the source IP address in the parameters is the IP address of the second Redis server, initiate the unbinding operation of the VIP address; if It is determined that the destination IP address in the parameter is the IP address of the first Redis server, then it is detected whether the VIP address of the Redis cluster is in a connected state; if the connection return message is not received, the first Redis server The VIP address of is bound to the Redis cluster.

In a possible implementation manner, the processing unit is further configured to: update the VIP address of the first Redis server to the ARP cache, so that the gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the The first Redis server is described.

In a possible implementation manner, the monitoring unit is specifically used for:

Send a heartbeat detection to each Redis server; if the heartbeat detection is successful, the available connection link is determined from the Redis instance with a successful heartbeat detection.

In the embodiment of the present invention, the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the number of monitoring components in the prior art is reduced; the monitoring component of the first Redis server is initiated by The detection thread detects the connection link of each Redis server; if the monitoring component of the first Redis server determines that the connection link of the second Redis server is faulty, it initiates a vote; the second Redis server is the main Redis server; The monitoring component of the first Redis server determines that the secondary Redis server whose voting result is greater than or equal to half is the secondary Redis server that switches with the second Redis server; the monitoring component of the first Redis server determines the first Redis The VIP address of the server is set to the VIP address of the Redis cluster, so that the client accessing the Redis cluster accesses the first Redis server according to the modified VIP address. While reducing the monitoring components, it realizes the VIP drift of the Redis server failure without adding additional monitoring components. Moreover, because the setting of the VIP address is completed by the monitoring component, it does not require other components in the prior art to complete, It further reduces the set of components and reduces the cost of maintenance.

Description of the drawings

In order to more clearly describe the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings needed in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative work, other drawings can be obtained from these drawings.

Figure 1a is a Redis cluster architecture provided by an embodiment of the present invention;

Figure 1b shows a Redis cluster architecture provided by an embodiment of the present invention;

2 is a schematic diagram of the architecture of a Redis cluster provided by an embodiment of the present invention;

FIG. 3 is a schematic flowchart of a high-availability method for a Redis cluster provided by an embodiment of the present invention;

4 is a schematic structural diagram of a high-availability device for Redis cluster provided by an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a Redis monitoring component provided by an embodiment of the present invention.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, 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 work shall fall within the protection scope of the present invention.

High-availability cluster: refers to server cluster technology for the purpose of reducing service interruption time. It minimizes the impact of software, hardware, or human-caused failures on the business by protecting the user's business program to provide uninterrupted services to the outside world.

Redis server: an open source, network-supported, memory-based, optional persistence key-value storage database written in ANSI C, and is usually used as a cache database.

Monitoring component sentinel: monitor the available status of the Redis server. When using Redis as a high-availability solution for the main Redis server and the secondary Redis server, if the main Redis server goes down, Redis itself (including many of its clients) does not realize automatic active/standby switching. Through the monitoring component sentinel component, you can Monitor whether Redis is running as expected; if a Redis node is found to be malfunctioning, it can notify another process (such as its client) to automatically switch.

The Redis-monitoring component sentinel itself is also an independently running process. It can monitor multiple master Redis servers-slave Redis server clusters, and automatically switch after the master Redis server is down. It is unreliable to use only a single monitoring component sentinel process to monitor the Redis cluster. When the monitoring component sentinel process runs incorrectly, or the network is blocked, the active and standby redis cluster cannot be switched (the monitoring component sentinel itself also has a single point of problem, single -point-of-failure) The entire cluster system will not operate as expected. Therefore, it is necessary to cluster the monitoring component sentinel, that is, multiple monitoring components sentinel need to be set up.

When a master Redis server node is unavailable, the monitoring component can elect at least one of the slave Redis servers of the master Redis server as the new master Redis server. Other slave Redis server nodes will change the address of the master Redis server that it follows to: the new address of the slave Redis server promoted to the master Redis server. If most of the monitoring components sentinels can communicate with each other, there will eventually be one authorized to perform fault migration, ensuring the liveness of Redis.

Keepalived: A component for health check in a load balancing cluster and a component for maintaining failover between the active and standby machines.

HAProxy: is a free and open source software written in C language that provides high availability, load balancing, and application proxy based on TCP and HTTP.

Vip: The ip address for external access in the cluster, usually only one.

In practical applications, Redis deployment has multiple structures. In the embodiment of the present invention, examples of deployment methods are provided. As shown in Figure 1a, one deployment method is to deploy VIP nodes. The VIP nodes manage multiple nodes, each The node manages an instance group, and the VIP node implements the function of data fragmentation, that is, the read and write requests sent by the application are allocated to the corresponding instance group of the corresponding node for processing by the VIP node.

In case of failure migration, for the master-slave switch of the Redis server, you can switch from the Redis server to the master Redis server through Keepalived. Keepalived can be set in each Redis server. If the monitoring component sentinel determines that the current main Redis server is running faulty, it is determined that fault migration is required. You can use Keepalived to migrate the process on the failed main Redis server to the monitoring component sentinel. The new main Redis server.

For the switch of VIP nodes, the HAProxy component can be set in each Redis server, and the master-slave switch of the Redis server can be detected instantly through the HAProxy component. If it is determined that the master-slave switch of the Redis server is completed, the new master Redis server is activated Set the VIP address as the VIP address of the current Redis cluster. The specific setting can be implemented through the Virtual Router Redundancy Protocol (VRRP) to switch the VIP address.

For the switching of VIP addresses, VRRP can virtualize the physical router device of the first Redis server and the physical router device of the second Redis server into a virtual router. This virtual router provides services to the outside through a virtual IP (VIP), while inside the virtual router It can include multiple physical routers working together. Only one physical router provides external services at the same time, that is, the main router. For example, if the current main Redis server is the first Redis server, at this time, only the physical of the first Redis server The router provides external servers. Among them, the main router is generated by an election algorithm. It has a virtual IP for external services and provides various network functions, such as: ARP request, ICMP (Internet Control Message Protocol, Internet Control Message Protocol) data forwarding, etc., and other physical routers do not It has an external virtual IP and does not provide external network functions. It only receives VRRP status notification information from the main routers, which are backup routers. When the main router fails, the backup router will re-elect and generate a new main router to enter the main router and continue to provide external services. The entire switchover is completely transparent to the client.

In the case of a master Redis server and one or more slave Redis servers, each master Redis server and slave Redis server is configured with a monitoring component sentinel component; in addition, due to the need to elect multiple slave Redis servers of the master Redis server One of them will be used as the new master Redis server. If the total number of the master Redis server and the slave Redis server is an even number, in order to ensure the smooth progress of the election, an additional monitoring component sentinel of the Redis server needs to be set up. The problem is in a large cluster It's not obvious, but in small clusters, additional components increase maintenance costs.

As shown in Figure 1b, the embodiment of the present invention provides another deployment method. There are several instance groups in a Redis cluster, and the application is directly connected to multiple instance groups, that is, the application is connected to multiple sets of master-slave servers, each Several instances responsible for data backup are running in the main server.

Under this scheme, for a non-VIP-based cluster deployment scheme, when switching occurs, the switch of the main Redis server needs to notify the client through the monitoring component sentinel, and the client needs to reconnect to the switched main Redis server. In the specific implementation process, the client needs to monitor the event queue of the monitoring component sentinel, obtain the ip port of the main Redis server after the switch, and initiate access to the ip port of the main Redis server after the switch, compared to the deployment scenario with VIP nodes , Is not conducive to the timeliness of handover.

For the same reason, since it is necessary to elect a slave Redis server from multiple slave Redis servers as the new master Redis server, if the total number of the master Redis server and the slave Redis server is an even number, in order to ensure the smooth progress of the election, Under the premise of a master Redis server and a slave Redis server, an additional monitoring component sentinel is required. In a small cluster, the additional components will increase the cost of maintenance.

Based on the above problems, referring to Figure 2, the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; as shown in Figure 3, the embodiment of the present invention provides a high availability of a Redis cluster Schematic diagram of the method flow, the specific implementation methods include:

Step 301: The monitoring component sentinel of the first Redis server detects the connection link of each Redis server by initiating a detection thread;

Specifically, a separate thread can be started to periodically send detection messages to each Redis instance, and its health status can be judged based on its response. In addition, the feedback interface is also opened to external callers. When the caller encounters an exception while reading and writing Redis, the feedback interface can be called to update the health status of the Redis instance in time.

Step 302: If the monitoring component of the first Redis server determines that the connection link of the second Redis server is faulty, it initiates a vote; the second Redis server is the master Redis server;

Specifically, after the monitoring component sentinel detects that the main Redis server cannot be connected at a specific time, it confirms that the second Redis server is faulty and needs to trigger a failover.

Step 303: If the monitoring component of the first Redis server determines that the secondary Redis server whose voting result is greater than or equal to half is the first Redis server, then the first Redis server is determined to be the one to switch to the second Redis server From the Redis server;

In the specific implementation process, all the monitoring components sentinels that monitor the main Redis server participate in the voting and elect a switch from the Redis server to the main Redis server. In an architecture scenario where there is only one slave Redis server, there is no need for more monitoring components sentinel to participate in the voting, only half of the voting is enough, so that the success of the switch can be guaranteed when the main Redis server is down, and also Save the resources of the monitoring component sentinel. Correspondingly, the voting method in the embodiment of the present invention is greater than or equal to half, and the specific code may be as follows:

Monitoring component sentinel.c:voters_quorum=voters/2;

In this way, only half of the monitoring components sentinel in the cluster can trigger the failover.

Step 304: The monitoring component of the first Redis server sets the VIP address of the first Redis server to the VIP address of the Redis cluster, so that the clients that access the Redis cluster can access the first Redis cluster according to the modified VIP address. A Redis server.

In the embodiment of the present invention, the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the number of monitoring components in the prior art is reduced; the monitoring component of the first Redis server is initiated by The detection thread detects the connection link of each Redis server; if the monitoring component of the first Redis server determines that the connection link of the second Redis server is faulty, it initiates a vote; the second Redis server is the main Redis server; The monitoring component of the first Redis server determines that the secondary Redis server whose voting result is greater than or equal to half is the secondary Redis server that switches with the second Redis server; the monitoring component of the first Redis server determines the first Redis The VIP address of the server is set to the VIP address of the Redis cluster, so that the client accessing the Redis cluster accesses the first Redis server according to the modified VIP address.

The redis server switch in the Redis cluster is realized through the voting mechanism. On the basis of reducing the monitoring components, the VIP drift of the failure of the Redis server is realized, no additional monitoring components are required, and because the setting of the VIP address is completed through the monitoring component Yes, it does not require other components in the prior art to complete, thereby further reducing component settings and reducing maintenance costs. When the Redis clusters of banks and other financial institutions switch Redis servers, the cost is lower and the maintenance cost is also reduced, which has more obvious economic benefits.

In step 304, a possible implementation manner includes:

Step 1: The monitoring component of the first Redis server obtains the parameters transmitted by the monitoring component of the second Redis server during failover;

Step 2: If the monitoring component of the first Redis server determines that the source IP address in the parameter is the IP address of the second Redis server, it initiates an unbinding operation of the VIP address;

Step 3: If the monitoring component of the first Redis server determines that the destination IP address in the parameter is the IP address of the first Redis server, it detects whether the VIP address of the Redis cluster is in a connected state;

Step 4: If the monitoring component of the first Redis server does not receive the connection return message, it binds the VIP address of the first Redis server to the Redis cluster.

In the specific implementation process, a script is triggered when the main Redis server of the Redis cluster fails over. The script can be written in shell language.

Specifically, the script is used to determine the parameters transmitted by the monitoring component from the monitoring component of the second Redis server during failover. For example, if the IP address in the parameter from-ip is the local ip, the address that can be bound by the VIP is still the second Redis server. Therefore, the VIP unbinding operation can be performed through the ip command of the operating system. For example, "/bin/ip addr del{VIP}/24 dev eth0". For example, if the IP address in the parameter to-ip is the local ip, it can be determined that the address of the VIP is the main Redis server after the switch. Therefore, a ping message needs to be sent to the VIP; if it is determined that the corresponding PONG message can be received, you can After confirming that the link is normal, wait for the relevant time to start the VIP after the handover. If the PONG message corresponding to the sent ping cannot be received, it means that the current VIP is unbound, and the first Redis server after the switch is not bound, and the VIP needs to be bound to the first Redis server. The above implementation can be achieved by the following code: "/bin/ip addr add{VIP}/24 dev eth0".

In a scenario with ARP (Address Resolution Protocol, namely ARP), a possible implementation manner, if the monitoring component of the first Redis server does not receive the connection return message, further includes:

Specifically, the arp cache of the VIP in the local area network can be updated. The above implementation can be achieved by the following code: /usr/sbin/arping-I eth0-A{VIP}-c 3.

Therefore, the new VIP can be bound to the first Redis server, and the arp cache is updated, so that the gateway confirms that the mac address corresponding to the ip is on the first Redis server, so that the client can pass through the VIP in the event of a failure Access the first Redis server, thus realizing a highly available cluster that can drift through VIP.

The embodiment of the present invention provides a more efficient Redis cluster high-availability method. Compared with other clusters, the maintenance components are reduced and the cost of learning other components is eliminated; and the use of monitoring components is effectively reduced, saving The host resource that needs to be consumed. The Redis active/standby switch process is relatively simple, and the client does not need to change the access ip to achieve the purpose of accessing the main Redis server after the switch.

Based on the same inventive concept, as shown in FIG. 4, an embodiment of the present invention provides a high-availability device for a Redis cluster. The cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the device include:

The monitoring unit 401 is configured to detect the connection link of each Redis server by initiating a detection thread;

The processing unit 402 is configured to initiate a voting if it is determined that the connection link of the second Redis server is faulty; the second Redis server is the primary Redis server; and the secondary Redis server whose voting result is greater than or equal to half is determined to be with the first Redis server. The second Redis server to switch from the Redis server; the VIP address of the first Redis server is set to the VIP address of the Redis cluster, so that the clients that access the Redis cluster can access the first Redis cluster according to the modified VIP address A Redis server.

In a possible implementation manner, the processing unit 402 is specifically configured to:

In a possible implementation manner, the processing unit 402 is further configured to: update the VIP address of the first Redis server to the ARP cache, so that the gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to The first Redis server.

In a possible implementation manner, the monitoring unit 401 is specifically configured to:

Taking into account that the Redis cluster in the embodiment of the present invention obtains the read and write request sent by the application, it may include:

Determine the corresponding Redis server according to the data primary key value in the read and write request;

Determine the corresponding port of the Redis server according to the hash value generated by the hash operation based on the data primary key value; determine the Redis instance corresponding to the read/write request according to the determined port.

For example, for a Redis cluster, the Redis cluster receives a read and write request from an application, and first determines which VIP node the read and write request corresponds to. After the VIP node is determined, the Redis cluster selects one from the corresponding connection pool Connect the link and transmit the read and write request to the VIP node. The VIP node then determines which Redis server corresponds to the read and write request according to the data primary key value in the read and write request, and then performs a hash operation based on the data primary key value to generate the ha Hopefully, the port of the corresponding Redis server is determined, and the Redis instance corresponding to the read and write request is determined according to the determined port. After the Redis instance is determined, the Redis cluster obtains a long connection from the connection pool corresponding to the Redis instance, so that the read and write request can be sent through the long connection.

Therefore, the Redis cluster in the embodiment of the present invention does not require cross-node access, which avoids that in the prior art, a large cluster of Redis version 3.0 or higher requires at least 3 main Redis servers, and the key is divided into slots. Each main Redis has a different slot. When the client accesses a certain Redis server, if the slot of the key is not in the Redis that is being accessed, it needs to be redirected to the Redis where the key is located, which is more efficient than the single Redis server. Access efficiency is low, and Redis commands that need to process multiple keys at the same time are not supported. For example, commands such as mset/mget do not support cross-node access.

Based on the same inventive concept, based on the above-mentioned embodiment, referring to FIG. 5, in the embodiment of the present invention, a schematic structural diagram of a computer device is shown.

The embodiment of the present invention provides a computer device. The computer device may include a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to implement connection and communication between these components. The user interface 1003 may include a display screen (Display) and an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as a magnetic disk memory. Optionally, the memory 1005 may also be a storage device independent of the foregoing processor 1001.

Those skilled in the art can understand that the structure shown in FIG. 5 does not constitute a limitation on the computer device, and may include more or less components than those shown in the figure, or a combination of certain components, or different component arrangements.

As a computer storage medium, the memory 1005 may include an operating system, a network communication module, a user interface module, and an information recommendation model generation program. Among them, the operating system is a program that manages and controls model parameters to obtain system hardware and software resources, and supports the generation of information recommendation models and the operation of other software or programs.

The user interface 1003 is mainly used to connect, the second server, the third server, etc., to communicate with each server; the network interface 1004 is mainly used to connect to the background server, and to communicate with the background server; and the processor 1001 can be used to call the memory The information recommended model generation program stored in 1005, and performs the following operations:

If it is determined that the connection link of the second Redis server is faulty, a voting is initiated; the second Redis server is the main Redis server; the Redis server whose voting result is greater than or equal to half is determined as the switch to the second Redis server From the Redis server; the VIP address of the first Redis server is set to the VIP address of the Redis cluster, so that clients accessing the Redis cluster can access the first Redis server according to the modified VIP address.

In a possible implementation manner, the processor 1001 is specifically configured to:

In a possible implementation manner, the processor 1001 is further configured to: update the VIP address of the first Redis server to the ARP cache, so that the gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to The first Redis server.

The present invention is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment. The instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. In this way, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.

Claims

A high-availability method for a Redis cluster, characterized in that the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the method includes:

The monitoring component of the first Redis server detects the connection link of each Redis server by initiating a detection thread;

If the monitoring component of the first Redis server determines that the connection link of the second Redis server is faulty, it initiates a vote; the second Redis server is the master Redis server;

If the monitoring component of the first Redis server determines that the slave Redis server whose voting result is greater than or equal to half is the first Redis server, the first Redis server is determined to be the slave that switches with the second Redis server Redis server;

The monitoring component of the first Redis server sets the VIP address of the first Redis server to the VIP address of the Redis cluster, so that clients that access the Redis cluster can access the first Redis cluster according to the modified VIP address. Redis server.
The method according to claim 1, wherein the monitoring component of the first Redis server setting the VIP address of the first Redis server to the VIP address of the Redis cluster comprises:

Acquiring, by the monitoring component of the first Redis server, the parameters transmitted by the monitoring component of the second Redis server during failover;

If the monitoring component of the first Redis server determines that the source IP address in the parameter is the IP address of the second Redis server, it initiates an unbinding operation of the VIP address;

If the monitoring component of the first Redis server determines that the destination IP address in the parameter is the IP address of the first Redis server, it detects whether the VIP address of the Redis cluster is in a connected state;

If the monitoring component of the first Redis server does not receive the connection return message, it binds the VIP address of the first Redis server to the Redis cluster.
The method according to claim 2, wherein if the monitoring component of the first Redis server does not receive the connection return message, the method further comprises:

The VIP address of the first Redis server is updated to the ARP cache, so that the gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.
The method according to any one of claims 1 to 3, wherein the monitoring component of the first Redis server detects the connection link of each Redis server by initiating a detection thread, comprising:

The monitoring component of the first Redis server sends a heartbeat detection to each Redis server;

If the heartbeat detection is successful, the available connection link is determined from the Redis instance that succeeded in the heartbeat detection.
A high-availability device for a Redis cluster, characterized in that the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the device includes:

The monitoring unit is used to detect the connection link of each Redis server by initiating a detection thread;

The processing unit is configured to initiate a voting if it is determined that the connection link of the second Redis server is faulty; the second Redis server is the primary Redis server; if it is determined that the secondary Redis server whose voting result is greater than or equal to half is the first Redis Server, the first Redis server is determined to be the slave Redis server that switches with the second Redis server; the VIP address of the first Redis server is set to the VIP address of the Redis cluster, so that the The client of the Redis cluster accesses the first Redis server according to the modified VIP address.
The device according to claim 5, wherein the processing unit is specifically configured to:

Obtain the parameters transmitted by the monitoring component of the second Redis server during failover; if it is determined that the source IP address in the parameters is the IP address of the second Redis server, initiate the unbinding operation of the VIP address; if It is determined that the destination IP address in the parameter is the IP address of the first Redis server, then it is detected whether the VIP address of the Redis cluster is in a connected state; if the connection return message is not received, the first Redis server The VIP address of is bound to the Redis cluster.
7. The device according to claim 6, wherein the processing unit is further configured to: update the VIP address of the first Redis server to the ARP cache, so that the gateway device of the Redis cluster confirms the Redis The VIP address of the cluster corresponds to the first Redis server.
The device according to any one of claims 5-7, wherein the monitoring unit is specifically configured to:

Send a heartbeat detection to each Redis server; if the heartbeat detection is successful, the available connection link is determined from the Redis instance with a successful heartbeat detection.
A computer device, characterized in that it comprises:

At least one processor; and,

A memory communicatively connected with the at least one processor; wherein,

The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor, so that the at least one processor can execute the method according to any one of claims 1 to 4 .
A non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the method described in any one of claims 1 to 4 .