content
(3) Set the accessible list (whitelist):
Cache breakdown (too much query volume, cache expired)
(2) Current limiting degradation
The mainstream implementation of distributed locks:
1. Implement distributed lock based on database
2. Based on cache (Redis, etc.)
Each distributed locking solution has its own advantages and disadvantages:
1. Performance: redis is the highest
2. Reliability: zookeeper is the highest here
Implementing distributed locks based on redis
1. Use setnx to lock and release the lock through del
2. The lock has not been released, and the key expiration time is set to be released automatically
3. An exception suddenly occurs after locking, and the expiration time cannot be set
Problem: Accidental deletion of locks
uuid prevents accidental deletion
Cache penetration (not found)
concept
The concept of cache penetration is very simple. The user wants to query a piece of data and finds that the redis in-memory database is not available, that is, the cache is not hit, so he queries the persistent layer database. It is not found, so this query fails. When there are many users, the cache is not hit, so they all request the persistence layer database. This will put a lot of pressure on the persistence layer database, which is equivalent to cache penetration.
solution
(1) Bloom filter
How does the bloom filter solve cache penetration in redis? Bloom filter is a data structure. It is very simple. First of all, it stores all possible query parameters in hash form. When the user wants to query, they use the Bloom filter to find that they are not in the collection, and they will be discarded directly. Persistence layer query.
(2) Cache empty objects
When the storage layer misses, even the returned empty object will be cached, and an expiration time will be set at the same time, and later access to the data will be obtained from the cache, protecting the back-end data source;
But there are two problems with this approach:
1. 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;
2. Even if the expiration time is set for the null value, there will still be inconsistencies between the data of the cache layer and the storage layer for a period of time, which will affect the business that needs to maintain consistency.
(3) Set the accessible list (whitelist):
Use the bitmaps type to define a list that can be accessed. The list id is used as the offset of the bitmaps. Each access is compared with the id in the bitmap. If the access id is not in the bitmaps, it will be intercepted and the access will not be allowed.
(4) Real-time monitoring:
When it is found that the hit rate of Redis begins to decrease rapidly, it is necessary to check the access objects and data to be accessed. In cooperation with the operation and maintenance personnel, a blacklist can be set to limit the service.
Cache breakdown (too much query volume, cache expired)
Overview
It is necessary to pay attention to the difference between cache breakdown and cache breakdown. Cache breakdown refers to a key that is very hot, and is constantly carrying large concurrency and large concurrency to access this point. When the key expires, it continues to Large concurrency breaks through the cache and requests the database directly, just like opening a hole in a barrier.
For example, in the hot search ranking, a large number of hot news accessed at the same time may lead to cache breakdown.
Cache breakdown means that there is no data in the cache but there is data in the database (usually the cache time expires). At this time, due to the large number of concurrent users, the data is not read in the cache at the same time, and the data is retrieved from the database at the same time, causing database pressure. Instantaneous increase, causing excessive pressure.
solution
1. Set hotspot data to never expire
In this way, the hotspot data will not expire, but when the Redis memory space is full, some data will be cleaned up, and this solution will take up space. Once there are more hotspot data, it will take up part of the space.
2. Add mutex lock (distributed lock)
Before accessing the key, use SETNX (set if not exists) to set another short-term key to lock the access of the current key, and delete the short-term key after the access ends. It is guaranteed that only one thread accesses it at a time. This requires very high locks.
Cache Avalanche
concept
A cache avalanche means that there is an error in the cache layer and it does not work properly. Therefore, all requests will reach the storage layer, and the call volume of the storage layer will increase sharply, resulting in the situation that the storage layer will also hang.
solution
(1) Redis high availability
The implication of this idea is that since redis may fail, I will add a few more redis, so that after one fails, the others can continue to work, which is actually a cluster.
(2) Current limiting degradation
The idea of this solution is to control the number of threads that read the database and write the cache by adding locks or queues after the cache is invalidated. For example, only one thread is allowed to query the data and write the cache for a certain key, and other threads wait.
(3) Data preheating
The meaning of data heating is that before formal deployment, I first access possible data in advance, so that some of the data that may be accessed in large quantities will be loaded into the cache. Before large concurrent access is about to occur, manually trigger the loading of different keys in the cache, and set different expiration times to make the time point of cache invalidation as uniform as possible.
Distributed lock
Problem Description
With the needs of business development, after the original single-machine deployment system is evolved into a distributed cluster system, because the distributed system is multi-threaded, multi-process and distributed on different machines, this will make the concurrency control lock in the original single-machine deployment situation. The strategy is invalid, and the pure Java API cannot provide the ability of distributed locks. In order to solve this problem, a cross-JVM mutual exclusion mechanism is needed to control the access to shared resources , which is the problem to be solved by distributed locks !
The mainstream implementation of distributed locks:
1. Implement distributed lock based on database
2. Based on cache (Redis, etc.)
3. Based on Zookeeper
Each distributed locking solution has its own advantages and disadvantages:
1. Performance: redis is the highest
2. Reliability: zookeeper is the highest here
Implementing distributed locks based on redis
1. Use setnx to lock and release the lock through del
127.0.0.1:6379> setnx k1 10
(integer) 1
127.0.0.1:6379> setnx k1 20
(integer) 0
127.0.0.1:6379> del k1
(integer) 12. The lock has not been released, and the key expiration time is set to be released automatically
127.0.0.1:6379> setnx users 20
(integer) 1
127.0.0.1:6379> expire users 20
(integer) 1
127.0.0.1:6379> ttl users
(integer) 163. An exception suddenly occurs after locking, and the expiration time cannot be set
You can set the expiration time at the same time when locking (atomic operation)
127.0.0.1:6379> set k2 15 nx ex 12 # nx 设置锁 ex 设置过期时间
OK
127.0.0.1:6379> ttl k2
(integer) 10Problem: Accidental deletion of locks
uuid prevents accidental deletion
Guaranteed atomicity
Using LUA scripts
LUA scripts are similar to redis transactions, which have certain atomicity and will not be queued by other commands , and can complete some redis transactional operations.