尚品汇-（二十）

一：商品详情页面优化

（1）思路

（2）整合redis到工程

（3）使用redis进行业务开发相关规则

（4）缓存常见问题

二：分布式锁

本地锁的局限性

（1）并发请求Redis的问题

（2）本地锁解决

（3）集群下，并发访问Reids

（4）分布式锁实现的解决方案

一：商品详情页面优化

（1）思路

页面一些固定的不长变的数据需要存入缓存，像价格长变的数据就需要实时查询数据库

虽然咱们实现了页面需要的功能，但是考虑到该页面是被用户高频访问的，所以性能需要优化。

一般一个系统最大的性能瓶颈，就是数据库的io操作。从数据库入手也是调优性价比最高的切入点。

一般分为两个层面，一是提高数据库sql本身的性能，二是尽量避免直接查询数据库。

重点要讲的是另外一个层面：尽量避免直接查询数据库。

解决办法就是：缓存

（2）整合redis到工程

由于redis作为缓存数据库，要被多个项目使用，所以要制作一个通用的工具类，方便工程中的各个模块使用。

而主要使用redis的模块，都是后台服务的模块，service工程。所以咱们把redis的工具类放到service-util模块中，这样所有的后台服务模块都可以使用redis。

首先在service-util引入依赖包

<!-- redis -->
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

<!-- spring2.X集成redis所需common-pool2-->
<dependency>
   <groupId>org.apache.commons</groupId>
   <artifactId>commons-pool2</artifactId>
   <version>2.6.0</version>
</dependency>

添加redis配置类

package com.atguigu.gmall.common.config

@Configuration
@EnableCaching
public class RedisConfig {

    @Bean
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<Object, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory);
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(objectMapper);

        // 序列号key value
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(jackson2JsonRedisSerializer);
        redisTemplate.setHashKeySerializer(new StringRedisSerializer());
        redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer);

        redisTemplate.afterPropertiesSet();
        return redisTemplate;
    }

}

说明：由于service-util属于公共模块，所以我们把它引入到service父模块，其他service子模块都自动引入了

（3）使用redis进行业务开发相关规则

开始开发先说明redis key的命名规范，由于Redis不像数据库表那样有结构，其所有的数据全靠key进行索引，所以redis数据的可读性，全依靠key。

企业中最常用的方式就是：object:id:field

比如：sku:1314:info

user:1092:info

:表示根据windows的 /一个意思

重构getSkuInfo方法

在RedisConst中定义redis的常量，RedisConst类在service-util模块中，所有的redis常量我们都配置在这里

package com.atguigu.gmall.common.constant;

/**
 * Redis常量配置类
 *
 */
public class RedisConst {

    public static final String SKUKEY_PREFIX = "sku:";
    public static final String SKUKEY_SUFFIX = ":info";
    //单位：秒
       public static final long SKUKEY_TIMEOUT = 24 * 60 * 60;

}

如何使用缓存：

以上基本实现使用缓存的方案。

（4）缓存常见问题

缓存最常见的3个问题：面试

1. 缓存穿透

2. 缓存雪崩

3. 缓存击穿

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

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

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

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

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

与缓存雪崩的区别：

1. 击穿是一个热点key失效

2. 雪崩是很多key集体失效

解决：锁

二：分布式锁

本地锁的局限性

（1）并发请求Redis的问题

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

在service-product中的TestController中添加测试方法

父模块中引入了util 也引用了Redis的依赖了，主启动类也进行了扫描，可以扫描到Redis的配置类

package com.atguigu.gmall.product.controller;


@Api(tags = "测试接口")
@RestController
@RequestMapping("admin/product/test")
public class TestController {
    
    @Autowired
    private TestService testService;

    @GetMapping("testLock")
    public Result testLock() {
        testService.testLock();
        return Result.ok();
    }
}

接口

package com.atguigu.gmall.product.service;

public interface TestService {

   void testLock();

}

实现类

package com.atguigu.gmall.product.service.impl;
@Service
public class TestServiceImpl implements TestService {

   @Autowired
   private StringRedisTemplate redisTemplate;
   @Override
   public void testLock() {
      // 查询redis中的num值
      String value = (String)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));
   }
}

说明：通过reids客户端设置num=0

多刷新几次：

使用ab工具测试

使用ab测试工具：httpd-tools（yum install -y httpd-tools）

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

测试如下：5000请求，100并发

ab -n 5000 -c 100 http://192.168.254.1:8206/admin/product/test/testLock

在服务器访问本地的ip相当于localhost

按理说5000个请求，Reids会变成5000

由于并发，可能请求先读取的0，由于一个请求改为1后，另外一个请求由于读取的是0又改为了1，导致最终的结果不是5000

（2）本地锁解决

怎么解决这个问题呢？加锁

@Override
public synchronized void testLock() {
   // 查询redis中的num值
   String value = (String)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));
}

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

加了锁之后效率变低了，速度变慢了

完美！与预期一致，是否真的完美？

（3）集群下，并发访问Reids

接下来再看集群情况下，会怎样？

接下来启动8206 8216 8226 三个运行实例。

运行多个service-product实例：

server.port=8216

server.port=8226

注意：bootstrap.properties 添加一个server.port = 8206; 将nacos的配置注释掉！

通过网关压力测试：

启动网关：没有端口，默认访问80，是网关服务

ab -n 5000 -c 100 http://192.168.200.1/admin/product/test/testLock

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

以上测试，可以发现：

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

此时需要分布式锁。

（4）分布式锁实现的解决方案

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

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

1. 基于数据库实现分布式锁

2. 基于缓存（Redis等）

3. 基于Zookeeper

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

1. 性能：redis最高

2. 可靠性：zookeeper最高

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