What are the basic knowledge points of Java MQ message queue?

Cache Avalanche

Let’s first look at what this normal caching process looks like? As shown in the figure below:

You can see that first the user accesses this something, and then this something accesses Redis. If Redis has the access data, it will Directly returns the data obtained from the cache; if the data is not found in the Redis cache, it will be queried in the MySql database. If there is a result, the data found from MySql will be synchronized to the Redis cache, and the query will be The result is returned.

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

First of all, let me give you an example. During Double Eleven, when you buy something in Dongdong, you enter its homepage. Since it is Double Eleven, the number of visits to the homepage is very large, so the homepage A lot of data is cached in redis.

Assume that the homepage data is stored in 100 keys in redis, and the cache expiration time is set to two hours. During Double Eleven, after shopping for more than two hours, the redis cache of the homepage data is here All will fail in an instant, causing all requests to be hit to the MySql database. At this time, the access pressure of the database increases, causing the MySql database to fail to respond in time and hang up. As a result, the homepage of Dongdong cannot continue to provide external services. , and then Brother Dong became very unhappy and sent the technical person in charge of this time to Africa.

So through this example, let’s look at the following picture:

That is to say, when the user accesses something, a large number of keys in redis are invalid, resulting in This Dong directly accesses the database and sends a large number of requests to the database. This phenomenon is Cache Avalanche. To put it simply, a large number of redis caches are invalidated at the same time, just like this avalanche is coming.

So what are the solutions to caching avalanche? Let’s talk about it below:

• # Set the expiration time of this cache to prevent a large number of keys from invalidating at the same time. That is, when setting up this cache, you can set the expiration time of the key. Time is spread out .

• We deploy redis generally in a cluster. We can put the keys of these hot spots on different nodes so that the keys of these hot spots are evenly distributed on different redis nodes. superior.

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

Cache Penetration

Next, let’s introduce what cache penetration is.

Let’s give an example: For example, a certain old man developed a website, and then the website became very popular. One day, it was suddenly attacked by hackers crazily. His attack method was to use this cache tunnel. The principle of transparency.

Everyone knows that usually, the primary key of the database increases from 0, and there are no negative numbers. So this hacker took advantage of this and continued to send requests with parameters with an ID less than zero. This guy initially put all the data of the website into the redis cache, but the hacker used a number with an ID less than zero to request it. There is no data with an ID less than zero in the redis cache, so redis cannot find this. As a result, once redis cannot find the result, it will check it in the database, then all requests will be hit to the database, and will always be hit to the database, because the redis cache layer cannot intercept such data at all.

The redis cache is directly penetrated by this kind of data, directly penetrating into the database. Similarly, let’s look at the following picture:

First, the malicious user accesses something and requests the data with id=-1, and then the data with id=-1 is If it was not found in the redis cache, I went to the database to query it. The data was not found, so I could only return empty data to the front end.

This malicious user (hacker) uses a script to continuously send this data to request, directly penetrating redis and hitting the database. This is the so-called cache penetration. To put it simply, cache penetration means that there is no such data in the cache or database. Generally, this situation is not accessed by normal users.

Then the solution for cache penetration is as follows:

• If the request penetrates redis and goes directly to the database, then no matter what result is found in the database , are written back to the redis cache, so that the next time a request is sent with the same parameters, it will be directly intercepted by the redis cache and will not be hit to the database.

• Verify the validity of the requested parameters.

• A more direct, simple and crude method is to blacklist this IP.

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

Cache breakdown

Let’s talk about the last issue, which is cache breakdown.

Let’s take Double Eleven as an example: During Double Eleven, Brother Dong announced that he wanted to hold a big event, and said that he wanted to auction the computer he used 20 years ago, and there were a lot of people. I was interested in this computer, so Dong Ge decided to auction the computer at 9 o'clock on Double Eleven. Then Dong's development programmer put the computer data into the redis cache, which corresponds to a key in the redis cache.

During the auction, everyone was very enthusiastic. The auction lasted for nearly three hours. The online auction has not ended yet, but the expiration time of the redis cache key corresponding to this computer is three and a half days. Hour. When everyone was auctioning for three and a half hours, the cache key of this computer suddenly became invalid. As a result, the large number of auction requests could not find the data in redis, so these large number of requests were directly hit to the database. At this time, the database The instantaneous pressure increases, causing the system to fail to respond in time and hang up.
At this time, Brother Dong was a little angry when he saw that his computer had not been auctioned yet, so he sent the programmer to Africa.

Similarly, let’s look at the following picture:

#The user visits a certain website, and then goes to redis to request an auction flash sale product. There is no invalidation in the cache. At this time, redis can return the result of the queried cache key, but when the cache key becomes invalid, the request will penetrate the redis and hit the database directly.

What everyone should pay attention to here is that this is the key of a certain hotspot. A large number of user requests continue to access the key of this hotspot. When the key of this hotspot suddenly fails, all requests will be blocked. To the database, this process is called cache breakdown. Remember it is the key to penetrate a very hot spot.

Then the solution to this cache breakdown is:

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

• Use distributed locks. If it is a single application, use mutex locks (distributed locks will be discussed in subsequent articles).

The above is the detailed content of What are the basic knowledge points of Java MQ message queue?. For more information, please follow other related articles on the PHP Chinese website!