Redis learning 5 - high concurrency distributed lock practice

I'm learning Redis When using distributed locks , We are bound to encounter some problems in actual development . Some records were made

One ： Cache penetration

Cache penetration refers to querying a data that doesn't exist at all , Neither the cache tier nor the storage tier will hit , Usually for the sake of fault tolerance , If the data cannot be found from the storage layer, it will not be written to the cache layer .
Cache penetration will cause non-existent data to be queried in the storage layer every time it is requested , Lost the significance of cache protection back-end storage .
The solution is as follows ： Cache an empty object

 public String  getCacheThrough(String key){
    
        String cacheValue = (String) redisTemplate.opsForValue().get(key);
        if(null == cacheValue){
    
            //  Get... From the database 
            String  dbValue =  getDbValue(key);
            redisTemplate.opsForValue().set(key,dbValue);
            //  If there's no database , Just set up a key The expiration date is 300 Of a second 
            if(dbValue == null){
    
                redisTemplate.expire(key,60 * 5, TimeUnit.SECONDS);
            }
            return  dbValue;
        }
        return cacheValue;
    }

Two ： Cache invalidation

Because a large number of caches fail at the same time, a large number of requests may penetrate the cache and reach the database at the same time , It may cause the database to be under too much pressure and even hang up , In this case, we'd better set the cache time of this batch of data to different times in a time period when adding in batch .

    public String getCacheBreakDown(String key){
    
        //  Get data from cache summary 
        String cacheValue = (String) redisTemplate.opsForValue().get(key);
        if(null == cacheValue){
    
            //  Get... From storage 
            String dbValue = getDbValue(key);
            int expireTime =  new Random().nextInt(300)+300;
            //  Set a random expiration time 
            redisTemplate.opsForValue().set(key,dbValue,expireTime,TimeUnit.SECONDS);
            return  dbValue;
        }

        return  cacheValue;
    }

3、 ... and ： hotspot Redis key The reconstruction

• At present key It's a hot spot key（ For example, a popular entertainment news ）, The amount of concurrency is very large .
• Rebuilding the cache cannot be done in a short time , It could be a complex calculation , For example, complicated SQL、 many times IO、 Multiple dependencies, etc .

In the moment of cache failure , There are a lot of threads to rebuild the cache , Cause the back-end load to increase , It might even crash the app .
To solve this problem is to avoid a large number of threads rebuilding cache at the same time .

 public String getCacheHot(String key){
    
        String cacheVale =(String) redisTemplate.opsForValue().get(key);
        //  If value  by  null , Start refactoring the cache 
        if(null == cacheVale){
    
            //  Add distributed lock to solve the problem of concurrent reconstruction of hotspot cache 
            String muteNxKey = "mutex:key:"+key;
            RLock hotCreateCacheLock = redisson.getLock(muteNxKey);
             hotCreateCacheLock.lock();
             try{
    
                 String dbValue = getDbValue(key);
                 redisTemplate.opsForValue().set(key,dbValue,5*60,TimeUnit.SECONDS);
                 return  dbValue;
             }finally {
    
                 hotCreateCacheLock.unlock();
             }
        }
        return cacheVale;
    }

Four ： Cache and database write inconsistency

This is a common situation , When we insert data into a process, it has not been processed yet , Another thread reads the data into the cache .

• Write about ： Two threads write
• Reading and writing ： A thread reads , A thread writes
  
  
  1. Use distributed locks to solve

    public String  updateCacheDoubleWrite1(String key){
    
        RLock updateValeLock = redisson.getLock(key);
        updateValeLock.lock();
        String dbVale = null;
        try{
    
             dbVale = updateValue(key);
             redisTemplate.opsForValue().set(key,dbVale,getTimeout(),TimeUnit.SECONDS);
        }finally {
    
            updateValeLock.unlock();
        }
        return dbVale;
    }

2. Use Redis The read-write lock is solved , The bottom layer is Lua Script

    public String updateCacheDoubleWrite2(String key){
    
        RReadWriteLock updateWriteLock =  redisson.getReadWriteLock(key);
        RLock write =updateWriteLock.writeLock();
        write.lock();
        String dbVale = null;
        try {
    
            dbVale = updateValue(key);
            redisTemplate.opsForValue().set(key,dbVale,getTimeout(),TimeUnit.SECONDS);
        }finally {
    
            write.unlock();
        }
        return dbVale;
    }

5、 ... and ： Cache avalanche

Cache avalanche refers to cache failure or downtime , All traffic flows to the back-end database , Cause the whole system to hang up .
Prevent and solve buffer avalanche problem , Consider from the following aspects ;

• Ensure high availability of cache layer services , For example, use Redis Sentinel or Redis Cluster.
• The dependent isolation component fuses and demotes the back end current limiter . For example, use Sentinel or Hystrix Current limiting degraded components . Carry out relevant degradation of services .
• Before the project goes online , After the walkthrough cache layer goes down , Application and backend load and possible problems , On this basis On this basis, make some Plan Settings .