Article directory
The use of Redis cache greatly improves the performance and efficiency of applications, especially in data query. But at the same time, it also brings some problems. Among them, the most critical problem is the consistency of data. Strictly speaking, there is no solution to this problem. If the requirements for data consistency are high, caching cannot be used. Some other typical problems are cache penetration , cache avalanche , and cache breakdown . At present, the industry also has more popular solutions.
cache penetration
Here is the logic of daily cache usage:
To query a piece of data, first query it in the cache.
Returns if present in the cache.
If it does not exist in the cache, query to the database.
If it exists in the database, the data is returned and stored in the cache.
Returns null if it does not exist in the database.
concept
The situation of cache penetration is that neither the database nor the Redis cache, that is, illegal query, so that the cache cannot be intercepted, and the value cannot be stored in the cache if it cannot be found in the database, so that every time such a query will go to the database, which is equivalent to direct access Yes, that is, penetration, which will put a lot of pressure on the database.
solution
1. Bloom filter
Bloom filter is a data structure that stores all possible query parameters in the form of hash, and checks them at the control layer first, and discards if they do not match, thus avoiding the query pressure on the underlying storage system.
2. Filter illegal queries
Filter illegal queries or requests in the background service to prevent them from reaching the Redis service and database.
3. Cache empty objects
When the storage layer misses, even if the returned empty object is cached, an expiration time will be set at the same time, and the data will be obtained from the cache when accessing it later, protecting the back-end data source.
But this approach has two problems:
- If null values can be cached, it means that the cache needs more space to store more keys, because there may be many keys with null values.
- Even if the expiration time is set for the null value, there will still be inconsistencies between the data in the cache layer and the storage layer for a period of time, which will affect the business that needs to maintain consistency.
cache breakdown
concept
Cache breakdown means that a key is very hot, and it is constantly carrying large concurrency, and the large concurrency concentrates on accessing this point. When the key expires at the moment, the continuous large concurrency will break through the cache and directly request the database, just like digging a hole in a barrier. When a key expires, there are a large number of concurrent access requests, and this type of data is generally hot data. Due to the expiration of the cache, the database will be accessed at the same time to query the latest data, and the cache will be written back, which will cause the database to be overloaded instantly.
solution
1. Set the hotspot data to never expire
From the perspective of caching, there is no expiration time set, so there will be no problems caused by hot key expiration.
2. Add mutex (distributed lock)
Distributed locks: use distributed locks to ensure that only one thread queries the backend service for each key at the same time, and other threads do not have permission to obtain distributed locks, so they can only wait. This method transfers the pressure of high concurrency to distributed locks, so it is a great test for distributed locks.
cache avalanche
concept
Cache avalanche means that within a certain period of time, the cache set expires and becomes invalid. One of the reasons for the avalanche is that, for example, it will be 0:00 on Double Eleven soon, and there will be a wave of panic buying soon. This wave of commodity time is relatively concentrated and put into the cache, assuming that the cache is for one hour. Then at one o'clock in the morning, the cache of this batch of products will expire. The access queries for this batch of commodities all fall on the database, and for the database, there will be periodic pressure peaks. Therefore, all requests will reach the storage layer, and the number of calls to the storage layer will increase sharply, causing the storage layer to hang up.
In fact, concentrated expiration is not very fatal. The more fatal cache avalanche is that a node of the cache server is down or disconnected from the network. Because of the naturally formed cache avalanche, the cache must be created intensively in a certain period of time. At this time, the database can also withstand the pressure, which is nothing more than periodic pressure on the database. The downtime of the cache service node will cause unpredictable pressure on the database server, and it is very likely that the database will be crushed in an instant.
solution
1. Build a Redis high-availability cluster
To achieve high availability of Redis, since one service may hang up, add a few more services, so that after one hangs up, the others can continue to work, which is actually a cluster built.
2. Current limit downgrade
After the cache expires, the number of threads that read the database and write the cache is controlled by adding locks or queues. For example, only one thread is allowed to query data and write cache for a certain key, while other threads wait.
3. Data preheating, scattered expiration time
The meaning of data heating is to pre-access possible data before official deployment, so that some data that may be accessed in large quantities will be loaded into the cache. Manually trigger the loading of different keys in the cache before large concurrent accesses are about to occur, and set different expiration times to make the cache failure time as uniform as possible.
Reference source: [Mad God Talks about Java] The latest ultra-detailed tutorial of Redis is easy to understand