8.商品分类、缓存及分布式锁(Redisson)

1. 门户首页商品分类

搜索做完之后,把目光移动首页,首页最重要的模块之一便是商品分类,商品分类也是进入商品列表,找到心仪商品的另一个主要途径。

8.商品分类、缓存及分布式锁(Redisson)_第1张图片

接下来就搭建一个module。这个页面作为整个商城的门户入口,访问量巨大,为了方便优化扩展,需要搭建独立的系统。

1.1. 创建首页Module

创建gmall-index首页工程

8.商品分类、缓存及分布式锁(Redisson)_第2张图片

application.yml配置如下:bootstrap.yml配置略。。。

server:
  port: 18087
spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    sentinel:
      transport:
        dashboard: localhost:8080
        port: 8719
  zipkin:
    base-url: http://localhost:9411/
    sender:
      type: web
    discovery-client-enabled: false
  sleuth:
    sampler:
      probability: 1
  redis:
    host: 172.16.116.100
  thymeleaf:
    cache: false
feign:
  sentinel:
    enabled: true

启动类上的注解:

@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
public class GmallIndexApplication {

    public static void main(String[] args) {
        SpringApplication.run(GmallIndexApplication.class, args);
    }
}

并把首页的页面及common目录 copy到templates目录下:

8.商品分类、缓存及分布式锁(Redisson)_第3张图片

在网关工程中配置首页路由:

- id: index-route1 # 首页的同步请求路由
  uri: lb://index-service
  predicates:
  - Host=www.gmall.com
  # - Path=/index/**  如果写在一个里面,他们的关系是and关系
- id: index-route2 # 首页的异步请求路由
  uri: lb://index-service
  predicates:
  - Path=/index/**

并在cors跨域过滤器中,添加允许跨域的域名地址:

8.商品分类、缓存及分布式锁(Redisson)_第4张图片

重启网关。修改nginx配置如下:

8.商品分类、缓存及分布式锁(Redisson)_第5张图片

重新加载配置文件:nginx -s reload

1.2. 跳转到首页

跳转到首页,并加载一级分类。

实现如下:

8.商品分类、缓存及分布式锁(Redisson)_第6张图片

IndexController:

@Controller
public class IndexController {

    @Autowired
    private IndexService indexService;

    @GetMapping
    public String toIndex(Model model){

        List<CategoryEntity> categoryEntities = this.indexService.queryLvl1Categories();
        model.addAttribute("cates", categoryEntities);

        // TODO: 加载其他数据

        return "index";
    }

}

IndexService:

@Service
public class IndexService {

    @Autowired
    private GmallPmsFeign pmsFeign;

    public List<CategoryEntity> queryLvl1Categories() {
        ResponseVo<List<CategoryEntity>> listResponseVo = this.pmsClient.queryCategoriesByPid(0l);
        return listResponseVo.getData();
    }

}

GmallPmsFeign:

@FeignClient("pms-service")
public interface GmallPmsClient extends GmallPmsApi {
}

注意:需要引入gmall-pms-interface的依赖

<dependency>
    <groupId>com.atguigugroupId>
    <artifactId>gmall-pms-interfaceartifactId>
    <version>0.0.1-SNAPSHOTversion>
dependency>

访问测试:

8.商品分类、缓存及分布式锁(Redisson)_第7张图片

1.3. 获取二、三级分类

对标京东:

8.商品分类、缓存及分布式锁(Redisson)_第8张图片

为了提高页面的响应速度,这里异步加载一级分类对应的二级分类及其下的所有三级分类。

结合接口文档:

请求地址:/index/cates/{pid}

请求方式:GET

请求参数:pid(一级分类的id)

正确响应:List 需要给CategoryEntity扩展一个字段subs

8.商品分类、缓存及分布式锁(Redisson)_第9张图片

需要gmall-pms提供这样的接口,然后在gmall-index中调用这个接口。

1.3.1. gmall-pms提供数据接口

在CategoryController中添加方法:

@GetMapping("subs/{pid}")
public ResponseVo<List<CategoryEntity>> queryCategoriesWithSub(@PathVariable("pid")Long pid){
    List<CategoryEntity> categoryEntityList = this.categoryService.queryCategoriesWithSub(pid);
    return ResponseVo.ok(categoryEntityList);
}

CategoryService:

public interface CategoryService extends IService<CategoryEntity> {

    PageResultVo queryPage(PageParamVo paramVo);

    List<CategoryEntity> queryCategory(Long parentId);

    List<CategoryEntity> queryCategoriesWithSub(Long pid);
}

在CategoryServiceImpl实现类中实现方法:

@Autowired
private CategoryMapper categoryMapper;

@Override
public List<CategoryEntity> queryCategoriesWithSub(Long pid) {
    return this.categoryMapper.queryCategoriesByPid(pid);
}

CategoryMapper:

@Mapper
public interface CategoryMapper extends BaseMapper<CategoryEntity> {

    List<CategoryEntity> queryCategoriesByPid(Long pid);
}

CategoryMapper.xml:



<mapper namespace="com.atguigu.gmall.pms.mapper.CategoryMapper">

    <resultMap id="CategoryMap" type="categoryEntity" autoMapping="true">
        <collection property="subs" javaType="list" ofType="categoryEntity" select="queryCategoriesByPid" column="id"/>
    resultMap>

    <select id="queryCategoriesByPid" resultMap="CategoryMap">
        select * from pms_category where parent_id = #{pid}
    select>
mapper>

测试:

8.商品分类、缓存及分布式锁(Redisson)_第10张图片

1.3.2. gmall-pms-interface定义api方法

在GmallPmsApi定义抽象的api接口方法

@GetMapping("pms/category/subs/{pid}")
public ResponseVo<List<CategoryEntity>> queryCategoriesWithSub(@PathVariable("pid")Long pid);

1.3.3. gmall-index调用接口

IndexController:

@ResponseBody
@GetMapping("index/cates/{pid}")
public ResponseVo<List<CategoryEntity>> queryLvl2CategoriesWithSub(@PathVariable("pid")Long pid){

    List<CategoryEntity> categoryEntities = this.indexService.queryLvl2CategoriesWithSub(pid);
    return ResponseVo.ok(categoryEntities);
}

IndexService:

public List<CategoryEntity> queryLvl2CategoriesWithSub(Long pid) {

    ResponseVo<List<CategoryEntity>> listResponseVo = this.pmsClient.queryCategoriesWithSub(pid);
    return listResponseVo.getData();
}

1.3.4. 整合测试

重启测试:

8.商品分类、缓存及分布式锁(Redisson)_第11张图片

访问首页,效果如下:

8.商品分类、缓存及分布式锁(Redisson)_第12张图片

2. 缓存

首页的访问量非常大,而首页中的商品类目访问量更大,鼠标移动就在访问,查询所有的数据,如果每次访问都实时到数据库获取数据,数据库的访问压力太大。

而这些信息一般更新的频率比较低,短时间内不会发生改变。因此,我们可以考虑在前台系统中,增加一层缓存,把这些数据缓存起来,请求到来时,不再调用数据接口,而是直接读取缓存中的数据。

这样就能大大减少首页分类加载所需时间,提高并发性能。

加不加缓存的标准:

  1. 变化频率低

  2. 访问频繁

实现:使用Redis实现缓存。

2.1. 如何实现

  1. 先读缓存,缓存有,直接返回。
  2. 缓存没有,再读数据库

2.2. 缓存的基本实现

接下来以根据父节点查询子节点演示缓存功能:

@Autowired
private StringRedisTemplate redisTemplate;

public static final String KEY_PREFIX = "index:category:";

public List<CategoryEntity> queryLvl2CategoriesWithSub(Long pid) {

    // 从缓存中获取
    String cacheCategories = this.redisTemplate.opsForValue().get(KEY_PREFIX + pid);
    if (StringUtils.isNotBlank(cacheCategories)){
        // 如果缓存中有,直接返回
        List<CategoryEntity> categoryEntities = JSON.parseArray(cacheCategories, CategoryEntity.class);
        return categoryEntities;
    }

    ResponseVo<List<CategoryEntity>> subCategoryResp = this.gmallPmsFeign.querySubCategory(pid);

    // 把查询结果放入缓存
    this.redisTemplate.opsForValue().set(KEY_PREFIX + pid, JSON.toJSONString(subCategoryResp), 30, TimeUnit.DAYS);

    return subCategoryResp.getData();
}

查询一级分类的缓存功能请自行实现。

测试:

8.商品分类、缓存及分布式锁(Redisson)_第13张图片

2.3. 缓存一致性

  1. 双写模式:写数据库,写缓存
  2. 失效模式:缓存失效(删除缓存),写数据库

读取缓存步骤数据一致性一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题

不管先保存到MySQL,还是先保存到Redis都面临着一个保存成功而另外一个保存失败的情况。

不管是先写MySQL数据库,再删除Redis缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。举一个例子:

1.如果删除了缓存Redis,还没有来得及写库MySQL,另一个线程就来读取,发现缓存为空,则去数据库中读取数据写入缓存,此时缓存中为脏数据。

2.如果先写了库,在删除缓存前,写库的线程宕机了,没有删除掉缓存,则也会出现数据不一致情况。

因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

解决:

  1. 基于mysql的binlog日志(canal)
  2. 消息队列

2.4. 缓存常见问题

缓存最常见的3个问题:

  1. 缓存穿透

  2. 缓存雪崩

  3. 缓存击穿

缓存穿透是指查询一个不存在的数据,由于缓存无法命中,将去查询数据库,但是数据库也无此记录,并且出于容错考虑,我们没有将这次查询的null写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞

解决:空结果也进行缓存,但它的过期时间会很短,最长不超过五分钟。

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

解决:原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。

缓存击穿是指对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:如果这个key在大量请求同时进来之前正好失效,那么所有对这个key的数据查询都落到db,我们称为缓存击穿。

与缓存雪崩的区别:

  1. 击穿是一个热点key失效
  2. 雪崩是很多key集体失效

解决:锁

8.商品分类、缓存及分布式锁(Redisson)_第14张图片

3. 分布式锁

3.1. 本地锁的局限性

之前,我们学习过synchronized及lock锁,这些锁都是本地锁。接下来写一个案例,演示本地锁的问题

3.1.1. 编写测试代码

在gmall-index中的IndexController中添加测试方法:

@GetMapping("testlock")
public ResponseVo<Object> testLock(){
    
    indexService.testLock();

    return ResponseVo.ok(null);
}

在IndexService方法中添加方法:

public void testLock() {
    // 查询redis中的num值
    String value = this.redisTemplate.opsForValue().get("num");
    // 没有该值return
    if (StringUtils.isBlank(value)){
        return ;
    }
    // 有值就转成成int
    int num = Integer.parseInt(value);
    // 把redis中的num值+1
    this.redisTemplate.opsForValue().set("num", String.valueOf(++num));
}

3.1.2. 使用ab工具测试

之前在redis中,玩过ab测试工具:httpd-tools(yum install -y httpd-tools)

ab  -n(一次发送的请求数)  -c(请求的并发数) 访问路径

测试之前需要在linux中修改hosts文件,添加域名映射:vi /etc/hosts
8.商品分类、缓存及分布式锁(Redisson)_第15张图片

测试如下:5000请求,100并发

8.商品分类、缓存及分布式锁(Redisson)_第16张图片

查看redis中的值:

8.商品分类、缓存及分布式锁(Redisson)_第17张图片

只有186。这代码问题很大!

3.1.3. 添加本地锁

8.商品分类、缓存及分布式锁(Redisson)_第18张图片

使用ab工具压力测试:5000次请求,并发100

8.商品分类、缓存及分布式锁(Redisson)_第19张图片

查看redis中的结果:

8.商品分类、缓存及分布式锁(Redisson)_第20张图片

完美!是否真的完美?

接下来再看集群情况下,会怎样?

3.1.4. 本地锁问题演示

接下来启动18087 18088 18089三个运行实例。

运行多个gmall-index实例:

8.商品分类、缓存及分布式锁(Redisson)_第21张图片

8.商品分类、缓存及分布式锁(Redisson)_第22张图片

这样就能启动多个运行实例

8.商品分类、缓存及分布式锁(Redisson)_第23张图片

由于这三个运行实例的服务名都是index-service,而网关配置的就是通过服务名负载均衡,我们只要通过网关访问,网关就会给我们做负载均衡了。

再次执行之前的压力测试,查看redis中的值:

8.商品分类、缓存及分布式锁(Redisson)_第24张图片

集群情况下又出问题了!!!

以上测试,可以发现:

​ 本地锁只能锁住同一工程内的资源,在分布式系统里面都存在局限性。

此时需要分布式锁。。

3.2. 分布式锁的实现

随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!

分布式锁主流的实现方案:

  1. 基于数据库实现分布式锁
  2. 基于缓存(Redis等)
  3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点:

  1. 性能:redis最高
  2. 可靠性:zookeeper最高

这里,我们就基于redis实现分布式锁。

3.2.1. 基本实现

借助于redis中的命令setnx(key, value),key不存在就新增,存在就什么都不做。同时有多个客户端发送setnx命令,只有一个客户端可以成功,返回1(true);其他的客户端返回0(false)。

8.商品分类、缓存及分布式锁(Redisson)_第25张图片

  1. 多个客户端同时获取锁(setnx)
  2. 获取成功,执行业务逻辑,执行完成释放锁(del)
  3. 其他客户端等待重试

代码:

public void testLock() {
    // 1. 从redis中获取锁,setnx
    Boolean lock = this.redisTemplate.opsForValue().setIfAbsent("lock", "111");
    if (lock) {
        // 查询redis中的num值
        String value = this.redisTemplate.opsForValue().get("num");
        // 没有该值return
        if (StringUtils.isBlank(value)){
            return ;
        }
        // 有值就转成成int
        int num = Integer.parseInt(value);
        // 把redis中的num值+1
        this.redisTemplate.opsForValue().set("num", String.valueOf(++num));

        // 2. 释放锁 del
        this.redisTemplate.delete("lock");
    } else {
        // 3. 每隔1秒钟回调一次,再次尝试获取锁
        try {
            Thread.sleep(1000);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

重启,服务集群,通过网关压力测试:

8.商品分类、缓存及分布式锁(Redisson)_第26张图片

查看redis中num的值:

8.商品分类、缓存及分布式锁(Redisson)_第27张图片

基本实现。

问题:setnx刚好获取到锁,业务逻辑出现异常,导致锁无法释放

解决:设置过期时间,自动释放锁。

3.2.2. 优化之设置锁的过期时间

设置过期时间有两种方式:

  1. 首先想到通过expire设置过期时间(缺乏原子性:如果在setnx和expire之间出现异常,锁也无法释放)
  2. 在set时指定过期时间(推荐)

8.商品分类、缓存及分布式锁(Redisson)_第28张图片

设置过期时间:

8.商品分类、缓存及分布式锁(Redisson)_第29张图片

压力测试肯定也没有问题。自行测试

问题:可能会释放其他服务器的锁。

场景:如果业务逻辑的执行时间是7s。执行流程如下

  1. index1业务逻辑没执行完,3秒后锁被自动释放。

  2. index2获取到锁,执行业务逻辑,3秒后锁被自动释放。

  3. index3获取到锁,执行业务逻辑

  4. index1业务逻辑执行完成,开始调用del释放锁,这时释放的是index3的锁,导致index3的业务只执行1s就被别人释放。

    最终等于没锁的情况。

解决:setnx获取锁时,设置一个指定的唯一值(例如:uuid);释放前获取这个值,判断是否自己的锁

3.2.3. 优化之UUID防误删

8.商品分类、缓存及分布式锁(Redisson)_第30张图片

实现如下:

8.商品分类、缓存及分布式锁(Redisson)_第31张图片

问题:删除操作缺乏原子性。

场景:

  1. index1执行删除时,查询到的lock值确实和uuid相等
  2. index1执行删除前,lock刚好过期时间已到,被redis自动释放
  3. index2获取了lock
  4. index1执行删除,此时会把index2的lock删除

3.2.4. 优化之LUA脚本保证删除的原子性

删除LUA脚本:

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

实现:

public void testLock() {
    // 1. 从redis中获取锁,setnx
    String uuid = UUID.randomUUID().toString();
    Boolean lock = this.redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
    if (lock) {
        // 查询redis中的num值
        String value = this.redisTemplate.opsForValue().get("num");
        // 没有该值return
        if (StringUtils.isBlank(value)){
            return ;
        }
        // 有值就转成成int
        int num = Integer.parseInt(value);
        // 把redis中的num值+1
        this.redisTemplate.opsForValue().set("num", String.valueOf(++num));

        // 2. 释放锁 del
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        this.redisTemplate.execute(new DefaultRedisScript<>(script), Arrays.asList("lock"), uuid);
        //            if (StringUtils.equals(uuid, this.redisTemplate.opsForValue().get("num"))) {
        //                this.redisTemplate.delete("lock");
        //            }
    } else {
        // 3. 每隔1秒钟回调一次,再次尝试获取锁
        try {
            Thread.sleep(1000);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

3.2.5. 优化之可重入锁

由于上述加锁命令使用了 SETNX ,一旦键存在就无法再设置成功,这就导致后续同一线程内继续加锁,将会加锁失败。当一个线程执行一段代码成功获取锁之后,继续执行时,又遇到加锁的子任务代码,可重入性就保证线程能继续执行,而不可重入就是需要等待锁释放之后,再次获取锁成功,才能继续往下执行。

用一段 Java 代码解释可重入:

public synchronized void a() {
    b();
}

public synchronized void b() {
    // pass
}

假设 X 线程在 a 方法获取锁之后,继续执行 b 方法,如果此时不可重入,线程就必须等待锁释放,再次争抢锁。

锁明明是被 X 线程拥有,却还需要等待自己释放锁,然后再去抢锁,这看起来就很奇怪,我释放我自己~

可重入性就可以解决这个尴尬的问题,当线程拥有锁之后,往后再遇到加锁方法,直接将加锁次数加 1,然后再执行方法逻辑。退出加锁方法之后,加锁次数再减 1,当加锁次数为 0 时,锁才被真正的释放。

可以看到可重入锁最大特性就是计数,计算加锁的次数。所以当可重入锁需要在分布式环境实现时,我们也就需要统计加锁次数。

分布式可重入锁实现方式有两种:

  • 基于 ThreadLocal 实现方案(略。。)
  • 基于 Redis Hash 实现方案

3.2.5.1. 加锁

Redis 提供了 Hash (哈希表)这种可以存储键值对数据结构。所以我们可以使用 Redis Hash 存储的锁的重入次数,然后利用 lua 脚本判断逻辑。

if (redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1) 
then
    redis.call('hincrby', KEYS[1], ARGV[1], 1);
    redis.call('expire', KEYS[1], ARGV[2]);
    return 1;
else
	return 0;
end

假设值为:KEYS:[lock], ARGV[uuid, expire]

如果锁不存在或者这是自己的锁,就通过hincrby(不存在新增,存在就加1)获取锁或者锁次数加1。

具体java代码如下:

private Boolean tryLock(String lockName, String uuid, Long expire){
    String script = "if (redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1) " +
        "then" +
        "    redis.call('hincrby', KEYS[1], ARGV[1], 1);" +
        "    redis.call('expire', KEYS[1], ARGV[2]);" +
        "    return 1;" +
        "else" +
        "   return 0;" +
        "end";
    if (!this.redisTemplate.execute(new DefaultRedisScript<>(script, Boolean.class), Arrays.asList(lockName), uuid, expire.toString())){
        try {
            // 没有获取到锁,重试
            Thread.sleep(200);
            tryLock(lockName, uuid, expire);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    // 获取到锁,返回true
    return true;
}

3.2.5.2. 解锁

-- 判断 hash set 可重入 key 的值是否等于 0
-- 如果为 nil 代表 其他线程尝试解锁,解锁失败
-- 如果为 0 代表 可重入次数被减 1
-- 如果为 1 代表 该可重入 key 解锁成功
if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then
    return nil;
end;
-- 小于等于 0 代表可以解锁
if (redis.call('hincrby', KEYS[1], ARGV[1], -1) > 0) then
    return 0;
else
    redis.call('del', KEYS[1]);
    return 1;
end;

这里之所以没有跟加锁一样使用 Boolean ,这是因为解锁 lua 脚本中,三个返回值含义如下:

  • 1 代表解锁成功,锁被释放
  • 0 代表可重入次数被减 1
  • null 代表其他线程尝试解锁,解锁失败

如果返回值使用 Boolean,Spring-data-redis 进行类型转换时将会把 null 转为 false,这就会影响我们逻辑判断,所以返回类型只好使用 Long。

具体java代码:

private void unlock(String lockName, String uuid){
    String script = "if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then" +
        "    return nil;" +
        "end;" +
        "if (redis.call('hincrby', KEYS[1], ARGV[1], -1) > 0) then" +
        "    return 0;" +
        "else" +
        "    redis.call('del', KEYS[1]);" +
        "    return 1;" +
        "end;";
    // 这里之所以没有跟加锁一样使用 Boolean ,这是因为解锁 lua 脚本中,三个返回值含义如下:
    // 1 代表解锁成功,锁被释放
    // 0 代表可重入次数被减 1
    // null 代表其他线程尝试解锁,解锁失败
    Long result = this.redisTemplate.execute(new DefaultRedisScript<>(script, Long.class), Lists.newArrayList(lockName), uuid);
    // 如果未返回值,代表尝试解其他线程的锁
    if (result == null) {
        throw new IllegalMonitorStateException("attempt to unlock lock, not locked by lockName: "
                                               + lockName + " with request: "  + uuid);
    }
}

3.2.5.3. 使用

public void testLock() {
    // 加锁
    String uuid = UUID.randomUUID().toString();
    Boolean lock = this.tryLock("lock", uuid, 300l);

    if (lock) {
        // 读取redis中的num值
        String numString = this.redisTemplate.opsForValue().get("num");
        if (StringUtils.isBlank(numString)) {
            return;
        }

        // ++操作
        Integer num = Integer.parseInt(numString);
        num++;

        // 放入redis
        this.redisTemplate.opsForValue().set("num", String.valueOf(num));

        // 测试可重入性
        this.testSubLock(uuid);

        // 释放锁
        this.unlock("lock", uuid);
    }
}

// 测试可重入性
private void testSubLock(String uuid){
    // 加锁
    Boolean lock = this.tryLock("lock", uuid, 300l);

    if (lock) {
        System.out.println("分布式可重入锁。。。");

        this.unlock("lock", uuid);
    }
}

3.2.6. 优化之自动续期

A线程超时时间设为10s(为了解决死锁问题),但代码执行时间可能需要30s,然后redis服务端10s后将锁删除。 此时,B线程恰好申请锁,redis服务端不存在该锁,可以申请,也执行了代码。那么问题来了, A、B线程都同时获取到锁并执行业务逻辑,这与分布式锁最基本的性质相违背:在任意一个时刻,只有一个客户端持有锁(即独享排他)。

锁延期方法:开启子线程执行延期

/**
     * 锁延期
     * 线程等待超时时间的2/3时间后,执行锁延时代码,直到业务逻辑执行完毕,因此在此过程中,其他线程无法获取到锁,保证了线程安全性
     * @param lockName
     * @param expire 单位:秒
     */
private void renewTime(String lockName, Long expire){
    String script = "if redis.call('exists', KEYS[1]) == 1 then return redis.call('expire', KEYS[1], ARGV[1]) else return 0 end";
    new Thread(() -> {
        while (this.redisTemplate.execute(new DefaultRedisScript<>(script, Boolean.class), Lists.newArrayList(lockName), expire.toString())){
            try {
                // 到达过期时间的2/3时间,自动续期
                Thread.sleep(expire * 2000 / 3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }).start();
}

获取锁成功后,调用延期方法给锁定时延期:

private Boolean tryLock(String lockName, String uuid, Long expire){
    String script = "if (redis.call('exists', KEYS[1]) == 0 or redis.call('hexists', KEYS[1], ARGV[1]) == 1) " +
        "then" +
        "    redis.call('hincrby', KEYS[1], ARGV[1], 1);" +
        "    redis.call('expire', KEYS[1], ARGV[2]);" +
        "    return 1;" +
        "else" +
        "   return 0;" +
        "end";
    if (!this.redisTemplate.execute(new DefaultRedisScript<>(script, Boolean.class), Arrays.asList(lockName), uuid, expire.toString())){
        try {
            // 没有获取到锁,重试
            Thread.sleep(200);
            tryLock(lockName, uuid, expire);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    // 锁续期
    this.renewTime(lockName, expire);
    // 获取到锁,返回true
    return true;
}

测试方法:锁过期时间30s,线程睡眠时间60s,每隔20s会自动续期。

public void testLock() {
    // 加锁
    String uuid = UUID.randomUUID().toString();
    Boolean lock = this.tryLock("lock", uuid, 30l);

    if (lock) {
        // 读取redis中的num值
        String numString = this.redisTemplate.opsForValue().get("num");
        if (StringUtils.isBlank(numString)) {
            return;
        }

        // ++操作
        Integer num = Integer.parseInt(numString);
        num++;

        // 放入redis
        this.redisTemplate.opsForValue().set("num", String.valueOf(num));

        // 睡眠60s,锁过期时间30s。每隔20s自动续期
        try {
            TimeUnit.SECONDS.sleep(60);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // 测试可重入性
        // this.testSubLock(uuid);

        // 释放锁
        this.unlock("lock", uuid);
    }
}

3.2.7. 优化之Redlock算法

redis集群状态下的问题:

  1. 客户端A从master获取到锁
  2. 在master将锁同步到slave之前,master宕掉了。
  3. slave节点被晋级为master节点
  4. 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。

安全失效

解决集群下锁失效,参照redis官方网站针对redlock文档:https://redis.io/topics/distlock

在算法的分布式版本中,我们假设有N个Redis服务器。这些节点是完全独立的,因此我们不使用复制或任何其他隐式协调系统。**前几节已经描述了如何在单个实例中安全地获取和释放锁,在分布式锁算法中,将使用相同的方法在单个实例中获取和释放锁。**将N设置为5是一个合理的值,因此需要在不同的计算机或虚拟机上运行5个Redis主服务器,确保它们以独立的方式发生故障。

为了获取锁,客户端执行以下操作:

  1. 客户端以毫秒为单位获取当前时间的时间戳,作为起始时间
  2. 客户端尝试在所有N个实例中顺序使用相同的键名、相同的随机值来获取锁定。每个实例尝试获取锁都需要时间,客户端应该设置一个远小于总锁定时间的超时时间。例如,如果自动释放时间为10秒,则尝试获取锁的超时时间可能在5到50毫秒之间。这样可以防止客户端长时间与处于故障状态的Redis节点进行通信:如果某个实例不可用,尽快尝试与下一个实例进行通信。
  3. 客户端获取当前时间 减去在步骤1中获得的起始时间,来计算获取锁所花费的时间。当且仅当客户端能够在大多数实例(至少3个)中获取锁时,并且获取锁所花费的总时间小于锁有效时间,则认为已获取锁。
  4. 如果获取了锁,则将锁有效时间减去 获取锁所花费的时间,如步骤3中所计算。
  5. 如果客户端由于某种原因(无法锁定N / 2 + 1个实例或有效时间为负)而未能获得该锁,它将尝试解锁所有实例(即使没有锁定成功的实例)。

每台计算机都有一个本地时钟,我们通常可以依靠不同的计算机来产生很小的时钟漂移。只有在拥有锁的客户端将在锁有效时间内(如步骤3中获得的)减去一段时间(仅几毫秒)的情况下终止工作,才能保证这一点。以补偿进程之间的时钟漂移

当客户端无法获取锁时,它应该在随机延迟后重试,以避免同时获取同一资源的多个客户端之间不同步(这可能会导致脑裂的情况:没人胜)。同样,客户端在大多数Redis实例中尝试获取锁的速度越快,出现裂脑情况(以及需要重试)的窗口就越小,因此理想情况下,客户端应尝试将SET命令发送到N个实例同时使用多路复用。

值得强调的是,对于未能获得大多数锁的客户端,尽快释放(部分)获得的锁有多么重要,这样就不必等待锁定期满才能再次获得锁(但是,如果发生了网络分区,并且客户端不再能够与Redis实例进行通信,则在等待密钥到期时需要付出可用性损失)。

3.2.8. 总结

分布式锁三个操作:

  1. 加锁
  2. 解锁
  3. 重试

为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下几个条件:

  • 互斥性。在任意时刻,只有一个客户端能持有锁。
  • 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
  • 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
  • 加锁和解锁必须具有原子性。
  • 实现可重入锁(可选)
  • 为了防止锁失效,锁要具备自动续期
  • 防止集群情况下锁失效,可以使用Redlock

3.3. 分布式锁之Redisson

​ Redisson是一个在Redis的基础上实现的Java驻内存数据网格(In-Memory Data Grid)。它不仅提供了一系列的分布式的Java常用对象,还提供了许多分布式服务。其中包括(BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service) Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离(Separation of Concern),从而让使用者能够将精力更集中地放在处理业务逻辑上。

8.商品分类、缓存及分布式锁(Redisson)_第32张图片

官方文档地址:https://github.com/redisson/redisson/wiki

3.3.1. 快速入门

  1. 引入依赖
<dependency>
    <groupId>org.redissongroupId>
    <artifactId>redissonartifactId>
    <version>3.11.2version>
dependency>
  1. 添加配置
@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient(){
        Config config = new Config();
        // 可以用"rediss://"来启用SSL连接
        config.useSingleServer().setAddress("redis://172.16.116.100:6379");
        return Redisson.create(config);
    }
}
  1. 代码实现
@Autowired
private RedissonClient redissonClient;

@Override
public void testLock() {

    RLock lock = this.redissonClient.getLock("lock"); // 只要锁的名称相同就是同一把锁
    lock.lock(); // 加锁

    // 查询redis中的num值
    String value = this.redisTemplate.opsForValue().get("num");
    // 没有该值return
    if (StringUtils.isBlank(value)) {
        return;
    }
    // 有值就转成成int
    int num = Integer.parseInt(value);
    // 把redis中的num值+1
    this.redisTemplate.opsForValue().set("num", String.valueOf(++num));

    lock.unlock(); // 解锁
}

使用ab压力测试,查看redis内容:

8.商品分类、缓存及分布式锁(Redisson)_第33张图片

3.3.2. 可重入锁(Reentrant Lock)

基于Redis的Redisson分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口。

大家都知道,如果负责储存这个分布式锁的Redisson节点宕机以后,而且这个锁正好处于锁住的状态时,这个锁会出现锁死的状态。为了避免这种情况的发生,Redisson内部提供了一个监控锁的看门狗,它的作用是在Redisson实例被关闭前,不断的延长锁的有效期。默认情况下,看门狗的检查锁的超时时间是30秒钟,也可以通过修改Config.lockWatchdogTimeout来另行指定。

另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。

快速入门使用的就是可重入锁。也是最常使用的锁。

最常见的使用:

RLock lock = redisson.getLock("anyLock");
// 最常使用
lock.lock();


// 加锁以后10秒钟自动解锁
// 无需调用unlock方法手动解锁
lock.lock(10, TimeUnit.SECONDS);


// 尝试加锁,最多等待100秒,上锁以后10秒自动解锁
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
if (res) {
   try {
     ...
   } finally {
       lock.unlock();
   }
}

改造程序:

8.商品分类、缓存及分布式锁(Redisson)_第34张图片

重启后在浏览器测试:

8.商品分类、缓存及分布式锁(Redisson)_第35张图片

在这10s期间,可以在redis客户端看到lock锁的内容:

8.商品分类、缓存及分布式锁(Redisson)_第36张图片

3.3.3. 读写锁(ReadWriteLock)

基于Redis的Redisson分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。其中读锁和写锁都继承了RLock接口。

分布式可重入读写锁允许同时有多个读锁和一个写锁处于加锁状态。

RReadWriteLock rwlock = redisson.getReadWriteLock("anyRWLock");
// 最常见的使用方法
rwlock.readLock().lock();
// 或
rwlock.writeLock().lock();


// 10秒钟以后自动解锁
// 无需调用unlock方法手动解锁
rwlock.readLock().lock(10, TimeUnit.SECONDS);
// 或
rwlock.writeLock().lock(10, TimeUnit.SECONDS);

// 尝试加锁,最多等待100秒,上锁以后10秒自动解锁
boolean res = rwlock.readLock().tryLock(100, 10, TimeUnit.SECONDS);
// 或
boolean res = rwlock.writeLock().tryLock(100, 10, TimeUnit.SECONDS);
...
lock.unlock();

IndexController中的两个方法:

@GetMapping("read")
public ResponseVo<String> read(){
    String msg = indexService.readLock();

    return ResponseVo.ok(msg);
}

@GetMapping("write")
public ResponseVo<String> write(){
    String msg = indexService.writeLock();

    return ResponseVo.ok(msg);
}

IndexService接口方法:注意保证锁的名称一致,才能使用同一把锁

public String readLock() {
    // 初始化读写锁
    RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("readwriteLock");
    RLock rLock = readWriteLock.readLock(); // 获取读锁

    rLock.lock(10, TimeUnit.SECONDS); // 加10s锁

    String msg = this.redisTemplate.opsForValue().get("msg");

    //rLock.unlock(); // 解锁
    return msg;
}

public String writeLock() {
    // 初始化读写锁
    RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("readwriteLock");
    RLock rLock = readWriteLock.writeLock(); // 获取写锁

    rLock.lock(10, TimeUnit.SECONDS); // 加10s锁

    this.redisTemplate.opsForValue().set("msg", UUID.randomUUID().toString());

    //rLock.unlock(); // 解锁
    return "成功写入了内容。。。。。。";
}

打开开两个浏览器窗口测试:

  • 同时访问写:一个写完之后,等待一会儿(约10s),另一个写开始

  • 同时访问读:不用等待

  • 先写后读:读要等待(约10s)写完成

  • 先读后写:写要等待(约10s)读完成

3.3.4. 信号量(Semaphore)和闭锁(CountDownLatch)

基于Redis的Redisson的分布式信号量(Semaphore)Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。

RSemaphore semaphore = redisson.getSemaphore("semaphore");
semaphore.acquire();
//或
semaphore.acquire(23);
semaphore.tryAcquire();
semaphore.tryAcquire(23, TimeUnit.SECONDS);

// 释放资源
semaphore.release();

基于Redisson的Redisson分布式闭锁(CountDownLatch)Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。

RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.trySetCount(1);
latch.await();

// 在其他线程或其他JVM里
RCountDownLatch latch = redisson.getCountDownLatch("anyCountDownLatch");
latch.countDown();

需要两个线程,一个等待。一个计数countDown

演示代码

IndexController:

/**
     * 等待
     * @return
     */
@GetMapping("latch")
public ResponseVo<Object> countDownLatch(){

    String msg = indexService.latch();

    return ResponseVo.ok(msg);
}

/**
     * 计数
     * @return
     */
@GetMapping("out")
public ResponseVo<Object> out(){

    String msg = indexService.countDown();

    return ResponseVo.ok(msg);
}

IndexService:

public String latch() {
    RCountDownLatch countDownLatch = this.redissonClient.getCountDownLatch("countdown");
    try {
        countDownLatch.trySetCount(6);
        countDownLatch.await();

        return "关门了。。。。。";
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return null;
}

public String countDown() {
    RCountDownLatch countDownLatch = this.redissonClient.getCountDownLatch("countdown");

    countDownLatch.countDown();
    return "出来了一个人。。。";
}

重启测试,打开两个页面:当第二个请求执行6次之后,第一个请求才会执行。

8.商品分类、缓存及分布式锁(Redisson)_第37张图片

3.4. 分布式锁 + AOP实现缓存

随着业务中缓存及分布式锁的加入,业务代码变的复杂起来,除了需要考虑业务逻辑本身,还要考虑缓存及分布式锁的问题,增加了程序员的工作量及开发难度。而缓存的玩法套路特别类似于事务,而声明式事务就是用了aop的思想实现的。

8.商品分类、缓存及分布式锁(Redisson)_第38张图片

  1. 以 @Transactional 注解为植入点的切点,这样才能知道@Transactional注解标注的方法需要被代理。
  2. @Transactional注解的切面逻辑类似于@Around

模拟事务,缓存可以这样实现:

  1. 自定义缓存注解@GmallCache(类似于事务@Transactional)
  2. 编写切面类,使用环绕通知实现缓存的逻辑封装

8.商品分类、缓存及分布式锁(Redisson)_第39张图片

定义一个注解:GmallCache

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface GmallCache {

    /**
     * 缓存的前缀
     * @return
     */
    String prefix() default "";

    /**
     * 设置缓存的有效时间
     * 单位:分钟
     * @return
     */
    int timeout() default 5;

    /**
     * 防止雪崩设置的随机值范围
     * @return
     */
    int random() default 5;

    /**
     * 防止击穿,分布式锁的key
     * @return
     */
    String lock() default "lock";
}

定义一个切面类加强注解:

@Aspect
@Component
public class GmallCacheAspect {

    @Autowired
    private StringRedisTemplate redisTemplate;

    @Autowired
    private RedissonClient redissonClient;

    /**
     * joinPoint.getArgs(); 获取方法参数
     * joinPoint.getTarget().getClass(); 获取目标类
     * @param joinPoint
     * @return
     * @throws Throwable
     */
    @Around("@annotation(com.atguigu.gmall.index.config.GmallCache)")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {

        // 获取切点方法的签名
        MethodSignature signature = (MethodSignature)joinPoint.getSignature();
        // 获取方法对象
        Method method = signature.getMethod();
        // 获取方法上指定注解的对象
        GmallCache annotation = method.getAnnotation(GmallCache.class);
        // 获取注解中的前缀
        String prefix = annotation.prefix();
        // 获取方法的参数
        Object[] args = joinPoint.getArgs();
        String param = Arrays.asList(args).toString();
        // 获取方法的返回值类型
        Class<?> returnType = method.getReturnType();

        // 拦截前代码块:判断缓存中有没有
        String json = this.redisTemplate.opsForValue().get(prefix + param);
        // 判断缓存中的数据是否为空
        if (StringUtils.isNotBlank(json)){
            return JSON.parseObject(json, returnType);
        }

        // 没有,加分布式锁
        String lock = annotation.lock();
        RLock rLock = this.redissonClient.getLock(lock + param);
        rLock.lock();

        // 判断缓存中有没有,有直接返回(加锁的过程中,别的请求可能已经把数据放入缓存)
        String json2 = this.redisTemplate.opsForValue().get(prefix + param);
        // 判断缓存中的数据是否为空
        if (StringUtils.isNotBlank(json2)){
            rLock.unlock();
            return JSON.parseObject(json2, returnType);
        }

        // 执行目标方法
        Object result = joinPoint.proceed(joinPoint.getArgs());

        // 拦截后代码块:放入缓存 释放分布锁
        int timeout = annotation.timeout();
        int random = annotation.random();
        this.redisTemplate.opsForValue().set(prefix + param, JSON.toJSONString(result), timeout + new Random().nextInt(random), TimeUnit.MINUTES);
        rLock.unlock();

        return result;
    }
}

在IndexServiceImpl的querySubCategories方法中使用注解,完成数据缓存功能:

@GmallCache(prefix = "index:cates:", timeout = 14400, random = 3600, lock = "lock")
public List<CategoryEntity> queryLvl2CategoriesWithSub(Long pid) {

    ResponseVo<List<CategoryEntity>> listResp = this.gmallPmsFeign.querySubCategory(pid);
    List<CategoryEntity> categoryVOS = listResp.getData();

    return categoryVOS;
}

该方法的实现只需要考虑业务逻辑本身,使用注解即可完成缓存功能。

测试:

8.商品分类、缓存及分布式锁(Redisson)_第40张图片

你可能感兴趣的:(电商项目)