Seckill system 03 - redis cache and distributed lock

Seckill system 03—— Multi level cache

cache ：

Background problem description

Access the database to query product information ：

Read more and write less

Front end static page ：

In the first part, we staticize the data , There are also many problems , For example, if we have too many goods ,freemark The template must be modified , All our goods need to be re produced and static , This workload is really too much .

Introduce caching :

Caching :

Redis Cache practice ：

Join in Redis

/** *  Get product details   Join in redis * * @param id  product ID */
    public PmsProductParam getProductInfo2(Long id) {
    
        PmsProductParam productInfo = null;
        // From the cache Redis Look inside 
        productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
        if (null != productInfo) {
    
            return productInfo;
        }
        productInfo = portalProductDao.getProductInfo(id);
        System.out.println(" I was executed ");
        if (null == productInfo) {
    
            log.warn(" No product information was found ,id:" + id);
            return null;
        }
        checkFlash(id, productInfo);
        redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, productInfo, 3600, TimeUnit.SECONDS);
        return productInfo;
    }

The problem of the above scheme ： Data copy 、 Common problems of data caching

1、 The problem of data consistency , How to guarantee Redis and mysql The problem of data consistency

Jmeter 1000 Secondary request graph , throughput 630.5/sec

Two solutions for data consistency ：

1、 The final consistency plan ：

Set timeout to resolve . Set up Redis Timeout for caching data .Redis Be overdue , The next request must be from mysql In order to get

redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE+id,productInfo,360,TimeUnit.SECONDS);

2、 Real time consistency scheme ：

transaction canal binlog

Two questions ( High concurrency )

The problem of compression 、 Reduce memory

problem 1,Redis Cached objects are sometimes large ,Redis Only disk IO, There is no solution to the network IO problem . Network transmission IO Still big .

problem 2,Redis Data will occupy a lot of memory , Using expiration mechanism can relieve memory pressure .

The Internet I/O resolvent , Compress object content , Using serialization and compression

Stress test scenario

The current in jmeter Carry out inside 1000 Concurrent request items id=26, The results are as follows

As expected, only set once redis There are differences , Why is it like this ？

re: Because of the emergence of Concurrency issues .

When I visit again for the second time , There is no log output at this time , It means that all caches are gone

Concurrency issues ： Concurrent programming 》 Concurrency issues 》 It can be achieved by locking java Concurrent , But the way of locking （ Not suitable for Distributed scenarios ）

Why is locking not suitable for distributed scenarios ：

scene ： If there is 800 A request ,400 To access a server ,400 One to access another server .

Which is locked synchronized One of them can be guaranteed jvm Of 400 The first request is serial access .

But the order in which two servers access the database cannot be guaranteed , Whether it is cross process access .

Lock time 、 And the running time of the code block

resolvent ： Using distributed locks ：redis、zookeeper

zookeeper Strong certification , Suitable for distributed

Redis Distributed Combat

/* * zk Distributed lock  */
@Autowired
private ZKLock zkLock;
private String lockPath = "/load_db";

@Autowired
RedissonClient redission;

/** *  Get product details   Join in redis  Join the lock  * * @param id  product ID */
public PmsProductParam getProductInfo3(Long id) {
    
    PmsProductParam productInfo = null;
    // From the cache Redis Look inside 
    productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
    if (null != productInfo) {
    
        return productInfo;
    }
    RLock lock = redission.getLock(lockPath + id); // Gets a reentrant lock 
    try {
    
        if (lock.tryLock()) {
     // Get the lock - The same thread can re-enter 
            productInfo = portalProductDao.getProductInfo(id);
            if (null == productInfo) {
    
                log.warn(" No product information was found ,id:" + id);
                return null;
            }
            checkFlash(id, productInfo);
            redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, productInfo, 3600, TimeUnit.SECONDS);
        } else {
    
            productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
        }
    } finally {
    
        if (lock.isLocked()) {
    
            if (lock.isHeldByCurrentThread())
                lock.unlock();
        }
    }
    return productInfo;
}

ps: Definition of reentry lock and deflection lock

Reentrant lock , Reentrancy means, for example, that a thread acquires an object A The lock on the , If it requests a second time A Your lock must be available （ That is to say, I won't lock myself up ）, Reentrancy is what threads must meet , Otherwise, a lot of code will deadlock

Biased locking , Biased locking means that if a thread requests a lock that it has already obtained , It won't do it again lock and unlock, This improves performance .
How to achieve reentrant is the same , Is to write down the owner of the lock , When applying for a lock, check whether the lock has been occupied , If someone occupies the lock , See if it is the applicant himself .

You can see that it works Redis lock ,QPS Immediately improved a lot

---

Redis Self provided lock setnx, Use setnx Concurrent lock

Cache application scenario ：

1、 Large amount of visits 、QPS high 、 Businesses with low update frequency

2、 Data consistency requirements are not high

Redis The cache problem

Cache breakdown problem （ Hotspot data is single key）：

For some with expiration set key, If these key May be in Some points in time are accessed very concurrently , It's a very “ hotspot ” The data of . This is the time , A question needs to be considered ： The cache is “ breakdown ” The problem of , The difference between this and cache avalanche is that this is for a certain key cache , The former is a lot of key, Cache breakdown is for a key A period of time in which to visit .

Solution ：

1. Lock , When the cache misses , Avoid a large number of requests to access the database by locking . Through the lock

2. No expiration allowed . Physics doesn't expire , That is, do not set the expiration time . Instead, it updates data in the background asynchronously and regularly . The simplest rough situation

3. Second level cache .L1 Cache expiration time is short ,L2 Cache expiration time is long . Request priority from L1 Get data cache , If you miss , Lock it , Ensure that only one thread reads data from the database and then updates to L1 and L2 in . Then other threads are still L2 Get data cache . Second level cache , It's impossible to have two Redis Are punctured .

Cache penetration problem （ A malicious attack 、 Access nonexistent data ）：

Cache penetration refers to querying a certain nonexistent data , Because the cache is written passively on Miss , And for the sake of fault tolerance , If no data can be found from the storage tier, it will not be written to the cache , This will cause the non-existent data to be queried by the storage layer every time it is requested , It loses the meaning of caching . When the flow is large , Probably DB It's gone , If someone Take advantage of the nonexistent key Attack our applications frequently , This is the loophole .

Some people use nonexistent key Visit frequently , Cache penetration will occur

** Solution ：** There are many ways to effectively solve the problem of cache penetration

1、 The most common is the use of bloon filter , Hash all possible data to a large enough bitmap in , A certain nonexistent data will be bitmap Intercept , Thus, the query pressure on the underlying storage system is avoided . use The bloon filter

2、 There's also a simpler and rougher way （ This is what we use ）, If the data returned by a query is empty （ Whether the data doesn't exist , Or a system failure ）, We still cache this empty result , But its expiration time will be very short , Up to five minutes . Directly cache the empty node to Redis in .

Cache avalanche （ At the same time , There's a lot of concurrency ）：

Avalanche refers to the use of Same expiration time , Causes the cache to fail at the same time at a certain time , Forward all requests to DB,DB Avalanche with excessive instantaneous pressure .

a large number of Redis At the same time , All interfaces instantly access the database .

Solution ：

**1、** The avalanche effect of cache failure has a terrible impact on the underlying system . Most system designers consider locking or queuing to ensure single thread caching （ process ） Write , So as to avoid a large number of concurrent requests falling on the underlying storage system in case of failure . Here is a simple solution to spread the cache expiration time , For example, we can == A random value is added to the original failure time ==, such as 1-5 Minutes at random , In this way, the repetition rate of each cache expiration time will be reduced , It's hard to trigger a collective failure .

2、 In advance ： This solution is to implement the cache cluster before the avalanche High availability , If using Redis, have access to Master-slave + sentry ,Redis Cluster To avoid Redis The total collapse .

3、 In the matter ： Use Hystrix Carry out current limiting & Downgrade , For example, a second is coming 5000 A request , We can set the assumption that there is only one second 2000 Requests can go through this component , So the rest 3000 The request will follow the current limiting logic . Then we call our own downgrading component （ Downgrade ）, For example, set some default values . To protect the last MySQL Not killed by a lot of requests . Using current limiting & Downgrade

4、 After the event ： Turn on Redis Persistence mechanism , Recover the cache cluster as soon as possible . After the avalanche , Quickly recover files

Cache and database write consistency problem ：

Consistency problems are common distributed problems , It can also be divided into final consistency and strong consistency . Database and cache write , There are bound to be inconsistencies .

re: First understand a premise . If there is a strong consistency requirement for data , Can't cache .

Everything we do , Only final consistency can be guaranteed . in addition , What we have done is basically , It can only be said to reduce the probability of inconsistency , It is impossible to avoid . therefore , Data with strong consistency requirements , Can't cache .

Introduce distributed lock code ：

1、 introduce redis rely on

<!-- Join in redisson-->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.6.5</version>
</dependency>

@Bean
public RedissonClient redissonClient(){
    
    Config config = new Config();
    config.useSingleServer().setAddress("redis://tlshop.com:6379").setPassword("123456").setDatabase(1);
    return Redisson.create(config);
}

Lock the single machine ：

Distributed locking ：

The same data request comes at the same time , such as set 100 value：（1 2 3）

Use ZooKeeper Distributed lock practice

/** *  Get product details  * * @param id  product ID */
public PmsProductParam getProductInfo(Long id) {
    
    PmsProductParam productInfo = null;
    productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
    if (productInfo != null) {
    
        log.info("get redis productId:" + productInfo);
        return productInfo;
    }
    try {
    
        if (zkLock.lock(lockPath + "_" + id)) {
    
            productInfo = portalProductDao.getProductInfo(id);
            if (null == productInfo) {
    
                return null;
            }
            checkFlash(id, productInfo);
            log.info("set db productId:" + productInfo);
            // Cache expiration time is random 
            redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, productInfo, 3600, TimeUnit.SECONDS);
        } else {
    
            // problem ： Return to null
            productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
        }
    } finally {
    
        log.info("unlock :" + productInfo);
        zkLock.unlock(lockPath + "_" + id);
    }
    return productInfo;
}

private void checkFlash(Long id, PmsProductParam productInfo) {
    
    FlashPromotionParam promotion = flashPromotionProductDao.getFlashPromotion(id);
    if (!ObjectUtils.isEmpty(promotion)) {
    
        productInfo.setFlashPromotionCount(promotion.getRelation().get(0).getFlashPromotionCount());
        productInfo.setFlashPromotionLimit(promotion.getRelation().get(0).getFlashPromotionLimit());
        productInfo.setFlashPromotionPrice(promotion.getRelation().get(0).getFlashPromotionPrice());
        productInfo.setFlashPromotionRelationId(promotion.getRelation().get(0).getId());
        productInfo.setFlashPromotionEndDate(promotion.getEndDate());
        productInfo.setFlashPromotionStartDate(promotion.getStartDate());
        productInfo.setFlashPromotionStatus(promotion.getStatus());
    }

It is found that the distributed lock added under the high parallel can solve the problem just now , But it also reduces qps, So it still depends on the demand

Principle of distributed lock ：

zk chart

summary ：

1、 The thread will directly create the next temporary sequence node under a lock node

2、 If you're not the first node , Just add a node listener to yourself

3、 As long as the last node releases the lock , Go ahead by yourself , It is equivalent to a queuing mechanism