Shulou(Shulou.com)06/01 Report--

This article mainly introduces "what are the Redis Cluster frequent meeting test questions". In the daily operation, I believe that many people have doubts about the Redis Cluster frequent meeting test questions. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "what are the Redis Cluster frequent meeting test questions?" Next, please follow the editor to study!

Talk about Redis cluster.

In the redis cluster cluster architecture, it can be composed of N redis master node, and each master node can mount multiple slave node.

Data can be sliced automatically, and a part of the data can be put on each master

It also provides built-in high availability support, and you can continue to work when some master is not available, because every master has a salve node, so if the mater is down, the redis cluster mechanism will automatically switch a slave to master.

Support read-write separation: for each master, it is responsible for writing requests, writing to master, and then reading from the corresponding slave of mater.

Summary: redis cluster (multiple master + read-write separation + high availability)

We only need to build a redis cluster based on redis cluster. There is no need to manually build replication replication + master-slave architecture + read-write separation + sentinel cluster + high availability.

What is the usage scenario of redis cluster and redis replication + sentinal

One-master, multi-slave, read-write separation + sentinel mechanism of redis replication + Sentinal:redis

If the amount of data is small, mainly for scenarios with high concurrency and high performance, for example, if the cache is usually only a few gigabytes, a single machine is sufficient. Then build a master-slave replication architecture (redis replication), one mater, multiple slave, several slave related to your required read throughput, and then build your own sentinal cluster to ensure the high availability of the redis master-slave architecture.

Redis cluster is mainly aimed at massive data + high concurrency + high availability scenarios. If it is massive data, if you have a large amount of data, it is recommended to use redis cluster.

How does redis cluster achieve data distribution? What are the advantages of this approach?

Redis cluster has a fixed 16384 hash slot (hash slot). The CRC16 value is calculated for each key, and then the corresponding hash slot of key can be obtained by taking the module 16384.

Each master in a redis cluster holds part of the slot (slot). For example, if there are three master, it is possible that each master holds more than 5000 hash slot.

Hash slot makes it easy to add and remove node. Add a master, move the hash slot of other master over, decrease one master, and move its hash slot to another master. Each addition or decrease of master nodes is based on 16384, not based on the number of master, so that the data originally on the old master will not be lost due to the addition or decrease of master. And the cost of redis cluster mobile hash slot is very low when adding or decreasing master.

What is the mechanism of communication between redis cluster nodes?

Redis cluster nodes communicate with each other using gossip protocol, and all nodes hold iFeng metadata. If there are metadata changes in different nodes, U constantly sends the metadata to other nodes to make data changes.

Nodes communicate with each other constantly, keeping the data of all nodes in the whole cluster intact.

It mainly exchanges fault information, addition and removal of nodes, hash slot information and so on.

The advantage of this mechanism is that the update of metadata is scattered, not concentrated in one place, and the update requests will be sent to all nodes to update one after another, with a certain delay and reducing the pressure.

The disadvantage is that there is a delay in updating metadata, which may lead to some lag in some operations of the cluster.

If you had a system with ultra-high read concurrency and used Redis to resist most read requests, how would you design it?

First of all, if it is a high read concurrency, let's first look at the order of magnitude of read concurrency. Because the read QPS of a redis stand-alone is at the level of 10,000, there is no problem with tens of thousands of reads per second. The cache architecture of "one Master, multiple Slave + Sentinel Cluster" is used to carry 10W + read concurrency per second, master-slave replication, and read-write separation. The main purpose of using Sentinel cluster is to improve the availability of cache architecture and solve the problem of single point of failure. The master database is responsible for writing, and multiple slave libraries are responsible for reading. It supports horizontal expansion. The number of redis slave instances to be added is determined according to the QPS of the read request. If read concurrency continues to increase, you only need to increase the redis from the instance.

If the business volume of the system increases now and you need to cache 1T + data, what do you do?

Because the bottleneck of supporting massive data in Redis is the capacity of a single machine, I will choose redis cluster mode at this time. Each master node stores part of the data. Suppose a master stores 32G, then only natively 32G > = 1TMagne n such master nodes can support the storage of 1T+ massive data.

The bottleneck of Redis single master is not the concurrency of read and write, but the memory capacity. Even one master and multiple slaves cannot solve this problem, because under one master and multiple slaves architecture, the data of multiple slave is exactly the same as that of master. If master is 10G, then slave can only store 10G data. So the amount of data is affected by the single owner.

At this time, a large amount of data needs to be cached, so there must be multiple masters, and the data saved by multiple masters can not be the same. The redis cluster model officially given by redis solves this problem perfectly.

Do you know what is the avalanche and penetration of redis? How to deal with it?

In fact, this is the cache must be asked, because cache avalanche and penetration, those are the two biggest cache problems, or do not appear, once there is a fatal problem. So the interviewer will ask you.

Let me first describe how the cache avalanche occurred.

For example, suppose the system has 5000 requests per second during the daily peak period, the cache peak can share 4000 requests per second, and another 1000 requests fall to the database (assuming that the database can undertake 2000 requests per second). If 5000 requests come in at this time, but the redis is down for some reason, and the cache cannot be used as a whole, then all 5000 requests will fall to the database. Obviously, the database couldn't handle it and crashed directly. At this time, if there is no special solution to deal with this failure, just very anxious to restart the database, as a result, because there is no data in the cache, the database is immediately killed by new traffic. This is the cache avalanche.

For cache avalanches, it is mainly divided into before and after.

Beforehand: if the cache is unavailable because most of the data sets in the cache fail, we can add a random value to the cache expiration time to disperse the failure time and avoid centralized failure as much as possible. In addition, if the cache is unavailable due to redis downtime due to other reasons, we need to build a highly available architecture for Redis in advance, such as Master / Slave + Sentinel or redis cluster, to prevent the entire cache from becoming unavailable and crashing in case of Redis failure.

Business: a small part of the data can also be cached to the local ehcache (local cache component) cache, plus hystrix current limit & downgrade component to avoid MySQL being killed.

Afterwards: if an avalanche does occur, we can also restart redis with redis's RDB or AOF to quickly load cached data from disk. This requires us to turn on the Redis persistence mechanism in advance to quickly recover cached data after an avalanche and restore data from disk to memory once restarted.

Another problem is cache penetration, which is usually a malicious attack by hackers or a bug from your own system. For example, hackers maliciously forge requests, these requests can not be found in the database, so the cache is also useless, then a large number of malicious requests will fall into the database to query, the database will not hang up?

The solution is

1. Write a null value to the cache as long as it is not found in the database.

2. Use the Bloom filter to filter the requested key to filter out the key that the system thinks is not illegal.

At this point, the study on "what are the test questions that Redis Cluster often meets" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.