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

一

一只阿木木2022年08月06日约 9 分钟

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

生产级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层

@Autowiredprivate RedisUtil redisUtil;@Autowiredprivate 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 越来越大，可能导致内存溢出。

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

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

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

未完待续... ...

文：一只阿木木

欢迎转发、交流小数据。

松花酿酒，春水煎茶。

眉上风止，见字如晤。

一只阿木木

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

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

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

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

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

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

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

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

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

来自同一个声音

一条命令自动清空 Inbox——inbox-triage 让 AI 帮你分拣每一条笔记

7 步闭环！从碎片信息到知识资产——我的 PKM 工作流全拆解

raw 是原料，wiki 是成品——为什么你的知识库必须分层（附完整架构模板）

Codex 知识库的「宪法」——AGENTS.md 不只是配置文件，它是你和 AI 之间的协作关系