One ： Cache consistency

problem ： How to keep the data in the cache consistent with that in the database ？

1. Double write mode —— After the database is modified , Modify the data in the cache

1） shortcoming ： It's possible to generate dirty data . But it can guarantee the final consistency .
2） Solution ：

• Lock
• Temporary data inconsistency , Add expiration time to cached data

2. Failure mode —— Delete cache , Wait for the next active query to update

1） shortcoming ： Will read dirty data . The second is to write if it is slow , It will lead to the third reading , Read the dirty data written first
2） Solution ：

• Frequently modified data , Don't add cache , Put it directly into the database .

Two ： Cache consistency - Solution

1. Whether it's dual write mode or failure mode , Will cause cache inconsistencies . That is, if multiple instances are updated at the same time, something will happen . What do I do ？

• 1、 If it is user latitude data （ Order data 、 User data ）, This concurrency rate is very small , Don't think about it , Cache data plus Last expiration date , Trigger the active update of read at regular intervals
• 2、 If it's a menu , Basic data such as commodity introduction , You can also use canal subscribe binlog The way .
• 3、 Cache data + The expiration time is also sufficient to solve the cache requirements of most businesses .
• 4、 Ensure concurrent read and write by locking , Line up as you write . It doesn't matter to read . So it's suitable to use read-write lock .（ Business doesn't care Dirty data , Allow temporary dirty data to be ignored ）;

2. summary ：

• The data we can put into the cache should not be real-time 、 The requirement of consistency is very high . So when caching data, add expiration time , Protect Just get the latest data every day .
• We should not over design , Increase the complexity of the system
• When it comes to real-time 、 Data with high consistency requirements , You should check the database , Even if you slow down .

3. Get commodity service code

public Map<String, List<Catalog2Vo>> getCatalogJsonFromDbWithRedissonLock() {
    
        //1. Inject redisson, Acquire distributed lock . The name of the lock , The finer the granularity of the lock , The faster the speed. 
        // Lock granularity ： The specific cache is a certain data ,11 Item No 
        RLock lock = redisson.getLock("catalogJson-lock");
        lock.lock();
        Map<String, List<Catalog2Vo>> dataFromDb = null;
        try {
    
            dataFromDb = getDataFromDb();
        } catch (Exception e) {
    
            e.printStackTrace();
        } finally {
    
           // Release the lock 
            lock.unlock();
        }
        return dataFromDb;
    }

3、 ... and ： Cache consistency - solve -Canal

Canal： Alibaba open source middleware , It can simulate the slave server of a database .mysql Any change will pass binlog The binary log is synchronized to cannal,canal Will update redis The data in .

At present, the system is not used canal, Need extra maintenance .

Four ： Our system consistency solutions

1） All cached data must have expiration time , When the data is expired, the next query can trigger active update
2） Reading and writing data , Plus distributed read-write locks