目录：
一：商品详情页面优化
（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 {@Beanpublic 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 valueredisTemplate.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 {@Autowiredprivate 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 {@Autowiredprivate StringRedisTemplate redisTemplate;@Overridepublic void testLock() {// 查询redis中的num值String value = (String)this.redisTemplate.opsForValue().get("num");// 没有该值returnif (StringUtils.isBlank(value)){return ;}// 有值就转成成intint num = Integer.parseInt(value);// 把redis中的num值+1this.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");// 没有该值returnif (StringUtils.isBlank(value)){return ;}// 有值就转成成intint num = Integer.parseInt(value);// 把redis中的num值+1this.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实现分布式锁。