Dark Horse Comments-07 Cache breakdown problem (hotspot key failure) and solution, mutex lock and setting logical expiration time

• Advantages: Build cache through asynchronous threads to avoid waiting for other threads and improve performance
• Disadvantages: Building an asynchronous thread business is complex, and requires maintaining an expire field, which requires additional memory consumption. Before the asynchronous thread completes building the cache, other threads return expired data (dirty data), resulting in data inconsistency.

Logical expiration application

Implement query store business based on store ID, and solve cache breakdown problem based on logical expiration method (hotspot key needs to be added in advance)

Step 1: Because the value of the data stored in redis now needs to have an expiration time attribute, you can create a new entity class containing the original data and expiration time fields (without invading the original code)

@Data
public class RedisData {<!-- -->
    // Expiration
    private LocalDateTime expireTime
    //Original data (use universal Object)
    private Object data;
}

Step 2: Add a new method in ShopServiceImpl, use unit testing to cache preheating i.e. add hotspot key, encapsulate hotspot store information and expiration time fields into RedisData objects and write them Redis cache

public void saveShop2Redis(Long id, Long expirSeconds) {<!-- -->
    // 1. Query store data in the database according to the store ID
    Shop shop = getById(id);
    // Since local query database is faster, simulate reconstruction delay
    Thread.sleep(200);
    // 2. Encapsulate the logical expiration time (convert the current time to seconds)
    RedisData redisData = new RedisData();
    //Set hot store information
    redisData.setData(shop);
    redisData.setExpireTime(LocalDateTime.now().plusSeconds(expirSeconds));
    // 3. Convert the RedisData object containing hot store information and logical expiration time fields into a JSON string and cache it to Redis
    stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
}

Step 3: Run the test method in the test class, and then go to the Redis graphical page to view the stored value (including the data field, that is, the shop object and the expireTime logical expiration time field)

@SpringBootTest
class HmDianPingApplicationTests {<!-- -->
    @Autowired
    private ShopServiceImpl shopService;
    @Test
    public void test(){<!-- -->
        shopService.saveShop2Redis(1L,1000L);
    }
}

{<!-- -->
    "data": {<!-- -->
        "area": "大关",
        "openHours": "10:00-22:00",
        "sold": 4215,
        "images": "https://qcloud.dpfile.com/pc/jiclIsCKmOI2arxKN1Uf0Hx3PucIJH8q0QSz-Z8llzcN56-IdNpm8K8sG4.jpg",
        "address": "No. 29, Jinchang Wenhua Court, Jinhua Road",
        "comments": 3035,
        "avgPrice": 80,
        "updateTime": 1666502007000,
        "score": 37,
        "createTime": 1640167839000,
        "name": "476 Tea Restaurant",
        "x": 120.149192,
        "y": 30.316078,
        "typeId": 1,
        "id": 1
    },
    "expireTime": 1666519036559
}

Step 4: Write the queryWithLogicalExpire method. In this method, if the store information is found, it returns null if the shop cannot be found. Finally, unify it in the queryById method. Determine and return the result class

//Declare a thread pool, because using logical expiration to solve cache breakdown requires a new thread to complete the reconstruction of the cache.
private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);

@Override
public Result queryById(Long id) {
    //Test using logical expiration to solve cache breakdown
    Shop shop = queryWithLogicalExpire(id);
    // If shop equals null, it means that the corresponding store does not exist in the database or the cached store information is an empty string.
    if (shop == null) {
        return Result.fail("The store does not exist!!");
    }
    // shop is not equal to null, return the queried merchant information to the front end
    return Result.ok(shop);
}

public Shop queryWithLogicalExpire(Long id) {
    //1. First query the corresponding hot store cache information (including expiration time) from Redis. The constant value here is the fixed store prefix + query store Id.
    String json = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);
    //2. If it is not hit, that is, json is equal to null, or if it is hit, but json is equal to the empty string, null will be returned directly (indicating that we have not imported the corresponding key)
    //"", null and "/t/n (line feed)" will all be judged as empty and return false
    if (StrUtil.isBlank(json)) {
        return null;
    }
    //3. If the hot store information is queried in Redis and it is not an empty string, convert the JSON string into a RedisData object
    RedisData redisData = JSONUtil.toBean(json, RedisData.class);
    //4. The essential type of redisData.getData() is JSONObject type (or JSON string) and not Object type object, so it cannot be directly converted to Shop type, and a tool class is required.
    Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);
    //5. Get the expiration time encapsulated in the RedisData object and determine whether it has expired.
    LocalDateTime expireTime = redisData.getExpireTime();
    if(expireTime.isAfter(LocalDateTime.now())) {
        // 5.1. Not expired, return store information directly
        return shop;
    }
    // 6. It has expired and needs to be cached again. Query the store information corresponding to the database and then write it to Redis and set the logical expiration time.
    // 6.1. Obtain mutex lock
    boolean isLock = tryLock(LOCK_SHOP_KEY + id);
    // 6.2. Determine whether the lock acquisition is successful
    if (isLock){
        // Check again whether the Redis cache has expired (double check). If it exists, there is no need to rebuild the cache.
        // If the store information cached in Redis is still expired, start an independent thread to implement cache reconstruction (you can sleep for 200ms during testing), and the actual logical expiration time of the cache is set to 30 minutes.
        CACHE_REBUILD_EXECUTOR.submit( ()->{// Start an independent thread
            try{
                this.saveShop2Redis(id,20L);
            }catch (Exception e){
                throw new RuntimeException(e);
            }finally {
                unlock(LOCK_SHOP_KEY + id);
            }
        });
    }
    // 6.4. Return expired store information
    return shop;
}

public void saveShop2Redis(Long id, Long expirSeconds) {<!-- -->
    // 1. Query store data in the database according to the store ID
    Shop shop = getById(id);
    // Since local query database is faster, simulate reconstruction delay
    Thread.sleep(200);
    // 2. Encapsulate the logical expiration time (convert the current time to seconds)
    RedisData redisData = new RedisData();
    //Set hot store information
    redisData.setData(shop);
    redisData.setExpireTime(LocalDateTime.now().plusSeconds(expirSeconds));
    // 3. Convert the RedisData object containing hot store information and logical expiration time fields into a JSON string and cache it to Redis
    stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData));
}

Test logic expiration to solve cache breakdown

Use Jmeter to test whether all threads will perform cache reconstruction or return old data when they cannot find the data. If the data is inconsistent when rebuilding the data, will the cache data in Redis be updated

• Use the saveShop2Redis method in the test class HmDianPingApplicationTests to add a cache of hot store information to Redis and set the logical expiration time to 2 seconds.
• Manually modify the information of this hot store in the MySQL database. After 2 seconds, the hot store data cached in Redis will logically expire and be inconsistent with the corresponding store information in the MySQL database.
• When users access expired cached data, they need to open a new thread to reconstruct the cached data. Before reconstruction, only dirty data (data before modification) can be obtained, and new data (data after modification) can be obtained after reconstruction. data)

Open 100 to access logical expired data

The users in the front can only see the dirty data, and the users in the back can see the new data