With so many Redis clustering scenarios, which one should I use?

The article was reproduced from the public number: Little Sister Taste

Redis is fast and reliable, and is standard for Internet companies. It has four deployment modes, such as stand-alone, master, sentry, Cluster, etc.

Below, only from the deployment mode, to illustrate their advantages and disadvantages.

Stand-alone mode

The redis in stand-alone mode is very simple, you only need to start a single node, the installation process is not more than 5 minutes.

With the simple commands of redis-benchmark test, QPS can reach more than 10w which is amazing to say.

The problem with stand-alone mode is also evident. Lack of highly available mechanisms!

If the redis process redis the process can only penetrate the underlying database, which is very dangerous for the business. If you use redis as a data store, the situation can get worse and even lose data.

Master-from mode

So the most basic redis deployment will add one or more slave (now called replication

When there is a problem with the main redis it is possible to select a slave top.

Unfortunately, this mode, like the traditional MySQL master, is more egg-painful to switch from, requiring external tools such as keepalived to switch, and deployment and maintenance difficulties soar directly.

keepalived is a highly available scenario based on VRRP protocol, which is achieved through IP drift. As you can see from the description, it requires the involvement of network administrators, contrary to our lightweight redis

Sentinel mode

Sentinel mode is to use additional processes to replace the function of keepalived and to determine the viability of the redis process. In Sentinel mode, once the primary node goes down, the backup from the node as the primary node can be top-up at any time.

But one of the biggest problems with the Sentinel model is that the number of sentries is too high to require at least three nodes.

When arbitrated against redis a vote of n/2+1 node is required to confirm, which is also the general practice of distributed systems (quorum). Similar Zookeeper sentinel nodes are odd and are perfectly suited.

Sentinel mode can detect multiple clusters simultaneously through sentinel monitor configuration, which is still useful when the number of clusters is moderate.

But Sentinel mode has many hidden pits, such as sentry start-up, which must function properly if master redis and sentry cannot start if you use RENAME in your redis profile to mask some dangerous commands.

When a client redis it can no longer connect directly to an instance of redis and it needs to go round from the sentry to get some change information.

Cluster mode

"A Soul Exchange with your own Redis Cluster"

The cluster pattern is arguably the most elegant way to do it. All you need to do is deploy multiple peer-to-peer redis nodes and then 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 1

It is also more requirements for nodes, generally using 6 nodes, three main three from. When there are more than 10 nodes, its coordination is less flexible, so the storage and performance caps for a single cluster can be reached quickly.

Some of the drawbacks of the cluster pattern are hidden. I ts server-side nodes are very stable, but some commands can seriously affect performance. S uch as mget pipeline etc. T hey need to spread requests across multiple nodes to execute and re-aggregate. The more nodes there are, the lower the performance.

In the following article, we describe in detail some of the more generic redis usage redis some of which are designed to circumvent some of the problems caused by cluster pattern.

"Redis specification, this is probably the most pertinent"

Other scenarios

You can see that these cluster patterns in redis are not perfect. Dealing with small services can be problem-free, and in the case of large clusters and services, these deployments can be very challenging in terms of operations and usage.

Using client hash is a common way to do this on large Internet sites. Referring to the following article, real-world routing rules can be quite complex, but requests can always fall precisely on a small group.

"The rules of routing in reality may be more complex than you think"

For managing large clusters, I prefer the master-to-peer model and then use Java or other languages to develop a centrally controlled Sentinel system that manages thousands of clusters.

Because Redis is a text protocol, the protocol is very simple, Netty even built-in its parser, so developing such a Sentinel system is very simple.

Some middle-tier proxy software can also share some of the routing work, but because it is the middle tier, involving a layer of network forwarding, Redis a speed-winning service, is not very practical.

There are more variants, such as this article below, which uses the Redis protocol, but the back-end storage is MySQL so your command will be castrated.

Architecture Secrets: Moving Flowers and Wood. Simulate redis with mysql

As we can see from the above description, redis can be used is one thing, good use is another.

You may have spent a day building a single-node Redis; BUG T here is no difference between the two in the eyes of leaders who don't understand technology -- they both meet the needs of the business. But don't over-measure, reality is generally more brutal, computer systems are not as stable as imagined, Murphy's law will always have a time to teach them to be human.

Of course, leaders teach me to be human every day.

That's W3Cschool编程狮 should I use when there's so much about the Redis clustering scenario? Related to the introduction, I hope to help you.