生产级Redis 高并发分布式锁实战2：缓存架构设计问题优化

对于大多数高并发场景，都是读多写少。比如商品信息，医生挂号信息等。提交订单页只有一个操作。

对于一个普通的缓存架构设计，实现商品的增删改查功能，代码如下：

Controller 层

@RestController("/api/product")
public class ProductController{
    @Autowired
    private ProductService productService;

    @RequestMapping(value="/add",method=RequestMethod.POST)
    public Product addProduct(@RequestBody Product productParam){
        return productService.addProduct(productParam);
    }

    @RequestMapping(value="/update",method=RequestMethod.POST)
    public Product updateProduct(@RequestBody Product productParam){
        return productService.updateProduct(productParam);
    }

    @RequestMapping(value="/get/{productId}")
    public Product getProduct(@PathVariable Long productId){
        return productService.getProduct(productId);
    }
}

Service层

@Autowired
private RedisUtil redisUtil;

@Autowired
private Redisson redisson;

public static final Integer PRODUCT_CACHE_TIMEOUT = 60 * 60 * 24;

@Transactional
public Product addProduct(Product product){
    Product productResult = productDao.addProduct(product);

    redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(),JSON.toJSONString(productResult)   );
    return productResult;
}

@Transactional
public Product updateProduct(Product product){
    Product productResult = productDao.updateProduct(product);

    redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(),JSON.toJSONString(productResult)   );
    return productResult;
}

public Product getProduct(Long productId){

    Product product = null;

    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    String productStr = redisUtil.get(productCacheKey);

    if(!StringUtils.isEmpty(productStr)){
        product = JSON.parseObject(productStr,Product.class);
        return product;
    }

    product = productDao.get(productId);

    if(product != null){
        redisUtil.set(productCacheKey, JSON.toJSONString(product));
    }
    return product;
}

优化架构问题1： 冷热数据

问题分析：假设几十亿的商品，所有商品数据将存入缓存。每天需要访问的数据，我们称为热数据。仅占内存不到 1%。热数据放缓存，冷数据放数据库，可以设置缓存超时时间，如24小时失效。

冷热数据分离方案：添加缓存失效时间，做到冷热数据分离

// 冷热数据分离，给缓存设置过期时间
redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(),JSON.toJSONString(productResult),PRODUCT_CACHE_TIMEOUT,TimeUnit.SECONDS );

// 查到缓存，则添加过期时间。称之为缓存读延期
String productStr = redisUtil.get(productCacheKey);
if(!StringUtils.isEmpty(productStr)){
        product = JSON.parseObject(productStr,Product.class);

        redisUtil.expire(productCacheKey,PRODUCT_CACHE_TIMEOUT,TimeUnit.SECONDS );
        return product;
}

优化架构问题2：缓存失效

参考：缓存击穿，缓存穿透，缓存雪崩问题分析及优化

• 缓存击穿：大批缓存在同一时间失效，导致大量请求同时穿透缓存直达数据库，可能会造成数据库瞬间压力过大甚至挂掉。

//设置随机时间

private Integer genProductCacheTimeOut(){
    return PRODUCT_CACHE_TIMEOUT + new Random().nextInt(5) * 60 * 60;
}

• 缓存穿透:
  
  被黑客攻击，后台发送大量数据库中不存在请求；
  
  或后台误操作商品在数据库中被删除。此时存在缓存无数据，数据库中无数据。

或使用布隆过滤器。或设置空缓存。

public static final String EMPTY_CACHE = "{}";

public Product getProduct(Long productId){

    Product product = null;

    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    String productStr = redisUtil.get(productCacheKey);

    if(!StringUtils.isEmpty(productStr)){
        // 如果查到缓存是我们设置的空缓存，则直接返回。
        if(EMPTY_CACHE.equals(productStr)){
            // 设置读延期
            redisUtils.expire(productCackeKey,genEmptyCacheTimeOut(), TimeUnit.SECONDS);
            return null;
        }

        product = JSON.parseObject(productStr,Product.class);

        redisUtil.expire(productCacheKey,genProductCacheTimeOut(),TimeUnit.SECONDS );
        return product;
    }

    product = productDao.get(productId);

    if(product != null){
        redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
    } else {
    // 设置空缓存
        redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
    }
    return product;
}

给空缓存设置一个过期时间

//设置随机时间

private Integer genEmptyCacheTimeOut(){
    return 60 + new Random().nextInt(30);
}

优化架构问题3：突发性热点缓存重建

假设几百万用户，几十万用户请求商品链接。冷门商品在缓存中不存在，则请求数据库。

假设此时几万请求到数据库，执行相同的设置缓存操作，这是典型的突发性热点缓存重建，导致系统压力暴增问题。

DCL: double check lock 双重检测锁。

方案：1 加锁，则不会让数据库宕机。2 双重检测锁DCL(Double Check Lock)。

• 缓存雪崩：指缓存支撑不住或宕机后，大量请求打到存储层，造成存储层也会级联宕机。

private Product getProductCache(String productCacheKey){
    Product product = null;
    String productStr = redisUtil.get(productCacheKey);
    if(!StringUtils.isEmpty(productStr)){
        // 如果查到缓存是我们设置的空缓存，则直接返回。
        if(EMPTY_CACHE.equals(productStr)){
            // 设置读延期
            redisUtils.expire(productCackeKey,genEmptyCacheTimeOut(), TimeUnit.SECONDS);
            return null;
        }

        product = JSON.parseObject(productStr,Product.class);

        redisUtil.expire(productCacheKey,genProductCacheTimeOut(),TimeUnit.SECONDS );

    }
    return product;
}

public Product getProduct(Long productId){

    Product product = null;

    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    product = getProductCache(productCacheKey);

    if(product != null){
        return product;
    }

    // 双重检测 DCL
    sysnchronized(this){
        // 双重检测，当缓存重建后，直接返回。
        product = getProductCache(productCacheKey);
        if(product != null){
            return product;
        }

        product = productDao.get(productId);
        if(product != null){
            redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
        } else {
        // 设置空缓存
            redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
        }
    }
     return product;

}

优化架构问题4：JVM锁与分布式锁

商品1 和商品2 的商品链接互不影响， 不需要相互加互斥锁，所以要优化为分布式锁。

public Product getProduct(Long productId){

    Product product = null;

    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    product = getProductCache(productCacheKey);

    if(product != null){
        return product;
    }

    // 双重检测 DCL
    sysnchronized(this){
        // 双重检测，当缓存重建后，直接返回。
        product = getProductCache(productCacheKey);
        if(product != null){
            return product;
        }

        product = productDao.get(productId);
        if(product != null){
            redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
        } else {
        // 设置空缓存
            redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
        }
    }
     return product;

}

优化分布式锁：

public static final String HOT_CACHE_PREFIX_LOCK = "hot_cache:lock";

public Product getProduct(Long productId){

    Product product = null;

    String productCacheKey = RedisKeyPrefixConst.PRODUCT_CACHE + productId;

    product = getProductCache(productCacheKey);

    if(product != null){
        return product;
    }

    // 双重检测 DCL
    RLock redissonLock = redisson.getLock(HOT_CACHE_PREFIX_LOCK + productId);
    redissonLock.lock(); // 用lua 脚本实现的setnx分布式锁

    try{
         product = getProductCache(productCacheKey);
        if(product != null){
            return product;
        }

        product = productDao.get(productId);
        if(product != null){
            redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
        } else {
        // 设置空缓存
            redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
        }
    } finally {
       redissonLock.unlock();
    }

     return product;

}

优化架构问题5：缓存数据库双写不一致

问题描述：

• 线程1写数据库product=10, -- 更新缓存为10.
• 线程2 --- --- --- --- 写数据库product=6,更新缓存6.
• 线程3--查缓存，为空。查数据库10， --- --- 更新缓存为10.

更新缓存和删除缓存是一样的问题。

public static final String UPDATE_PRODUCT_LOCK = "update_product:lock";

//getProduct 加锁

    try{
         product = getProductCache(productCacheKey);
        if(product != null){
            return product;
        }

       //加锁
        RLock updateProductLock = redisson.getLock(UPDATE_PRODUCT_LOCK+productId);

        updateProductLock.lock();

        try{
           product = productDao.get(productId);
            if(product != null){
                redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
            } else {
            // 设置空缓存
                redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
            }
        } finally {
            updateProductLock.unlock();
        }
    } finally {
       redissonLock.unlock();
    }

// update 加锁

@Transactional
public Product updateProduct(Product product){
    Product productResult =null;
    //与查询方法中的锁是同一把锁，互斥
    RLock updateProductLock = redisson.getLock(UPDATE_PRODUCT_LOCK+productId);
    updateProductLock.lock();

    // 串行执行，没有并发安全问题
    try{
       productDao.updateProduct(product);

        redisUtil.set(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(),JSON.toJSONString(productResult),genProductCacheTimeout(),TimeUnit.SECONDS);
    } finally {
        updateProductLock.unlock();
    }

    return productResult;
}

优化架构问题6：优化缓存数据库双写不一致下的分布式锁的优化

读写锁。读锁的时候是共享锁，并行执行。

// 读锁
        //RLock updateProductLock = redisson.getLock(UPDATE_PRODUCT_LOCK+productId);
        //updateProductLock.lock();

        RReadWriteLock readWriteLock = redisson.getLock(UPDATE_PRODUCT_LOCK+productId);
        RLock rLock = readWriteLock.readLock();
        rLock.lock();

        try{
           product = productDao.get(productId);
            if(product != null){
                redisUtil.set(productCacheKey, JSON.toJSONString(product),genProductCacheTimeOut(), TimeUnit.SECONDS);
            } else {
            // 设置空缓存
                redisUtil.set(productCacheKey, EMPTY_CACHE, genEmptyCacheTimeOut(), TimeUnit.SECONDS);
            }
        } finally {
            rLock.unlock();
        }

同理，更新操作改为写锁，代码略。读写锁也是基于lua 脚本实现，

优化架构问题7：空发热点缓存环境下的分布式锁的优化

DCL 双重检测锁。

串行转并发思想

串行转并发：保证第一次线程在3s 内加锁完毕并且把逻辑走完，其他等待的几万的请求直接并行查缓存。

问题：假如第一个请求重建逻辑缓存需要4s，大量在等待的线程会在3s 的时候查缓存，此时缓存没有重建完成，会导致请求到数据库，相当于缓存失效。

// 原有DCL 的逻辑：
RLock redissonLock = redisson.getLock(""+productId);

redissonLock.lock();

优化为：
redissonnLock.tryLock(3, TimeUnit.SECONDS);

3s 后，假设有几万在等待的请求，则直接并行查缓存返回。

问题：假设第一个线程4s，大量数据会击穿缓存查数据库，又会导致数据库压力爆增。要提前想好，做好权衡。

做架构，要根据业务场景，选择更适合的技术。

系统逻辑增加，会不会也会导致系统变慢，那么加锁的意义又没意义了？

如果系统没有高并发的情况，可采用我们初始的代码。但在大型生产环境下，就会存在并发的问题。

代码逻辑增加，系统执行会有影响吗？

90% 的问题得到解决，不会请求到代码逻辑。10% 的性能用来处理小概率场景，高并发下的小概率场景是不允许出错的。

架构的设计思想：要根据具体的业务场景来设计技术架构。

优化架构问题8：商品大促环境下的缓存血崩

多级缓存架构。此时可以加一个JVM 进程级别的缓存

public static Map<String, Product> productMap = new ConcurrentHashMap();

private Product getProductCache(String productCacheKey){

   // 1 先查jvm 进程级别的缓存，每秒可支持百万并发
    Product product = productMap.get(productCacheKey);
    if (null != product){
        return product;
    }

   // 2 在查redis 缓存 ，redis 支持分片操作
    String productStr = redisUtil.get(productCacheKey);
    if(!StringUtils.isEmpty(productStr)){
        // 如果查到缓存是我们设置的空缓存，则直接返回。
        if(EMPTY_CACHE.equals(productStr)){
            // 设置读延期
            redisUtils.expire(productCackeKey,genEmptyCacheTimeOut(), TimeUnit.SECONDS);
            return null;
        }

        product = JSON.parseObject(productStr,Product.class);

        redisUtil.expire(productCacheKey,genProductCacheTimeOut(),TimeUnit.SECONDS );

    }
    return product;
}

// 更新redis 数据时，也要更新jvm 缓存

productMap.put(RedisKeyPrefixConst.PRODUCT_CACHE + productResult.getId(),product);

//问题1： 如果部署多台服务器，此时会导致jvm 缓存不一致

//问题2：map 越来越大，可能导致内存溢出。

解决了一个问题，创造了两个问题。那么这些问题该如何处理呢？

by:一只阿木木