This is the third day of my participation in Gwen Challenge. This article is participating in “Java Theme Month – Java Development in Action”, see the activity link for details.
background
System stability has been pursued by the all corporate r&d personnel, when the system problem, this time can log, system monitoring and performance indicators to undergo screening, but the complexity of the system, distributed, lead to the accumulation of a lot of information such as high concurrency, this time, may be for staff, is a very headache thing. Messaging middleware, or MQ for short, was invented to do many things: for example, reduce frequent business interactions through MQ in complex businesses. With high concurrency, transactions that do not need to be processed in a timely manner can be assigned to MQ. In the process of transaction, there are a lot of transaction processing, if the state of long link and lock is maintained for a long time, it is likely to cause lock table, lock library, deadlock. At this time also need MQ to carry on the message buffer, asynchronous, to ensure the stability of the system, continue to go on. It does not increase CPU and memory consumption due to long cycles such as deadlocks, thus avoiding service hang-ups and outages.
MQ in all its forms
In fact, there are more and more kinds of messaging middleware: RabbitMQ, RocketMQ, Kafka, and so on. Here is a table showing the various MQ features:
At this point, you might say that there is another type of middleware: Redis. Indeed, Redis is also a type of middleware that is commonly used as cache middleware. Cache some information, so that data information sharing, can also use it to achieve distributed lock, such as the realization of second kill, grab a single and other functions. It is also used as a cache for some order information to prevent a large number of order information from being backlogged and causing a high load on the server. In summary, Redis is often used as a buffer.
In addition to the above mentioned, message-oriented middleware can also be used to grab red packets, transaction system billing records, process push, notifications, etc. As a cache processor, Redis greatly improves the performance and efficiency of applications, especially in the level of data query, and greatly reduces the frequency of database query. However, this also brings some problems, among which the typical ones are: cache penetration, cache breakdown, cache avalanche.
What is cache penetration?
Let’s take a look at the cache query process first: when the front end sends a request to query data, the back end will first query in the cache Redis. If the data is queried, it will be directly returned to the front end, and the process ends. If no data is found in the cache, the system searches for the data in the database. In this case, the data is returned to the front end and inserted into the cache. There is also the possibility that a query to the database will return NULL if no data is found. In this case, if the user repeatedly makes requests and maliciously provides information that does not exist in the database, the data queried in the database will always be NULL. This kind of data will not be stuffed into the cache, this kind of data will always be accessed from the database, that is, malicious attack, it is likely to cause great pressure on the database, make the database cry. This process is called cache penetration. The cache is always directly penetrated to access the database.
The solution
Currently, the typical solution for cache penetration is to return NULL to the front end when not found in a database query. At the same time, NULL is inserted into the cache and the corresponding Key is set to expire. This kind of treatment is more commonly used in e-commerce.
What is cache breakdown?
Cache breakdown refers to that a Key in the cache is constantly and frequently requested. When the Key fails at a certain point, continuous high concurrent requests will break through the cache and directly request the database, resulting in a sharp increase in the pressure on the database at that moment. It’s like dripping water through a stone.
The solution
Since this key can be accessed and requested repeatedly, it can be valid for 10,000 years, so that high concurrency requests never fall on the database layer.
What is cache avalanche?
Cache avalanche refers to the failure of cache keys at a certain moment, which leads to a large number of query requests falling on the database layer, resulting in high database load, or even collapse of the database.
The solution
An avalanche occurs when a large number of keys fail at the same time. To avoid this, different and random expiration times are set for keys to stagger key expiration points in the cache, thereby reducing database stress.