Redis's self-summary

1. Cache penetration

2. Cache avalanche

3. Cache breakdown

Redis implements distributed locks

In order to prevent us from being abnormal when we execute the business or the server is down accidentally, we do not delete the lock and cause us to deadlock, then we need to add an expiration time before executing the business.
The lock and our expiration time cannot be executed separately to ensure that it is atomic.

The lock deleted here may not be our own lock, so when we add the lock, we must put a uuid to ensure that it is our own lock. Then we take it out and judge that it is our own lock. These two operations are not atomic, so we need to use the lua script.

Delete lock

Using Redisson to implement distributed locks

He can simplify our previous logic and make it more powerful.

1. Will automatically renew our locks and automatically add 30s by default
2. Don’t worry about the problem of unlocking.
   
   We generally need to manually specify the expiration time, otherwise the complicated internal extension strategy is time-consuming.

Read-write lock

Use Redisson

1. Add dependencies

<dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.14.1</version>
</dependency>

2. Configuration

@Configuration
public class RedissonConfig {
    
    

    @Bean(destroyMethod = "shutdown")
    public RedissonClient redisson() {
    
    
        // 1. Create config object
        Config config = new Config();
        config.useSingleServer().setAddress("redis://39.96.41.98:6379");
        return Redisson.create(config);
    }
}

Redis data consistency