CN110224871B - High-availability method and device for Redis cluster - Google Patents
High-availability method and device for Redis cluster Download PDFInfo
- Publication number
- CN110224871B CN110224871B CN201910540450.2A CN201910540450A CN110224871B CN 110224871 B CN110224871 B CN 110224871B CN 201910540450 A CN201910540450 A CN 201910540450A CN 110224871 B CN110224871 B CN 110224871B
- Authority
- CN
- China
- Prior art keywords
- redis
- server
- redis server
- cluster
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/30—Decision processes by autonomous network management units using voting and bidding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/10—Mapping addresses of different types
- H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/58—Caching of addresses or names
Abstract
The embodiment of the invention relates to the field of science and technology finance (Fintech), and discloses a high-availability method and a high-availability device of a Redis cluster, wherein the cluster comprises at least two Redis servers and monitoring components which are correspondingly configured with the Redis servers; the method comprises the following steps: a monitoring component of a first Redis server detects a connection link of each Redis server by initiating a detection thread; if the monitoring component of the first Redis server determines that a connection link of the second Redis server fails, voting is initiated; the monitoring component of the first Redis server determines the slave Redis servers with voting results larger than or equal to half of those of the slave Redis servers as the slave Redis servers switched with the second Redis server; the method and the system reduce the cost under the condition of realizing the VIP drift of the faults of the Redis server.
Description
Technical Field
The invention relates to the technical field of communication of financial technology (Fintech), in particular to a high-availability method and device of a Redis cluster.
Background
With the development of computer technology, more and more technologies are applied in the financial field, the traditional financial industry is gradually changing to financial technology (Fintech), the Redis cluster technology is no exception, but due to the requirements of security and real-time performance of the financial industry, higher requirements are also put forward on the technologies.
At present, in order to solve the performance problem caused by high concurrency, a cache layer is adopted between a web application system and a database, and the most widely used is Redis (Redis is a key-value type memory database in nature). Redis is used as a buffer layer between software and a traditional database, the operation command is simple, and high performance is guaranteed under the condition that data validity is guaranteed.
In the prior art, in order to realize a server with the purposes of high availability of Redis and service interruption time reduction, the influence of a fault caused by software/hardware/human factors on a service is reduced to the minimum degree by protecting the service which is uninterruptedly provided by a service program of a user, a component needs to be migrated to perform fault migration, a plurality of monitoring components are needed to perform monitoring on the server, the number of needed components is too many, and the maintenance cost is high.
Disclosure of Invention
The embodiment of the invention provides a high-availability method and device for a Redis cluster, which are used for solving the problems of excessive components for accessing a Redis database and higher maintenance cost in the prior art.
The embodiment of the invention provides a high-availability method of a Redis cluster, wherein the cluster comprises at least two Redis servers and monitoring components which are configured corresponding to the Redis servers; the method comprises the following steps:
a monitoring component of a first Redis server detects a connection link of each Redis server by initiating a detection thread;
if the monitoring component of the first Redis server determines that a second Redis server connection link fails, voting is initiated; the second Redis server is a main Redis server;
if the monitoring component of the first Redis server determines that the secondary Redis servers with voting results larger than or equal to half of the voting results are the first Redis server, determining the first Redis server as the secondary Redis server switched with the second Redis server;
and the monitoring component of the first Redis server sets the VIP address of the first Redis server as the VIP address of the Redis cluster, so that clients accessing the Redis cluster access the first Redis server according to the modified VIP address.
A possible implementation manner for the monitoring component of the first Redis server to set the VIP address of the first Redis server to the VIP address of the Redis cluster includes:
the monitoring component of the first Redis server acquires 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 parameters is the IP address of the second Redis server, initiating a VIP address unbinding operation;
if the monitoring component of the first Redis server determines that the destination IP address in the parameters is the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state;
and if the monitoring component of the first Redis server does not receive the communication return message, binding the VIP address of the first Redis server to the Redis cluster.
A possible implementation manner, if the monitoring component of the first Redis server does not receive the communication return message, further comprising:
updating the VIP address of the first Redis server to an ARP cache, so that a gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.
A possible implementation manner is that a monitoring component of the first Redis server detects a connection link of each Redis server by initiating a sniffing thread, including:
the monitoring component of the first Redis server sends heartbeat detection to each Redis server;
and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
The embodiment of the invention provides a high-availability device of a Redis cluster, wherein the cluster comprises at least two Redis servers and monitoring components which are configured corresponding to the Redis servers; the device includes:
the monitoring unit is used for detecting the connection link of each Redis server by initiating a detection thread;
the processing unit is used for initiating voting if the second Redis server connection link is determined to be in fault; the second Redis server is a main Redis server; if the fact that the voting result is larger than or equal to half of the slave Redis servers is determined to be the first Redis server, determining the first Redis server to be the slave Redis server switched with the second Redis server; and setting the VIP address of the first Redis server as 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.
In a possible implementation manner, the processing unit is specifically configured to:
acquiring parameters transmitted by a monitoring component of the second Redis server during fault switching; if the source IP address in the parameters is determined to be the IP address of the second Redis server, initiating the operation of unbinding the VIP address; if the target IP address in the parameters is determined to be the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state; and if the communication return message is not received, binding the VIP address of the first Redis server to the Redis cluster.
In one possible implementation manner, the processing unit is further configured to: updating the VIP address of the first Redis server to an ARP cache so that a 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 is specifically configured to:
sending heartbeat detection to each Redis server; and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
The cluster comprises 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; detecting a connection link of each Redis server by initiating a detecting thread through a monitoring component of a first Redis server; if the monitoring component of the first Redis server determines that a second Redis server connection link fails, voting is initiated; the second Redis server is a main Redis server; the monitoring component of the first Redis server determines the slave Redis servers with voting results larger than or equal to half of those of the slave Redis servers as the slave Redis servers switched with the second Redis server; and the monitoring component of the first Redis server sets the VIP address of the first Redis server as the VIP address of the Redis cluster, so that clients accessing the Redis cluster access the first Redis server according to the modified VIP address. When reducing the monitoring subassembly, realized the VIP drift of the trouble of Redis server, need not increase extra monitoring subassembly to, because the setting of VIP address is accomplished through the monitoring subassembly, do not need other subassemblies among the prior art to accomplish, further reduced the setting of subassembly, reduced the cost of maintaining.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1a provides a Redis cluster architecture according to an embodiment of the present invention;
FIG. 1b provides a Redis cluster architecture according to an embodiment of the present invention;
FIG. 2 is a block diagram of a Redis cluster according to an embodiment of the present invention;
fig. 3 is a schematic flow chart of a high availability method for a Redis cluster according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of a high-availability device of a Redis cluster according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a Redis monitoring component according to an embodiment of the present invention.
Detailed Description
To make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail with reference to the accompanying drawings. All other embodiments, which can be obtained by a person skilled in the art without making any creative effort based on the embodiments in the present invention, belong to the protection scope of the present invention.
High availability clustering refers to a server clustering technique with the goal of reducing service disruption time. The method and the system reduce the influence of faults caused by software/hardware/human to the service to the minimum degree by protecting the service which is continuously provided by the service program of the user to the outside.
Redis Server, an open-source, network-enabled, memory-based, optionally persistent, key-value pair storage database written using ANSI C, is also commonly used as a caching database.
Monitoring component sentinel: and monitoring the available state of the redis server. When Redis is used as a high-availability scheme of a master Redis server and a slave Redis server, if the master Redis server is down, the Redis (including a plurality of clients) does not automatically switch between the master and the slave, and whether the Redis operates well as expected can be monitored by monitoring a sensor component of the Redis; if a certain redis node operation is found to be failed, another process (such as a client side thereof) can be informed to perform automatic switching.
The Redis-monitoring component sentinel is also an independently running process, can monitor a plurality of main Redis servers-slave Redis server clusters, and can automatically switch after the main Redis server is found to be down. It is unreliable to use only a single monitoring component sentinel process to monitor the redis cluster, and when the monitoring component sentinel process is running wrongly or is network-blocked, the master-slave switching of the redis cluster cannot be realized (the monitoring component sentinel itself also has a single point problem, and the whole cluster system cannot run in an expected manner). Therefore, it is necessary to cluster the monitoring components sentinel, i.e. a plurality of monitoring components sentinel need to be provided.
When a master Redis server node is unavailable, the monitoring component can elect one of the at least one slave Redis servers of the master Redis server as a 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 sentinel can communicate with each other, a failure migration is authorized to be carried out finally, and the activity of Redis is guaranteed.
Keepalived-a component for health status checking under a load balancing cluster and a component for maintaining failover between hosts and standby machines.
HAProxy is a free and open source software written in C language that provides high availability, load balancing, and TCP and HTTP based application proxies.
Vip is the ip address in the cluster for external access, usually only one.
In practical applications, there are multiple structures for the deployment manner of Redis, and in the embodiment of the present invention, an example of the deployment manner is provided, as shown in fig. 1a, one deployment manner is to deploy a VIP node, the VIP node manages and controls multiple nodes, each node manages one instance group, and the VIP node implements a function of data fragmentation, that is, a read-write request sent by an application program is distributed to an instance group corresponding to a corresponding node through the VIP node for processing.
If fault migration occurs, aiming at master-slave switching of the Redis server, the slave Redis server can be switched to the master Redis server through Keepalived. Keepalive can set up in every Redis server, if control subassembly sentinel confirms current main Redis server operation trouble, confirms that to carry out the fault migration, can pass through keepalive, with the process on the main Redis server of trouble, migrate to the new main Redis server that control subassembly sentinel determined.
Aiming at the switching of the VIP node, the HAproxy component can be arranged in each Redis server, the master-slave switching of the Redis servers can be instantly detected through the HAproxy component, if the master-slave switching of the Redis servers is determined to be completed, the VIP address of a new master Redis server is started and is set as the VIP address of the current Redis cluster, and the switching of the VIP address can be realized through the VRRP by specific setting.
The switching of the VIP address may be implemented by a Virtual Router Redundancy Protocol (VRRP). The VRRP may virtualize a physical router device of the first Redis server and a physical router device of the second Redis server into a virtual router, where the virtual router provides services to the outside through a Virtual IP (VIP), and may include multiple physical routers inside the virtual router to cooperate with each other, and only one physical router provides services to the outside at the same time, that is, a main router, for example, if the current main Redis server is the first Redis server, then the server is provided to the outside only through the physical router of the first Redis server at this time. The main router is generated by election algorithm, possesses virtual IP for external service, and provides various network functions, such as: ARP request, ICMP (Internet Control Message Protocol) data forwarding, etc., and other physical routers do not possess external virtual IP and provide external network functions, and only receive VRRP status advertisement information of the master router, which are backup routers. When the main router fails, the backup router performs election again, a new main router is generated to enter the main router to continue to provide external services, and the whole switching is completely transparent to the client.
Under the condition of one master Redis server and one or more slave Redis servers, each master Redis server and each slave Redis server are respectively provided with a monitoring component sentinel component; in addition, because one of the multiple slave Redis servers of the master Redis server needs to be elected as a new master Redis server, if the total number of the master Redis server and the slave Redis servers is an even number, in order to ensure that election is smoothly performed, a monitoring component sentinel of 1 Redis server needs to be additionally arranged, and the problem is not obvious in a large cluster, but in a small cluster, the additionally arranged component increases maintenance cost.
As shown in fig. 1b, an embodiment of the present invention provides another deployment manner, where there are a plurality of instance groups in a Redis cluster, an application is directly connected to the plurality of instance groups, that is, the application is connected to a plurality of groups of servers in master-slave cooperation, and each master server runs a plurality of instances responsible for data backup.
Under the scheme, for a deployment scheme of a cluster not based on VIP, when switching occurs, the switching of the main Redis server needs to inform the client through the monitoring component sentinel, and the client needs to be reconnected to the switched main Redis server. In a specific implementation process, the client needs to monitor an event queue of the monitoring component sentinel, obtain an ip port of the switched main Redis server, and initiate access to the ip port of the switched main Redis server, which is not favorable for timeliness of switching compared with a deployment scenario with a VIP node.
For the same reason, one of the multiple slave Redis servers of the master Redis server needs to be elected as a new master Redis server, and if the total number of the master Redis server and the slave Redis servers is an even number, in order to ensure smooth election, on the premise of one master Redis server and one slave Redis server, 1 monitoring component sentinel needs to be additionally arranged, and in a small cluster, the additionally arranged component increases the maintenance cost.
Based on the above problem, referring to fig. 2, the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; as shown in fig. 3, an embodiment of the present invention provides a schematic flow diagram of a high-availability method for a Redis cluster, and a specific implementation method includes:
step 301: a monitoring component sentinel of a first Redis server detects a connection link of each Redis server by initiating a detection thread;
a possible implementation manner is that a monitoring component of the first Redis server detects a connection link of each Redis server by initiating a sniffing thread, including:
the monitoring component of the first Redis server sends heartbeat detection to each Redis server;
and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
Specifically, a separate thread may be started to periodically send a detection packet to each Redis instance, and the health status of the Redis instance may be determined according to the response. In addition, a feedback interface is also opened to an external caller, and when the caller reads and writes Redis and encounters abnormity, the feedback interface can be called so as to update the health state of the Redis instance in time.
Step 302: if the monitoring component of the first Redis server determines that a second Redis server connection link fails, voting is initiated; the second Redis server is a main Redis server;
specifically, after the monitoring component sentinel monitors that the primary Redis server is disconnected in a specific time, it confirms that the secondary Redis server fails, and needs to trigger failover.
Step 303: if the monitoring component of the first Redis server determines that the secondary Redis servers with voting results larger than or equal to half of the voting results are the first Redis server, determining the first Redis server as the secondary Redis server switched with the second Redis server;
in the specific implementation process, all monitoring components sentinel monitoring the master Redis server participate in voting, and a slave Redis server is switched to the master Redis server. Under the architecture scene that only one slave Redis server exists, more monitoring components sentinel are not needed to participate in voting, and only half of voting is needed, so that the switching success can be ensured under the condition that the master Redis server is down, and the resources of the monitoring components sentinel are also saved. Correspondingly, the voting mode 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;
therefore, triggering of fault transfer can be completed only by half of the monitoring assemblies sentinel in the cluster.
Step 304: and the monitoring component of the first Redis server sets the VIP address of the first Redis server as 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 cluster comprises 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; detecting a connection link of each Redis server by initiating a detection thread through a monitoring component of a first Redis server; if the monitoring component of the first Redis server determines that a second Redis server connection link fails, voting is initiated; the second Redis server is a main Redis server; the monitoring component of the first Redis server determines the slave Redis servers with voting results larger than or equal to half of those of the slave Redis servers as the slave Redis servers switched with the second Redis server; and the monitoring component of the first Redis server sets the VIP address of the first Redis server as the VIP address of the Redis cluster, so that clients accessing the Redis cluster access the first Redis server according to the modified VIP address. Switching of Redis servers in Redis clusters is achieved through a voting mechanism, monitoring components are reduced, simultaneously VIP drifting of faults of the Redis servers is achieved, additional monitoring components do not need to be added, and due to the fact that the VIP addresses are set through the monitoring components, other components in the prior art are not needed to be set, setting of the components is further reduced, and maintenance cost is reduced. When Redis clusters of financial institutions such as banks are switched with Redis servers, the cost is lower, the maintenance cost is reduced, and the economic benefit is more obvious.
In step 304, one possible implementation includes:
firstly, a monitoring component of a first Redis server acquires parameters transmitted by a monitoring component of a second Redis server during fault switching;
step two, if the monitoring component of the first Redis server determines that the source IP address in the parameters is the IP address of the second Redis server, initiating a binding releasing operation of the VIP address;
step three, if the monitoring component of the first Redis server determines that the destination IP address in the parameters is the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state;
and step four, if the monitoring component of the first Redis server does not receive the communication return message, binding the VIP address of the first Redis server to the Redis cluster.
In a specific implementation process, a script is triggered when a main Redis server of a Redis cluster fails to transfer, and the script can be written in a shell language.
Specifically, the script is used for judging 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 from-IP parameter is the native IP, the VIP-bindable address is still the second Redis server, and therefore, the VIP unbinding operation can be executed by the IP command of the operating system. For example, "/bin/ip addr del { VIP }/24dev eth0". For example, if the IP address in the parameter to-IP is the local IP, it may be determined that the address of the VIP is the switched primary Redis server, and therefore, a ping message needs to be sent to the VIP; if the corresponding PONG message is determined to be received, the link is determined to be normal, and the relevant time is waited to start the switched VIP. If the PONG message corresponding to the sent ping cannot be received, the current VIP is unbound, the switched first Redis server is not bound, and the VIP needs to be bound on the first Redis server. For example, this may be achieved by: "/bin/ip addr add { VIP }/24dev eth0".
In a scenario with an Address Resolution Protocol (ARP), a possible implementation manner is that if the monitoring component of the first Redis server does not receive a connection return message, the method further includes:
updating the VIP address of the first Redis server to an ARP cache, so that a gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.
In particular, the arp cache of the VIP within the local area network may be updated. For example, this may be achieved by: /usr/sbin/arping-I eth0-A { VIP } -c 3.
Therefore, a 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, and thus, the client can access the first Redis server through the VIP in case of failure, and a high-availability cluster which can drift through the VIP is realized.
The embodiment of the invention provides a high-availability method of a Redis cluster with higher efficiency, and compared with other clusters, the method reduces the maintenance components and avoids the cost of learning other components; in addition, the use of the monitoring assembly is effectively reduced, and the host resources required to be consumed are saved. The Redis master-slave switching process is relatively simple, and the client does not need to replace the accessed ip, so that the aim of accessing the switched master Redis server is fulfilled.
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, where the cluster includes at least two Redis servers and monitoring components configured corresponding to the Redis servers; the device includes:
the monitoring unit 401 is configured to detect a connection link of each Redis server by initiating a detection thread;
a processing unit 402, configured to initiate a vote if it is determined that a second Redis server connection link fails; the second Redis server is a main Redis server; determining the secondary Redis servers with voting results larger than or equal to half of those of the secondary Redis servers as the secondary Redis servers switched with the second Redis server; and setting the VIP address of the first Redis server as 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.
In a possible implementation manner, the processing unit 402 is specifically configured to:
acquiring parameters transmitted by a monitoring component of the second Redis server during fault switching; if the source IP address in the parameters is determined to be the IP address of the second Redis server, initiating the operation of unbinding the VIP address; if the target IP address in the parameters is determined to be the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state or not; and if the communication return message is not received, binding the VIP address of the first Redis server to the Redis cluster.
In a possible implementation manner, the processing unit 402 is further configured to: updating the VIP address of the first Redis server to an ARP cache, so that a 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:
sending heartbeat detection to each Redis server; and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
Considering that the Redis cluster in the embodiment of the present invention obtains the read/write request sent by the application program, the method may include:
determining a corresponding Redis server according to the data primary key value in the read-write request;
determining a corresponding port of the Redis server according to a hash value generated by performing hash operation on the data primary key value; and determining a 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-write request sent by an application program, firstly determines which VIP node corresponding to the read-write request, after the VIP node is determined, the Redis cluster selects a connection link from a corresponding connection pool, transmits the read-write request to the VIP node, the VIP node determines which Redis server corresponding to the read-write request according to a data primary key value in the read-write request, then determines a port of the corresponding Redis server according to a hash value generated by hash operation according to the data primary key value, and determines a Redis instance corresponding to the read-write request according to the determined port. After the Redis instance is determined, the Redis cluster acquires a long connection from the connection pool corresponding to the Redis instance, so that the read-write request can be sent through the long connection.
Therefore, the Redis cluster in the embodiment of the invention does not need cross-node access, and avoids the problem that in the prior art, a large cluster above Redis3.0 version needs at least 3 main Redis servers, and keys are divided into slots, and each main Redis has a different slot, so that when a client accesses a certain Redis server, if the slot where the key is located is not the Redis of the access, the client needs to be redirected to the Redis where the key is located for access, the efficiency is lower than that of a single Redis server, and Redis commands which need to process a plurality of keys at the same time are not supported, for example, commands such as mset/mget and the like do not support cross-node access.
Based on the same inventive concept, referring to fig. 5, a schematic structural diagram of a computer device according to an embodiment of the present invention is shown.
An embodiment of the present invention provides a computer device, where the computer device may include: a processor 1001, e.g. a CPU, a network interface 1004, a user interface 1003, a memory 1005, a communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 1005 may alternatively be a storage device separate from the processor 1001.
Those skilled in the art will appreciate that the configuration shown in FIG. 5 does not constitute a limitation of a computer device and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
The memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a generation program of an information recommendation model. The operating system is a program for managing and controlling the model parameter acquisition system hardware and software resources, and supports the generation program of the information recommendation model and the operation of other software or programs.
The user interface 1003 is mainly used for connecting, connecting with a second server, a third server, and the like, and performs data communication with each server; the network interface 1004 is mainly used for connecting a background server and performing data communication with the background server; and the processor 1001 may be configured to call the generation program of the information recommendation model stored in the memory 1005, and perform the following operations:
if the fact that the second Redis server connection link fails is determined, voting is initiated; the second Redis server is a main Redis server; determining the secondary Redis servers with voting results larger than or equal to half of those of the secondary Redis servers as the secondary Redis servers switched with the second Redis server; and setting the VIP address of the first Redis server as 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.
In a possible implementation manner, the processor 1001 is specifically configured to:
acquiring parameters transmitted by a monitoring component of the second Redis server during fault switching; if the source IP address in the parameters is determined to be the IP address of the second Redis server, initiating the operation of unbinding the VIP address; if the target IP address in the parameters is determined to be the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state or not; and if the communication return message is not received, binding the VIP address of the first Redis server to the Redis cluster.
In one possible implementation manner, the processor 1001 is further configured to: updating the VIP address of the first Redis server to an ARP cache so that a 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 processor 1001 is specifically configured to:
sending heartbeat detection to each Redis server; and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including the preferred embodiment and all changes and modifications that fall within the scope of the invention.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (10)
1. A high-availability method of a Redis cluster is characterized in that the cluster comprises at least two Redis servers and monitoring components configured corresponding to the Redis servers; the method comprises the following steps:
a monitoring component of a first Redis server detects a connection link of each Redis server by initiating a detecting thread;
if the monitoring component of the first Redis server determines that a second Redis server connection link fails, voting is initiated; the second Redis server is a main Redis server;
if the monitoring component of the first Redis server determines that the secondary Redis servers with voting results larger than or equal to half of the voting results are the first Redis server, determining the first Redis server as the secondary Redis server switched with the second Redis server;
the monitoring component of the first Redis server sets the VIP address of the first Redis server as the VIP address of the Redis cluster, so that clients accessing the Redis cluster access the first Redis server according to the modified VIP address; the switching of the VIP address is realized by a Virtual Routing Redundancy Protocol (VRRP).
2. The method of 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, comprising:
the monitoring component of the first Redis server acquires 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 parameters is the IP address of the second Redis server, initiating a VIP address unbinding operation;
if the monitoring component of the first Redis server determines that the destination IP address in the parameters is the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state;
and if the monitoring component of the first Redis server does not receive the communication return message, binding the VIP address of the first Redis server to the Redis cluster.
3. The method of claim 2, wherein the monitoring component of the first Redis server, if not receiving a connectivity return message, further comprises:
updating the VIP address of the first Redis server to an ARP cache, so that a gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.
4. A method according to any of claims 1-3, wherein the monitoring component of the first Redis server snooping the connection links of the Redis servers by initiating a sniffing thread, comprising:
the monitoring component of the first Redis server sends heartbeat detection to each Redis server;
and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
5. The high-availability device of the Redis cluster is characterized in that the cluster comprises at least two Redis servers and monitoring components which are configured corresponding to the Redis servers; the device comprises:
the monitoring unit is used for detecting the connection links of the Redis servers by initiating a detection thread;
the processing unit is used for initiating voting if the second Redis server connection link is determined to be in fault; the second Redis server is a main Redis server; if the fact that the voting result is larger than or equal to half of the slave Redis servers is determined to be the first Redis server, determining the first Redis server to be the slave Redis server switched with the second Redis server; setting the VIP address of the first Redis server as the VIP address of the Redis cluster, so that a client accessing the Redis cluster accesses the first Redis server according to the modified VIP address; the switching of the VIP address is realized by a Virtual Routing Redundancy Protocol (VRRP).
6. The apparatus according to claim 5, wherein the processing unit is specifically configured to:
acquiring parameters transmitted by a monitoring component of the second Redis server during fault switching; if the source IP address in the parameters is determined to be the IP address of the second Redis server, initiating a VIP address unbinding operation; if the target IP address in the parameters is determined to be the IP address of the first Redis server, detecting whether the VIP address of the Redis cluster is in a connected state; and if the communication return message is not received, binding the VIP address of the first Redis server to the Redis cluster.
7. The apparatus as recited in claim 6, said processing unit to further: updating the VIP address of the first Redis server to an ARP cache, so that a gateway device of the Redis cluster confirms that the VIP address of the Redis cluster corresponds to the first Redis server.
8. The device according to any one of claims 5 to 7, characterized in that said monitoring unit is specifically configured to:
sending heartbeat detection to each Redis server; and if the heartbeat detection is successful, determining an available connection link from the Redis instance with successful heartbeat detection.
9. A computer device, comprising:
at least one processor; and (c) a second step of,
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4.
10. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 4.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910540450.2A CN110224871B (en) | 2019-06-21 | 2019-06-21 | High-availability method and device for Redis cluster |
| PCT/CN2020/095421 WO2020253596A1 (en) | 2019-06-21 | 2020-06-10 | High availability method and apparatus for redis cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910540450.2A CN110224871B (en) | 2019-06-21 | 2019-06-21 | High-availability method and device for Redis cluster |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110224871A CN110224871A (en) | 2019-09-10 |
| CN110224871B true CN110224871B (en) | 2022-11-08 |
Family
ID=67814194
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910540450.2A Active CN110224871B (en) | 2019-06-21 | 2019-06-21 | High-availability method and device for Redis cluster |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110224871B (en) |
| WO (1) | WO2020253596A1 (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110674192A (en) * | 2019-10-09 | 2020-01-10 | 浪潮云信息技术有限公司 | Redis high-availability VIP (very important person) drifting method, terminal and storage medium |
| US11917001B2 (en) * | 2020-02-04 | 2024-02-27 | Nutanix, Inc. | Efficient virtual IP address management for service clusters |
| CN111444062B (en) * | 2020-04-01 | 2023-09-19 | 山东汇贸电子口岸有限公司 | Method and device for managing master node and slave node of cloud database |
| CN113535126A (en) * | 2020-04-14 | 2021-10-22 | 天津科技大学 | House renting platform based on SSM |
| CN112306720B (en) * | 2020-11-23 | 2022-06-21 | 迈普通信技术股份有限公司 | Service system cluster management method |
| CN112860485A (en) * | 2021-02-03 | 2021-05-28 | 北京北信源信息安全技术有限公司 | Control method of dual-computer hot standby system based on keepalived |
| CN113079192B (en) * | 2021-02-08 | 2021-12-31 | 马上消费金融股份有限公司 | Information processing method, device, equipment and readable storage medium |
| CN113806181A (en) * | 2021-09-24 | 2021-12-17 | 重庆富民银行股份有限公司 | Redis multi-cluster automatic monitoring method and system |
| CN114363156A (en) * | 2022-01-25 | 2022-04-15 | 南瑞集团有限公司 | Hydropower station computer monitoring system deployment method based on cluster technology |
| CN114785713B (en) * | 2022-03-31 | 2024-02-23 | 度小满科技(北京)有限公司 | Method and proxy middleware for realizing high availability of Redis cluster |
| CN115037785B (en) * | 2022-08-12 | 2022-11-01 | 深圳市星卡软件技术开发有限公司 | Instant communication system and method |
| CN116546092B (en) * | 2023-07-04 | 2023-10-13 | 深圳市亲邻科技有限公司 | Redis-based object model storage system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105933407A (en) * | 2016-04-20 | 2016-09-07 | 中国银联股份有限公司 | Method and system for achieving high availability of Redis cluster |
| CN106210151A (en) * | 2016-09-27 | 2016-12-07 | 深圳市彬讯科技有限公司 | A kind of zedis distributed caching and server cluster monitoring method |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10191824B2 (en) * | 2016-10-27 | 2019-01-29 | Mz Ip Holdings, Llc | Systems and methods for managing a cluster of cache servers |
| CN106534328B (en) * | 2016-11-28 | 2020-01-31 | 网宿科技股份有限公司 | Node connection method and distributed computing system |
| CN108206843B (en) * | 2016-12-16 | 2021-06-04 | 北京金山云网络技术有限公司 | Cluster access method and device |
-
2019
- 2019-06-21 CN CN201910540450.2A patent/CN110224871B/en active Active
-
2020
- 2020-06-10 WO PCT/CN2020/095421 patent/WO2020253596A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105933407A (en) * | 2016-04-20 | 2016-09-07 | 中国银联股份有限公司 | Method and system for achieving high availability of Redis cluster |
| CN106210151A (en) * | 2016-09-27 | 2016-12-07 | 深圳市彬讯科技有限公司 | A kind of zedis distributed caching and server cluster monitoring method |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020253596A1 (en) | 2020-12-24 |
| CN110224871A (en) | 2019-09-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110224871B (en) | High-availability method and device for Redis cluster | |
| US20200358848A1 (en) | Methods, systems, and media for providing distributed database access during a network split | |
| US7225356B2 (en) | System for managing operational failure occurrences in processing devices | |
| CN108075971B (en) | Main/standby switching method and device | |
| JP2019219954A (en) | Cluster storage system, data management control method, and data management control program | |
| US9992058B2 (en) | Redundant storage solution | |
| US10771318B1 (en) | High availability on a distributed networking platform | |
| KR20030003264A (en) | Server duplexing method and duplexed server system | |
| KR20070026327A (en) | Redundant routing capabilities for a network node cluster | |
| US20150113313A1 (en) | Method of operating a server system with high availability | |
| CN104503965A (en) | High-elasticity high availability and load balancing realization method of PostgreSQL (Structured Query Language) | |
| US11403319B2 (en) | High-availability network device database synchronization | |
| US20180309662A1 (en) | On-demand control plane redundancy | |
| JP4964666B2 (en) | Computer, program and method for switching redundant communication paths | |
| CN113849136B (en) | Automatic FC block storage processing method and system based on domestic platform | |
| US10067841B2 (en) | Facilitating n-way high availability storage services | |
| US10305987B2 (en) | Method to syncrhonize VSAN node status in VSAN cluster | |
| US11418382B2 (en) | Method of cooperative active-standby failover between logical routers based on health of attached services | |
| CN111400285A (en) | MySQ L data fragment processing method, apparatus, computer device and readable storage medium | |
| CN113709220B (en) | High-availability implementation method and system of virtual load equalizer and electronic equipment | |
| WO2020241032A1 (en) | Fault-tolerant system, server, fault-tolerant system operation method, server operation method, and program for server operation method | |
| CN112882771A (en) | Server switching method and device of application system, storage medium and electronic equipment | |
| US11947431B1 (en) | Replication data facility failure detection and failover automation | |
| US20230254270A1 (en) | Computer-readable recording medium storing program, information processing method, and information processing system | |
| JP6954693B2 (en) | Fault-tolerant systems, servers, how they operate, and programs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |