Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Redis Hot spot Key problem Discovery and what are the five Solutions

2025-02-14 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

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

This article is about Redis hot Key problems found and what are the five solutions, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article. Let's take a look at it with the editor.

There are two reasons for the emergence of hot issues:

1. The data of user consumption is much larger than that of production (hot-selling goods, hot news, hot comments, star live broadcast).

In some unexpected events in daily work and life, such as the price reduction and promotion of some popular goods during the Singles' Day holiday, when one of the items is viewed or purchased tens of thousands of times, a large demand will be formed. in this case, it will cause hot issues.

2. Request sharding set, which exceeds the performance limit of a single Server.

When the server reads data for access, the data is often sliced and segmented. In this process, the corresponding Key is accessed on a host Server. When the access exceeds the Server limit, it will lead to hot Key problems.

The harm of hot issues

1. The traffic is concentrated, reaching the upper limit of the physical Nic.

2. If there are too many requests, the cache sharding service is destroyed.

3. DB breakdown, causing business avalanche.

As mentioned earlier, when the request of a hot Key exceeds the upper limit of the host network card on a certain host, due to the excessive concentration of traffic, other services in the server will be unable to carry out.

If the hot spot is too concentrated and the cache of the hot spot Key is too much, it will lead to the collapse of the cache sharding service when it exceeds the current cache capacity.

When the cache service crashes, another request is generated and cached to the backend DB. Due to the weak performance of DB itself, request penetration is easy to occur in the face of large requests, which will further lead to avalanche phenomenon and seriously affect the performance of the device.

Solution

The usual solutions are mainly focused on the corresponding transformation of the client and the Server side.

1. Server cache scheme

First, Client sends the request to Server, and Server is a multi-threaded service, so there is a cache space based on Cache LRU policy locally.

When the Server itself is congested, Server does not send the request further to the DB but returns directly, only when the Server itself is unblocked will the Client request be sent to the DB and the data will be rewritten to the cache.

At this point, the access and reconstruction of the cache are completed.

However, the scheme also has the following problems:

1. Cache invalidation, multi-thread construction cache problem

2. Cache loss and cache construction problem

3. Dirty reading

2. Use Memcache and Redis schemes

This scheme solves the hot Key problem by deploying cache separately on the client side.

In the process of use, Client first visits the service layer, and then accesses the cache layer on the same host.

This solution has the advantages of nearby access, high speed and no bandwidth limitation, but it also has the following problems.

1. Waste of memory resources

2. Dirty reading

3. Use the local cache scheme

Using local caching has the following problems:

1. Need to know the hot spots in advance

2. Limited cache capacity

3. Inconsistent time growth

4. Hot spot Key omission

There are all kinds of problems in traditional hot spot solutions, so how to solve them?

4. Read-write separation solution for hot reading

The roles of each node in the architecture are as follows:

1. Load balancing at SLB layer

2. Automatic routing for read-write separation in Proxy layer

3. Master is responsible for writing requests.

4. The ReadOnly node is responsible for reading the request

5. Slave nodes and Master nodes are highly available

In the actual process, Client sends the request to SLB,SLB and distributes it to multiple Proxy, and then classifies and sends the request through the identification of Proxy.

For example, a request that is also a Write is sent to the Master module, and a request for Read is sent to the ReadOnly module.

The read-only nodes in the module can be further expanded to effectively solve the problem of hot reading.

At the same time, read-write separation has the advantages of flexible expansion of read hot spots, storage of a large number of hot Key, client-friendly and so on.

5. Hot data solution

This scheme solves the problem of hot Key by actively discovering hot spots and storing them.

First, Client also accesses SLB and distributes various requests to Proxy through SLB, and Proxy forwards the request to the back-end Redis in a route-based manner.

The hot key is solved by adding cache on the server side.

Specifically, the local cache is added on the Proxy, the local cache uses the LRU algorithm to cache the hot spot data, and the back-end db node adds the hot spot data calculation module to return the hot spot data.

The main advantages of Proxy architecture are as follows:

1. Proxy local cache hotspot, and the read capacity can be expanded horizontally.

2. DB node timing calculation hotspot data set

3. DB feedback Proxy hotspot data

4. Completely transparent to the client, without any compatibility

Hot spot key processing

Reading of hot spot data

The processing of hot Key is mainly divided into two forms: writing and reading. In the process of data writing, when SLB receives data K1 and writes it to a Redis through a certain Proxy, it completes the data writing.

If K1 becomes a hotspot key after the calculation of the backend hotspot module, Proxy will cache the hotspot, and the next time the client accesses K1, it can not go through Redis.

Finally, because proxy can be expanded horizontally, the access ability of hot spot data can be enhanced arbitrarily.

Discovery of hot spot data

For the discovery of hot spot data on db, first of all, the request statistics of Key will be carried out in a cycle. After reaching the request level, the hot spot Key will be located, and all hot spot Key will be put into a small LRU linked list. When accessing through Proxy request, if Redis finds that the point to be visited is a hot spot, it will enter a feedback stage and mark the data at the same time.

When DB computing is hot, the main methods and advantages are:

1. Hot spot statistics based on statistical threshold.

2. Hot spot statistics based on statistical cycle

3. The statistical method of initial value without reset based on version number.

4. DB computing has the advantages of minimal impact on performance, extremely small memory footprint and so on.

Scheme comparison

Through the above comparative analysis, we can see that there is a great improvement in solving hot Key compared with traditional methods. No matter it is based on read-write separation scheme or hot data solution, it can be flexibly expanded in the actual processing environment, transparent to the client, and has certain data inconsistency.

In addition, the read-write separation mode can store more hot data, while the Proxy-based mode has a cost advantage.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report