秒杀系统（三）Redis缓存和分布式锁

秒杀系统03——多级缓存

缓存：

后台问题描述

访问数据库查询商品信息：

读多写少

前端静态化页面：

上篇通过我们对数据进行静态化，也是有很多问题的，比如我们商品如果过多，freemark模板一定修改之后，我们所有的商品都需要重新再次生产静态化，这个工作量实在是太大了。

引入缓存:

缓存作用:

Redis缓存实战：

加入Redis

/**
     * 获取商品详情信息  加入redis
     *
     * @param id 产品ID
     */
    public PmsProductParam getProductInfo2(Long id) {
        PmsProductParam productInfo = null;
        //从缓存Redis里找
        productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
        if (null != productInfo) {
            return productInfo;
        }
        productInfo = portalProductDao.getProductInfo(id);
        System.out.println("我被执行了");
        if (null == productInfo) {
            log.warn("没有查询到商品信息,id:" + id);
            return null;
        }
        checkFlash(id, productInfo);
        redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, productInfo, 3600, TimeUnit.SECONDS);
        return productInfo;
    }

上述方案的问题： 数据拷贝、数据缓存的共性问题

1、数据一致性的问题，怎么保证Redis和mysql数据一致性的问题

Jmeter 1000次请求图，吞吐量630.5/sec

数据一致性的两种解决方案：

1、最终一致性方案：

设置超时时间来解决。设置Redis缓存数据的超时时间。Redis过期，下次请求还是得从mysql中获取

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

2、实时一致性方案：

交易canal binlog

两个问题(高并发)

压缩的问题 、减少内存

问题1，Redis缓存的对象有时候很大，Redis只解决了磁盘IO，没有解决网络IO问题。网络传输IO依旧很大。

问题2，Redis数据会占用大量内存，采用过期机制可以缓解内存压力。

网络I/O解决方法，压缩对象内容，采用序列化和压缩方法

压力测试情景

当前在jmeter里面进行1000个并发请求商品id=26，结果如下图

跟预期只set一次redis 是有出入，为何会这样子了？

re: 是因为出现了并发问题。

当我第二次再去访问，此时此刻没有日志输出，说明全部走了缓存

并发问题：并发编程》并发问题》可以用锁的方式来实现 java并发，但是加锁的方式（不适合分布式场景）

加锁的方式为什么不适用分布式场景：

情景： 假如有800个请求，400个去访问一个服务器，400个去访问另一个服务器。

其中加锁 synchronized 可以保证其中一个jvm的400个请求是串行去访问。

但是两个服务器访问数据库的顺序不能保证，是否是跨进程访问。

上锁时间、和代码块的运行时间

解决方法：采用分布式锁：redis、zookeeper

zookeeper 有强认证，适合分布式

Redis分布式实战

/*
 * zk分布式锁
 */
@Autowired
private ZKLock zkLock;
private String lockPath = "/load_db";

@Autowired
RedissonClient redission;

/**
     * 获取商品详情信息  加入redis 加入锁
     *
     * @param id 产品ID
     */
public PmsProductParam getProductInfo3(Long id) {
    PmsProductParam productInfo = null;
    //从缓存Redis里找
    productInfo = redisOpsUtil.get(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, PmsProductParam.class);
    if (null != productInfo) {
        return productInfo;
    }
    RLock lock = redission.getLock(lockPath + id); //获取重入锁
    try {
        if (lock.tryLock()) { //获取锁-同一个线程可重入
            productInfo = portalProductDao.getProductInfo(id);
            if (null == productInfo) {
                log.warn("没有查询到商品信息,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:重入锁和偏向锁的定义

重入锁，可重入性是指比如一个线程获得了对象A上的锁，如果它第二次请求A的锁必然可以获得（也就是说不会自己把自己锁住），可重入性是线程必须满足的，不然很多代码就会死锁了

偏向锁，偏向锁是说如果线程请求一个自己已经获得的锁，它不会去再次执行lock和unlock，这样可以提升性能。
如何实现可重入都是一样的，就是把锁的拥有者记下来，当申请锁的时候看一下锁是否已经被占有了，如果有人占着锁，看看是不是就是申请者自己。

可以看到使用了Redis锁，QPS立马提升了很多

---

Redis自身提供的锁 setnx，使用setnx进行并发锁进行

缓存应用场景：

1、访问量大、QPS高、更新频率不是很高的业务

2、数据一致性要求不高

Redis缓存问题

缓存击穿问题（热点数据单个key）：

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key，缓存击穿是对一个key一段时间其中进行访问。

解决方案：

1.加锁，在未命中缓存时，通过加锁避免大量请求访问数据库。通过加锁

2.不允许过期。物理不过期，也就是不设置过期时间。而是逻辑上定时在后台异步的更新数据。最简单粗暴的情况

3.采用二级缓存。L1缓存失效时间短，L2缓存失效时间长。请求优先从L1缓存获取数据，如果未命中，则加锁，保证只有一个线程去数据库中读取数据然后再更新到L1和L2中。然后其他线程依然在L2缓存获取数据。采用二级缓存，不可能两个Redis都被击穿。

缓存穿透问题（恶意攻击、访问不存在数据）：

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

有人采用不存在的key频繁的去访问，就会发生缓存穿透的问题

**解决方案：**有很多种方法可以有效地解决缓存穿透问题

1、最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。采用布隆过滤器

2、另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 直接将空节点也进行缓存到Redis中。

缓存雪崩（同一时间失效，并发量大）：

雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

大量的Redis同一时间失效，所有的接口瞬间访问数据库。

解决方案：

**1、**缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就是将缓存失效时间分散开，比如我们可以==在原有的失效时间基础上增加一个随机值==，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

2、事前：这种方案就是在发生雪崩前对缓存集群实现高可用，如果是使用 Redis，可以使用 主从+哨兵 ，Redis Cluster 来避免 Redis 全盘崩溃的情况。

3、事中：使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。采用限流&降级

4、事后：开启Redis持久化机制，尽快恢复缓存集群。发生雪崩后，快速恢复文件

缓存和数据库双写一致性问题：

一致性问题是分布式常见问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。

re: 先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。

我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。

引入分布式锁代码：

1、引入redis依赖

<!--加入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);
}

单机加锁：

分布式加锁：

同一时间同一个数据请求过来，比如set 100 value：（1 2 3）

使用ZooKeeper分布式锁实战

/**
 * 获取商品详情信息
 *
 * @param id 产品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);
            //缓存失效时间随机
            redisOpsUtil.set(RedisKeyPrefixConst.PRODUCT_DETAIL_CACHE + id, productInfo, 3600, TimeUnit.SECONDS);
        } else {
            //问题：返回为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());
    }

发现在高并发下增加了分布式锁可以解决刚才那个问题，但是也降低了qps，所以这儿还是要根据需求而定

分布式锁原理：

zk图

总结：

1、线程来会直接创建一个锁节点下的下一个临时顺序节点

2、如果自己不是第一个节点，就给自己加上一个节点监听器

3、只要上一个节点释放锁，自己就排到前面，相当于一个排队机制