【43-本地锁-分布式锁概念原理-分布式锁解决方案-Redis实现分布式锁-Redisson分布式锁-项目整合Redisson-缓存数据一致性问题-解决缓存一致性的方案-SpringCache缓存】
一.知识回顾
【0.三高商城系统的专题专栏都帮你整理好了，请点击这里！】
【1-系统架构演进过程】
【2-微服务系统架构需求】
【3-高性能、高并发、高可用的三高商城系统项目介绍】
【4-Linux云服务器上安装Docker】
【5-Docker安装部署MySQL和Redis服务】
【6-Git安装与配置过程、Gitee码云上创建项目、IDEA关联克隆的项目】
【7-创建商城系统的子模块并将修改后的信息使用Git提交到Gitee上】
【8-数据库表结构的创建&后台管理系统的搭建】
【9-前端项目的搭建部署、Node安装、VSCode安装】
【10-Node的安装以及全局环境变量的相关配置&解决启动报错的问题(1.Error: Cannot find module ‘fs/promises)(2.npm安装node-sass报错)】
【11-导入人人generator项目并自动生成相关的文件&商品子模块的调试&公共模块common子模块的抽离与实现&Lombok插件的安装】
【12-商品子模块整合MyBatisPlus技术&其它模块通过generator的自动生成与补充完善】
【13-项目中微服务组件的学习-SpringCloudAlibaba微服务生态体系的学习&SpringCloudAlibaba的依赖管理&项目中SpringBoot和SpringCloud版本的统一】
【14-微服务的注册中心与配置中心Nacos&Windows操作系统上安装Nacos和Linux操作系统上用Docker中安装Nacos&每个子项目模块使用Nacos进行服务注册与发现】
【15-项目中服务的远程调用之OpenFeign&订单模块与商品模块集成使用OpenFeign的案例】
【16-配置中心之Nacos的基本使用&Nacos服务之命令空间、Nacos服务之配置组、Nacos服务之配置拆分】
【17-微服务网关之Spring Cloud Gateway&Spring Cloud Gateway网关服务搭建】
【18-业务开发-基础业务-商品模块-分类管理-前后端管理系统的启动-为分类管理表增加数据-Json插件的下载-返回具有层级目录、父子关系结构的数据】
【19-业务开发-基础业务-商品模块-分类管理-管理系统新建菜单-后端项目renren注册到Nacos注册中心和配置中心去-项目gateway网关模块的搭建-浏览器的同源策略与解决跨域问题实操案例】
【20-业务开发-基础业务-商品模块-分类管理-前端展示后端具有层级关系的目录数据-商品系统三级分类的逻辑删除前后端代码实现】
【21-业务开发-基础业务-商品模块-分类管理-商品系统三级分类的新增类别前后端代码实现-商品系统三级分类的更新类别前后端代码实现-之前错误的Bug修正】
【22-业务开发-基础业务-商品模块-分类管理-商品系统三级分类拖拽页面的功能-前后端代码的逻辑实现-访问测试-拖拽开关的开启和关系-批量更新拖拽数据-批量删除选定数据】
【23-业务开发-基础业务-品牌管理-品牌管理项目搭建-品牌管理实现的增删改查操作测试-后端数据显示状态使用前端组件开关按钮展示-以及数据处理以及测试】
【24-业务开发-基础业务-品牌管理-图片管理-阿里云OSS服务开通和使用-阿里云OSS服务API使用-SpringCloudAlibaba OSS服务的使用】
【25-业务开发-基础业务-品牌管理-图片管理-图片上传方式的三种实现方式-第三方公共服务模块集成到项目中-服务端生成签名实战】
【26-业务开发-基础业务-品牌管理-图片管理-上传图片功能实现-基于阿里云OSS服务-解决跨域问题-设置跨域规则-修改ACL权限为公共读】
【27-业务开发-基础业务-品牌管理-图片管理-添加修改品牌信息并显示图片-前端数据校验-后端数据JSR303校验实现-统一异常处理-自定义响应编码规则-分组校验-自定义校验注解-项目Bug解决】
【28-业务开发-基础业务-属性管理-SKU和SPU基本概念-SKU和SPU关联关系-属性实体之间的关联关系-批量菜单创建】
【29-业务开发-基础业务-属性管理-属性组业务逻辑开发-页面布局-三级分类组件功能-属性组表单-父子组件传值-属性组数据展示-属性组数据添加-属性组数据修改-前后端项目整合交互测试】
【30-业务开发-基础业务-品牌管理-分类维护-解决分类维护业务开发中的一个Bug-品牌管理-分页插件-分页功能的逻辑实现-品牌管理-检索条件模糊查询品牌管理-增加更新操作中排序字段检验还是存在问题】
【31-业务开发-基础业务-品牌管理-级联类别信息业务功能实现-品牌管理和商品分类管理俩者业务关联出现数据冗余，导致数据不同步的问题-开启事务-项目测试】
【32-业务开发-基础业务-规格参数-保存数据-查询数据-更新操作之数据回显展示-更新操作-前后端项目交互整合与测试-总结收获】
【33-业务开发-基础业务-规格参数-销售属性-多表之间的关联增删改查操作-前后端项目交互整合与测试-Cannot read property ‘publish‘ of undefined】
【34-业务开发-基础业务-属性组和基本属性-属性组和基本属性建立关联-属性组和基本属性解除关联-未关联属性查询-确认新增】
【35-业务开发-基础业务-商品服务-新增商品-会员模块服务-mall-member-会员模块数据维护-规格参数维护-前端项目Bug解决-PubSub依赖缺失】
【36-业务开发-基础业务-商品服务SPU-前后端处理商品数据Json-发布商品前后端业务逻辑-feign服务远程调用-DTO数据传输对象-商品服务的检索-商品管理的检索项目中修改更正完善逻辑操作】
【37-业务开发-基础业务-库存管理- 仓库模块Nacos注册中心的配置-Gateway网关配置-仓库维护的增删改查-商品库存管理-采购流程-采购需求维护-采购需求合并-领取采购单完成采购操作】
【插入------>ElasticSearch专栏相关的知识内容都整理好了，在这里哟！】
【38-商品上架功能结合ElasticSearch全文检索的流程-商品ES关系映射模型&Docker安装ik分词器-实现上架功能复杂的逻辑实现-Postman+Kibana访问测试】
【39-商品整合thymeleaf模板引擎-商城用户端的实现逻辑-部署devtools工具依赖-商品后台-三级分类逻辑分析实现-Docker 安装部署Nginx-Nginx对网关实现反向代理负载均衡】
【40-系统性能压力测试基本概念-相关性能指标HPS&TPS&QPS&RT-安装Jmeter教程-JMeter测试流程-线程组-取样器-监视器-测试商城首页-JMeter Address 占用的问题】
【41-系统性能压力测试优化-JVM知识回顾-jconsole和jvisualvm-jvisualvm安装Visual GC插件-Nginx压力测试- 网关gateway压测-Nginx实现动静分离】
【42-缓存的基本概念-是否使用缓存的场景-本地缓存-分布式缓存-项目中整合Redis-修改三级分类逻辑代码+加入缓存-三级分类加入缓存后压力测试-缓存穿透-缓存雪崩-缓存击穿】
二.本地锁的局限&分布式锁原理
2.1 本地锁的局限
本地锁在分布式环境下，是没有办法锁住其他节点的操作的，这种情况肯定是有问题的
2.2 本地锁到分布式锁的演进
针对本地锁的问题，我们需要通过分布式锁来解决，那么是不是意味着本身锁在分布式场景下就不需要了呢？
一个业务网逻辑模块发出很多个请求，而我们使用本地锁是为了让多个请求最后只有一个请求去和其它更少的资源去竞争请求分布式锁
显然不是这样的，因为如果分布式环境下的每个节点不控制请求的数量，那么分布式锁的压力会非常大，这时我们需要本地锁来控制每个节点的同步，来降低分布式锁的压力，所以实际开发中我们都是本地锁和分布式锁结合使用的。
2.3 分布式锁的原理
分布式锁或者本地锁的本质其实是一样的，都是将并行的操作转换为了串行的操作
三.分布式锁的常用解决方案
3.1 数据库
可以利用MySQL隔离性：唯一索引
use test;
CREATE TABLE `DistributedLock` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁名',
`desc` varchar(1024) NOT NULL DEFAULT '备注信息',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';
//数据库中的每一条记录就是一把锁，利用的mysql唯一索引的排他性
lock(name,desc){
insert into DistributedLock(`name`,`desc`) values (#{name},#{desc});
}
unlock(name){
delete from DistributedLock where name = #{name}
}
可以利用拍他说来实现 select … where … for update;
乐观锁：乐观的任务数据不会出现数据安全问题，如果出现了就重试一次
select ...,version;
update table set version+1 where version = xxx
3.2 Redis&Redisson
下面会详细介绍Redis和Redisson实战场景，此处不做过多解释。
- Redis:setNX: setNX(key,value) :如果key不存在那么就添加key的值，否则添加失败
- Redisson：Redisson实现分布式锁框架
3.3 Zookeeper
创建的临时有序节点中每次只有最小的去获取锁，业务逻辑成功后，释放锁，然后下一个节点监听到了做出香瓜的改变。
四.Redis实现分布式锁
在Redis中是通过setNX指令来实现锁的抢占，那么利用这个命令实现分布式锁的基础代码为：
public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
String keys = "catalogJSON";
// 加锁
Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111");
if(lock){
// 加锁成功
Map<String, List<Catalog2VO>> data = getDataForDB(keys);
// 从数据库中获取数据成功后，我们应该要释放锁
stringRedisTemplate.delete("lock");
return data;
}else{
// 加锁失败
// 休眠+重试
// Thread.sleep(1000);
return getCatelog2JSONDbWithRedisLock();
}
}
上面的代码其实是存在一些问题的，首先如果getDataForDB(keys)这个方法如果出现的异常，那么我们就不会删除该key也就是不会释放锁，从而造成了死锁，针对这个问题，我们可以通过设置过期时间来解决，具体代码如下：
public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
String keys = "catalogJSON";
// 加锁
Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111");
if(lock){
// 给对应的key设置过期时间
stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
// 加锁成功
Map<String, List<Catalog2VO>> data = getDataForDB(keys);
// 从数据库中获取数据成功后，我们应该要释放锁
stringRedisTemplate.delete("lock");
return data;
}else{
// 加锁失败
// 休眠+重试
// Thread.sleep(1000);
return getCatelog2JSONDbWithRedisLock();
}
}
上面虽然解决了getDataForDB方法出现异常的问题，但是如果在expire方法执行之前就中断呢？这样也会出现我们介绍的死锁的问题，那这个问题怎么办？这时我们就希望setNx和设置过期时间的操作能够保证原子性。
这时我们就可以在setIfAbsent方法中同时指定过期时间，保证这个原子性的行为
public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
String keys = "catalogJSON";
// 加锁 在执行插入操作的同时设置了过期时间
Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111",30,TimeUnit.SECONDS);
if(lock){
// 给对应的key设置过期时间
stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
// 加锁成功
Map<String, List<Catalog2VO>> data = getDataForDB(keys);
// 从数据库中获取数据成功后，我们应该要释放锁
stringRedisTemplate.delete("lock");
return data;
}else{
// 加锁失败
// 休眠+重试
// Thread.sleep(1000);
return getCatelog2JSONDbWithRedisLock();
}
}
如果获取锁的业务执行时间比较长，超过了我们设置的过期时间，那么就有可能业务还没执行完，锁就释放了，然后另一个请求进来了，并创建了key，这时原来的业务处理完成后，再去删除key的时候，那么就有可能删除别人的key，这时怎么办?针对这种情况我们可以查询的锁的信息通过UUID来区分，具体的代码如下：
public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
String keys = "catalogJSON";
// 加锁 在执行插入操作的同时设置了过期时间
String uuid = UUID.randomUUID().toString();
Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", uuid,30,TimeUnit.SECONDS);
if(lock){
// 给对应的key设置过期时间
stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
// 加锁成功
Map<String, List<Catalog2VO>> data = getDataForDB(keys);
// 获取当前key对应的值
String val = stringRedisTemplate.opsForValue().get("lock");
if(uuid.equals(val)){
// 说明这把锁是自己的
// 从数据库中获取数据成功后，我们应该要释放锁
stringRedisTemplate.delete("lock");
}
return data;
}else{
// 加锁失败
// 休眠+重试
// Thread.sleep(1000);
return getCatelog2JSONDbWithRedisLock();
}
}
上面查询key的值和删除key其实不是一个原子性操作，这就会出现我查询出来key之后，时间过期了，然后key被删除了，然后其他的请求创建了一个新的key，然后原来的执行删除了这个key，又出现了删除别人key的情况。这时我们需要保证查询和删除是一个原子性行为。
public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
String keys = "catalogJSON";
// 加锁 在执行插入操作的同时设置了过期时间
String uuid = UUID.randomUUID().toString();
Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", uuid,300,TimeUnit.SECONDS);
if(lock){
Map<String, List<Catalog2VO>> data = null;
try {
// 加锁成功
data = getDataForDB(keys);
}finally {
String srcipts = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end ";
// 通过Redis的lua脚本实现 查询和删除操作的原子性
stringRedisTemplate.execute(new DefaultRedisScript<Integer>(srcipts,Integer.class)
,Arrays.asList("lock"),uuid);
}
return data;
}else{
// 加锁失败
// 休眠+重试
// Thread.sleep(1000);
return getCatelog2JSONDbWithRedisLock();
}
}
五.Redisson分布式锁
5.1 Redisson的整合
添加对应的依赖
<dependency>
<groupId>org.redissongroupId>
<artifactId>redissonartifactId>
<version>3.16.1version>
dependency>
添加对应的配置类
@Configuration
public class MyRedisConfig {
@Bean
public RedissonClient redissonClient(){
Config config = new Config();
// 配置连接的信息
config.useSingleServer().setAddress("redis://IP地址:6379");
RedissonClient redissonClient = Redisson.create(config);
return redissonClient;
}
}
5.2 可重入锁
5.2.1 可重入锁进行加锁是否设置过期时间重载方法的解析
- 如果我们指定了锁的过期时间，那么在源码中会直接帮我们创建一个过期时间是指定值的锁，时间到期后就会直接把该锁给删除
- 如果我们没有指定过期时间，那么在执行的时候首先会创建一把锁且过期时间是30s然后会创建异步任务，每个10s执行一次任务来续期
5.2.2 可重入锁进行加锁不设置过期时间
- 锁会自动续期，如果业务时间超长，运行期间Redisson会自动给锁重新添加30s，不用担心业务时间，锁自动过去而造成的数据安全问题
- 加锁的业务只要执行完成， 那么就不会给当前的锁续期，即使我们不去主动的释放锁，锁在默认30s之后也会自动的删除
@ResponseBody
@GetMapping("/hello")
public String hello(){
RLock myLock = redissonClient.getLock("myLock");
// 加锁
myLock.lock();
try {
System.out.println("加锁成功...业务处理....." + Thread.currentThread().getName());
Thread.sleep(30000);
}catch (Exception e){
}finally {
System.out.println("释放锁成功..." + Thread.currentThread().getName());
// 释放锁
myLock.unlock();
}
return "hello";
}
5.2.3 可重入锁进行加锁设置过期时间
- 指定了过期时间后那么自动续期就不会生效了，这时我们就需要注意设置的过期时间一定要满足我们的业务场景
- 但是实际开发中我们最好指定过期时间–>性能角度考虑
5.3 读写锁
- 根据业务操作我们可以分为读写操作，读操作其实不会影响数据，那么如果还对读操作做串行处理，效率会很低，这时我们可以通过读写锁来解决这个问题。
- 读 读 ： 相对于没有加锁
写 读 ： 需要等待写锁释放
写 写 ： 阻塞的方式
读 写 ： 读数据的时候也会添加锁，那么写的行为也会阻塞 - 在读写锁中，只有读读的行为是共享锁，相互之间不影响，只要有写的行为存在，那么就是一个互斥锁(排他锁)
@GetMapping("/writer")
@ResponseBody
public String writerValue(){
RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
// 加写锁
RLock rLock = readWriteLock.writeLock();
String s = null;
rLock.lock(); // 加写锁
try {
s = UUID.randomUUID().toString();
stringRedisTemplate.opsForValue().set("msg",s);
Thread.sleep(30000);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
rLock.unlock();
}
return s;
}
@GetMapping("/reader")
@ResponseBody
public String readValue(){
RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
// 加读锁
RLock rLock = readWriteLock.readLock();
rLock.lock();
String s = null;
try {
s = stringRedisTemplate.opsForValue().get("msg");
}finally {
rLock.unlock();
}
return s;
}
5.4 闭锁
基于Redisson的Redisson分布式闭锁（CountDownLatch）Java对象 RCountDownLatch采用了与 java.util.concurrent.CountDownLatch相似的接口和用法。
@GetMapping("/lockDoor")
@ResponseBody
public String lockDoor(){
RCountDownLatch door = redissonClient.getCountDownLatch("door");
door.trySetCount(5);
try {
door.await(); // 等待数量降低到0
} catch (InterruptedException e) {
e.printStackTrace();
}
return "关门熄灯...";
}
@GetMapping("/goHome/{id}")
@ResponseBody
public String goHome(@PathVariable Long id){
RCountDownLatch door = redissonClient.getCountDownLatch("door");
door.countDown(); // 递减的操作
return id + "下班走人";
}
5.5 信号量(Semaphore)
基于Redis的Redisson的分布式信号量（Semaphore）Java对象
RSemaphore采用了与 java.util.concurrent.Semaphore相似的接口和用法。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。
@GetMapping("/park")
@ResponseBody
public String park(){
RSemaphore park = redissonClient.getSemaphore("park");
boolean b = true;
try {
// park.acquire(); // 获取信号 阻塞到获取成功
b = park.tryAcquire();// 返回获取成功还是失败
} catch (Exception e) {
e.printStackTrace();
}
return "停车是否成功:" + b;
}
@GetMapping("/release")
@ResponseBody
public String release(){
RSemaphore park = redissonClient.getSemaphore("park");
park.release();
return "释放了一个车位";
}
六.缓存数据一致性问题
目前一般主流系统使用redis+mysql来保证高并发高性能。那么不可避免的会遇到缓存双写一致性问题—即缓存和数据库数据不一致。
6.1 双写模式
双写模式：就是写完数据库之后再去写缓存，保持缓存一致性；
存在的问题:
双写模式存在的问题:当一个请求写完数据库后，还没有更新缓存，此时又来了一个请求，直接写了数据库，并且立刻写了缓存，完成后，此时轮到了第一个请求写缓存数据，此时将第二个请求的缓存数据直接修改了。此时存在脏数据的问题，但是当我们设置的key的缓存事件过期后，又会重新拉取最新的数据进行覆盖。
6.2 失效模式
失效模式：简言之就是写完数据库，不用写缓存，而是删缓存，等有请求进来读数据的时候，缓存中没有，就会查数据库，然后主动放到缓存里面。也叫触发主动更新；
存在的问题一：删除缓存失败，导致Redis和mysql的数据不一致。
存在的问题二：删除缓存成功，但mysql主从时延问题，导致读操作回源时出现数据不一致
6.3 解决缓存一致性的方案
- 缓存的所有数据我们都加上过期时间，数据过期之后主动触发更新操作
- 使用读写锁来处理，读读的操作是不相互影响的
无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？
- 如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
- 如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。
- 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
- 通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略）
总结：
- 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。
- 我们不应该过度设计，增加系统的复杂性
- 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。
七.SpringCache
SpringCache官方网站参考手册
7.1 整合SpringCache
pom文件中导入依赖
配置文件中设置相关的信息
主启动类中加入放开缓存的注解
7.2 缓存注解应用
SpringCache的原理
CacheAutoConfiguration–》根据指定的spring.cache.type=reids会导入 RedisCacheAutoConfiguration
下面就是SpringCache缓存的解决方案，只需要通过这几个注解就可以完成缓存的操作，从而和具体的缓存实现解耦的操作。
触发缓存的保存操作
@Cacheable: Triggers cache population.
更新操作触发数据从缓存中删除的操作
@CacheEvict: Triggers cache eviction.
在不影响方法执行的操作下更新缓存
@CachePut: Updates the cache without interfering with the method execution.
上下注解的组合操作
@Caching: Regroups multiple cache operations to be applied on a method.
在类级别共享缓存的相关数据
@CacheConfig: Shares some common cache-related settings at class-level.
7.2.1 @Cacheable缓存注解使用注意事项
@Cacheable({“catagory”,“product”})
在注解中我们可以指定对应的缓存的名称，起到一个分区的作用，一般按照业务来区分@Cacheable({“catagory”,“product”}) 代表当前的方法的返回结果是需要缓存的，调用该方法的时候，如果缓存中有数据，那么该方法就不会执行，如果缓存中没有数据，那么就执行该方法并且把查询的结果缓存起来。
7.2.2 缓存处理
- 存储在Redis中的缓存数据的Key是默认生成的：缓存名称::SimpleKey[]
- 默认缓存的数据的过期时间是-1永久
- 缓存的数据，默认使用的是jdk的序列化机制
7.2.3 缓存改进：
-
生成的缓存数据我们需要指定自定义的key： key属性来指定，可以直接字符串定义也可以通过SPEL表达式处理：#root.method.name
-
指定缓存数据的存活时间: spring.cache.redis.time-to-live 指定过期时间
spring:
cache:
redis:
time-to-live: 60000 # 指定缓存key的过期时间
- 把缓存的数据保存为JSON数据,通过我们自定义配置对象来自定义序列化对象的方式
7.2.4 @CacheEvict缓存注解使用注意事项
@CacheEvict：在更新数据的时候同步删除缓存中的数据
@CacheEvict(value = “catagory”,key=“‘getLeve1Category’”)，更新数据时候删除catagory分区下key是getLeve1Category的数据
@CacheEvict(value = “catagory”,allEntries = true) 表示删除catagory分区下的所有的缓存数据–方式一
@Caching(evict = {
@CacheEvict(value = “catagory”,key=“‘getLeve1Category’”)
,@CacheEvict(value = “catagory”,key=“‘getCatelog2JSON’”)
})，如果想要有选择的清除catagory分区下的缓存数据应该使用上面这种方法—方式二
7.3 SpringCache缓存总结
1).读模式
- 缓存穿透：查询一个null的数据。可以解决 cache-null-values=true
- 缓存击穿:大量并发进来同时查询一个正好过期的数据。解决方案：分布式锁 sync=true 本地锁
- 缓存雪崩：大量的key同一个时间点失效。解决方案：添加过期时间 time-to-live=60000 指定过期时间
2).写模式
- 读写锁
- 引入canal，监控binlog日志文件来同步更新数据
- 读多写多，直接去数据库中读取数据即可
总结：
- 常规数据(读多写少)：而且对及时性和数据的一致性要求不高的情况，我们完全可以使用SpringCache
- 特殊情况：特殊情况特殊处理。
好了，关于【43-本地锁-分布式锁概念原理-分布式锁解决方案-Redis实现分布式锁-Redisson分布式锁-项目整合Redisson-缓存数据一致性问题-解决缓存一致性的方案-SpringCache缓存】就先学习到这里，更多的内容持续学习中，敬请期待。