Redis is a standard for Internet companies with high speed and reliability. It has four deployment modes: single-machine, master-slave, sentinel and Cluster.
Here, just in terms of deployment patterns, are some of the pros and cons.
Stand-alone mode
Single-machine Redis is very simple, you only need to start a single node, the installation process takes less than 5 minutes.
QPS can reach 10W or more using a simple command tested by Redis-Benchmark, which is pretty amazing.
The problems with single-player mode are also obvious. Lack of highly available mechanics!
If the Redis process dies, the process can only penetrate into the underlying database, which is very dangerous for the business. If you use Redis as a data store, the situation is even worse, and you can even lose data.
A master-slave mode
So the most basic Redis deployment adds one or more slaves (now called replication).
When the master redis fails, a slave can be selected to take over.
Unfortunately, this mode is the same as the traditional MySQL master-slave mode, which is painful to switch, and requires the use of external tools such as Keepalived to help switch, deployment and maintenance of a direct increase in difficulty.
Keepalived is a high availability solution based on VRRP protocol. Keepalived implements high availability through IP drift. The description suggests that it requires network administrator involvement, which is the opposite of our lightweight Redis.
The guard mode
In sentry mode, keepalived is replaced by an extra process to determine whether a Redis process is alive. In Sentry mode, if the master node goes down, backup from the slave node can be taken over at any time.
However, one of the biggest problems with sentinel mode is that there are too many sentinels, requiring at least three nodes.
Quorum of REDis requires n/2+1 votes for confirmation, which is common practice for distributed systems. Like Zookeeper, an odd number of sentinel nodes is appropriate.
The Sentinel mode can be configured to detect multiple sets of clusters at the same time, and is useful when the number of clusters is moderate.
The Sentinel mode has many hidden potholes, such as the sentinel boot, which must be kept alive to work properly; Also, sentry will not be able to start if RENAME blocks dangerous commands in your Redis configuration file.
When a client connects to Redis, it can no longer connect directly to an instance of Redis. It needs to go around the sentinel to get some change information.
Cluster pattern
The love of Redis Cluster: a Labour of Love.
Cluster mode is arguably the most elegant way of doing this. All you need to do is deploy multiple peer Redis nodes and group them using client commands.
IP =192.169.0.23./bin/redis-cli --cluster create $IP :7001 $IP :7002 $IP :7003 $IP :7004 $IP :7005 $IP :7006 --cluster-replicas 1Copy the code
It also has more requirements for nodes, generally using 6 nodes, three master and three subordinate. With more than 10 nodes, coordination becomes less flexible, so the storage and performance ceiling for a single cluster can be reached quickly.
Some of the drawbacks of the cluster model are subtle. The server node is very stable, but some commands can seriously affect performance. Such as MGET,pipeline, etc. They require requests to be spread across multiple nodes for execution and reaggregation. The more nodes, the lower the performance.
In the following article, we describe in detail some of the more general redis usage specifications, some of which are intended to circumvent some of the problems caused by the cluster pattern.
This is probably the most pertinent Redis specification yet.
Other options
As you can see, none of these redis clusters are perfect. It may not be a problem to deal with small services, but for large clusters and services, these deployment methods are very challenging for operation and maintenance and usage.
The client hash method is commonly used on large Internet networks. As you can see from the following article, the routing rules in real life can be quite complex, but requests always fall precisely on a small group.
For managing large clusters, I prefer the master-slave model, and then develop a centrally managed sentinel system in Java or some other language to manage thousands of clusters.
Because Redis is a text protocol, the protocol is very simple, Netty even directly built in its parser, so the development of such a sentinel system is very simple.
Some mid-tier proxy software can also share some routing work, but because it is mid-tier and involves a layer of network forwarding, it is not very practical for a speed-driven service like Redis.
There are more variations, such as this one, which uses the Redis protocol but uses MySQL for back-end storage, so your commands will be neutered.
From the above description, we can see that it is one thing to use Redis and another to use it well.
You might spend a day building a single-node Redis; I probably spent a week writing a Java version of Sentry with a lot of bugs. In the eyes of non-technical leaders, there is no difference between the two — they both meet the needs of the business. But there is no need to care too much, the reality is generally cruel, the computer system is not as stable as imagined, Murphy’s law will always have a time to teach them to be a man.
Of course, the leader teaches me how to behave every day.
You can follow my B station account →→→→B station account
Study communication groups →→→→ →Communication group