Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to solve Redis hot data problems". In daily operation, I believe many people have doubts about how to solve Redis hot data problems. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "how to solve Redis hot data problems". Next, please follow the editor to study!

1. Interviewer: have you encountered any Redis hot data problems in the project? what are the common causes?

Problem analysis: the last time I listened to the big guy in the group interview Ali p7 was asked this question, the difficulty index is five stars, which is really an additional item for me and other rookies.

A: I have something to say about hot data issues. I was aware of this problem when I first learned to use Redis, so I will deliberately avoid it and never dig a hole for myself. The biggest problem with hot data will cause failures caused by load imbalance (that is, data skew) in Reids clusters. These problems are fatal to Redis clusters.

First, let's talk about the main causes of Reids cluster load imbalance failure:

High-traffic Key, that is, hot key, according to past maintenance experience, a key visits more than 1000 QPS should be highly concerned, such as hot products, hot topics and so on.

Large Value, although some key access QPS is not high, but because the value is very large, resulting in a large load of network card, network card traffic is full, a single machine may have gigabit / s, IO failure.

Hot Key + big Value exists at the same time, server killer.

So what failures will be caused by a hot key or a large Value:

Data skew problem: large Value will cause uneven data distribution among different nodes in the cluster, resulting in data skew problem. A large number of requests with a very high read-write ratio will fall on the same redis server, and the load of the redis will be seriously increased and easy to hang up.

QPS tilt: the QPS on the slice is uneven.

A large Value can cause insufficient buffers on the Redis server and cause get timeouts.

Because the Value is too large, the traffic of the network card in the computer room is insufficient.

The knock-on effect of the failure of Redis cache leads to the breakdown of the database layer.

Interviewer: how do you accurately locate the hot data issues in a real project?

Answer: the solution to this problem is relatively broad. To specifically look at different business scenarios, for example, if the company organizes promotional activities, there must be a way to count the goods participating in the promotion in advance, and this kind of scenario can be estimated through the prediction method. For emergencies and uncertainties, Redis will monitor the hot data on its own. It can be summarized as follows:

Know the method in advance:

According to the business, human flesh statistics or system statistics may become hot data, such as promotional goods, hot topics, holiday topics, anniversary activities and so on.

Redis client collection method:

The caller counts the number of key requests by counting, but can not predict the number of key, so the code is intrusive.

Public Connection sendCommand (final ProtocolCommand cmd, final byte []... Args) {/ / get key String key = analysis (args) from parameters; / / count counterKey (key); / / ignore}

Redis Cluster Agent layer Statistics:

Agent-based Redis distributed architecture such as Twemproxy,codis, with a unified entrance, can collect and report at the Proxy layer, but the disadvantage is obvious that not all Redis cluster architectures have proxy.

Redis server collects:

Monitoring the QPS of a single fragment of Redis, it is found that the node where the QPS is tilted to a certain degree carries on the monitor to obtain the hot key. Redis provides the monitor command, which can count all the commands on a Redis node over a period of time and analyze the hot key. Under the condition of high concurrency, there will be hidden dangers of memory surge and Redis performance, so this method is suitable to be used in a short time. Similarly, you can only count the hotspot key of one Redis node. For the cluster, it is a little more troublesome from a business point of view.

The above four methods are now more commonly used in the industry, methods, I have a new idea by learning Redis source code. Type 5: modify the Redis source code.

Modify the Redis source code: (ideas from reading the source code)

I find that Redis4.0 brings us many new features, including the hot key discovery mechanism based on LFU. With this new feature, we can realize the statistics of hot key on this basis. This is just my personal idea.

Interviewer psychology: the young man is quite thoughtful, the mind is very open, but also played the idea of modifying the source code, I do not have this ambition. That's what the team needs.

(finding problems, analyzing problems, solving problems, without waiting for the interviewer to ask questions, directly talking about how to solve hot data problems, this is the core content)

3. How to solve hot data problems

A: on how to manage hot data problems, the solution to this problem is mainly from two aspects: the first is data fragmentation, which allows the pressure to be shared among multiple shards in the cluster to prevent a single machine from hanging up, and the second is migration isolation.

Summary:

Key split:

If the type of the current key is a secondary data structure, such as a hash type. If there are a large number of hash elements, you can consider splitting the current hash so that the hot spot key can be split into several new key and distributed on different Redis nodes, thus reducing the pressure

Migration hotspot key:

Take Redis Cluster as an example, the slot where the hotspot key resides can be migrated to a new Redis node separately, so that even if the hotspot key has a high QPS, it will not affect other businesses of the entire cluster, and it can also be customized, and the hotspot key can be automatically migrated to independent nodes. This solution also has more replicas.

Hot spot key current restriction:

For the read command, we can migrate the hotspot key and then add the slave node, and for the write command, we can limit the flow by targeting this hotspot key alone.

Increase the local cache:

For businesses where data consistency is not so high, hot key can be cached in the local cache of the business machine, because it is in the local memory of the business side, eliminating a remote IO call. However, when the data is updated, it may cause inconsistencies between the business and Redis data.

Interviewer: you gave a good answer and considered it very carefully.

4. Interviewer: with regard to the last question about Redis, Redis supports rich data types, so how to solve the large Value stored in these data types? is this the case online?

Problem analysis: compared with the hot key concept, the concept of large Value is better understood. Because Redis runs in a single thread, if the value of one operation is very large, it will have a negative impact on the response time of the entire redis, because Redis is a Key-Value structure database, and a large value takes up more memory than a single value, and the most direct impact on the Redis cluster is data skew.

A: (trying to baffle me? I came prepared. )

Let me first talk about how big the Value is, which can be divided into the following according to the experience values given by the company infrastructure:

Note: (the experience value is not the standard, but is summed up according to the long-term observation of online case by cluster operation and maintenance personnel)

Large: the number of elements in collection data types such as string type value > 10K, list, hash, zset and so on is more than 1000.

Super large: the number of elements in collection data types such as string type value > 100K, list, hash, zset and so on is more than 10000.

Since Redis runs in a single thread, if the value of a single operation has a negative impact on the response time of the entire redis, it can be split if it can be done in business. Here are some typical split schemes:

A larger key-value is split into several key-value to spread the operating pressure evenly among multiple redis instances, reducing the IO impact on a single redis.

Store several split key-value in a hash, each field represents a specific attribute, use hget,hmget to get part of the value, and use hset,hmset to update some properties.

Too many elements stored in hash, set, zset, list

Similar to the first practice in scenario 1, you can split these elements.

Take hash as an example, the original normal access process is:

Hget (hashKey, field); hset (hashKey, field, value)

Now, fix the number of buckets, such as 10000. For each access, first calculate the hash value of the field locally, divide by 10000, and determine which key the field falls on. The core idea is to break up the value and only get what you need at a time.

NewHashKey = hashKey + (hash (field)% 10000); hset (newHashKey, field, value); hget (newHashKey, field) so far, the study on "how to solve Redis hot data problems" is over, hoping to solve everyone's 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.