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

This article mainly explains "what are the knowledge points of java mq message queue". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what are the knowledge points of java mq message queue"?

Cache avalanche

First of all, let's take a look at this normal caching process. As shown in the following figure:

As you can see, first, this user accesses this east, and then this certain east accesses the Redis. If the Redis has the access data, it will directly return the data obtained by the query cache; if the data is not found in the Redis cache, it will query the MySql database and find the result. Synchronize the data found in the MySql to the Redis cache, and return the result of this query.

This is a simple normal caching process. So based on this normal caching process, let's take a look at what a cache avalanche is.

First of all, let me give you an example, that is, during the Singles Day holiday, I bought something in something and entered its home page. Since it is Singles' Day, the visit volume of the home page is very large, so a lot of the data on the home page is cached in redis.

Suppose that the home page data is stored in 100 key in redis, and the cache expiration time is set to two hours. When during the Singles' Day holiday, after more than two hours of shopping, the redis cache of the home page data will all fail instantly, causing all requests to be called to the MySql database. At this time, the access pressure on the database increases, causing the MySql database to fail without timely response. As a result, the home page of a certain east could not continue to provide services to the outside world, and then brother Dong was very unhappy and sent the technical person in charge to Africa.

So through this example, let's take a look at the following picture:

That is to say, when a user accesses something, a large number of key in the redis becomes invalid, causing the owner to directly access the database and call a large number of requests to the database. This phenomenon is called cache avalanche. To put it simply, the redis cache fails a lot at the same time, just like this avalanche.

So how many solutions are there for caching avalanche? Let's talk about the following:

Set the expiration time of this cache so that a large number of key will not expire at the same time, that is, when setting this cache, you can spread the expiration time of key.

Our deployment of redis is generally deployed in a cluster, so we can put the key of these hot spots on different nodes, so that the key of these hot spots is evenly distributed on different redis nodes.

There is a more violent method, do not set the cache expiration time, so that key will never expire.

Cache penetration

Next, let's introduce what cache penetration is.

Or give an example: for example, a certain brother developed a website, and then the website was so popular that one day he was suddenly attacked by hackers crazily, and his attack method was based on the principle of cache penetration.

As we all know, usually, the primary key of the database is incremented from 0 and there is no negative number, so the hacker takes advantage of this and keeps sending requests with parameters with ID less than zero. At the beginning, this brother put all the data of the website into the redis cache, but the hacker made the request with a number whose ID is less than zero, and there is no data with an ID less than zero in the redis cache, so the redis cannot find the result. Once the redis cannot find the result, it will check in the database, then all requests will be called to the database and will be called all the way to the database. Because the redis cache layer can not intercept such data at all.

The redis cache is directly penetrated by this data, directly into the database. Also, let's take a look at the following picture:

First of all, the malicious user visits something and requests it with the data of id=-1. Then the data of the id=-1 is not found in the redis cache, so it is queried in the database, and the empty data can only be returned to the front end.

The malicious user (hacker) uses a script to constantly send this data request, directly through the redis to the database, this is the so-called cache penetration. To put it simply, cache traversal means that there is no such data in the cache and database, which is generally not accessed by normal users.

Then the solution to cache traversal is as follows:

If the request penetrates the redis and goes directly to the database, no matter what the database finds out, it will be written back to the redis cache, so that the next time the request is sent with the same parameter, it will be directly blocked by the redis cache and will not call back to the database.

Verify the validity of the requested parameters.

A more direct, simple and rough method to block this IP.

Finally, use the Bloom filter, which is a very good way.

Cache breakdown

Let's talk about the last problem, which is the breakdown of the cache.

Or take Singles Day as an example: during the Singles Day holiday, Brother Dong said that he wanted to engage in a big event, saying that he wanted to auction the computer he used 20 years ago, and then a lot of people were interested in the computer, so Dong decided to auction the computer at 9: 00 on Singles Day, and then some developer programmer put the computer data into the redis cache, which corresponds to a key in the redis cache.

At the time of the auction, everyone's enthusiasm was so high that the auction lasted for nearly three hours, and the online auction was not over yet, but the expiration time of the corresponding redis cache key on this computer was three and a half hours. When everyone auctioned for three and a half hours, the cache key of this computer suddenly expired, resulting in a large number of auction requests that could not find data in the redis, so that a large number of requests would be typed directly to the database. At this time, the pressure on the database increased instantly, resulting in an untimely response and hanging up.

At this time, Brother Dong was a little angry when he saw that his computer had not been auctioned off, so he sent the programmer to Africa.

Let's also take a look at the following picture:

Users visit something and then go to redis to request a certain auction. When the cache does not expire, redis can return the result of the cache key that is queried, but when the cache key fails, the request will break through the redis and call directly to the database.

What you notice here is that this is the key of a certain hot spot, and a large number of users request to access the key of this hot spot constantly. When the key of this hot spot suddenly expires, all the requests are sent to the database, this process is called cache breakdown. Remember that it breaks through a very hot key.

So the solution to this cache breakdown is:

Let the hotspot key not expire, that is, do not set the expiration time (not recommended).

Use distributed locks, or mutexes if it is a single application (which will be discussed later in distributed locks).

At this point, I believe you have a deeper understanding of "what are the knowledge points of java mq message queue?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.