Redis6总纲
文档
https://github.com/redisson/redisson/wiki/Table-of-Content
JUC
学过juc可以和 redission 无缝衔接
https://www.jianshu.com/p/aa02b491afba
目录
1、构建项目
2、看门狗原理如何解决死锁
3、读写锁
4、信号量
5、闭锁
6、分布式锁解决缓存一致性问题
概述
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），从而让使用者能够将精力更集中地放在处理业务逻辑上。
一、项目搭建
1、坐标引入
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.12.0</version>
</dependency>
2、配置
单节点配置
package com.kk.springbootredis.config;
import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.io.IOException;
@Configuration
public class RedissonConfig {
/*
* @Description: 所有对 Redisson的使用都是通过 RedissonClient对象
* @Author: 阿K
* @CreateDate: 2021/12/16 21:34
* @Param: []
* @Return: org.redisson.api.RedissonClient
**/
@Bean(destroyMethod = "shutdown")
RedissonClient redisson() throws IOException {
// 1、创建配置
Config config = new Config ( );
config.useSingleServer ().setAddress ("redis://106.52.23.202:6379");
// 集群模式
// useClusterServers ( )
//.addNodeAddress ("redis://127.0.0.1:7004", "redis://127.0.0.1:7001");
// 密码设置
//.setPassword ("abc123456");
// 2、根据 Config 实例创建出 RedissonClient 对象
return Redisson.create (config);
}
}
以下两种为官网提供的参考：
1、单节点
// 默认连接地址 127.0.0.1:6379
RedissonClient redisson = Redisson.create();
Config config = new Config();
config.useSingleServer().setAddress("myredisserver:6379");
RedissonClient redisson = Redisson.create(config);
2、集群
Config config = new Config();
config.useClusterServers()
.setScanInterval(2000) // 集群状态扫描间隔时间，单位是毫秒
//可以用"rediss://"来启用SSL连接
.addNodeAddress("redis://127.0.0.1:7000", "redis://127.0.0.1:7001")
.addNodeAddress("redis://127.0.0.1:7002");
RedissonClient redisson = Redisson.create(config);
二、第一个Demo
官网：
1、第一个 demo
@Controller
public class TestRedissonClient {
@Autowired
RedissonClient redisson;
@ResponseBody
@GetMapping("/hello")
public String hello(){
// 1、获取一把锁，只要锁的名字一样，既是同一把锁
RLock lock = redisson.getLock ("my-lock");
// 2、加锁
lock.lock ();// 阻塞式等待
try {
System.out.println ("加锁成功，执行业务..."+Thread.currentThread ().getId () );
// 模拟超长等待
Thread.sleep (20000);
} catch (Exception e) {
e.printStackTrace ( );
}finally {
// 3、解锁
System.out.println ("释放锁..."+Thread.currentThread ().getId () );
lock.unlock ();
}
return "hello";
}
}
发送两个请求
打印结果
加锁成功，执行业务...80
释放锁...80
加锁成功，执行业务...81
释放锁...81
二、看门狗原理
1、模拟两个服务，A服务闪掉还没释放锁的情况
A服务先运行，在运行B服务，还没释放A的是否，A就挂了，锁也还没释放，会不会死锁呢？？
启动两台，8080，8081（闪断--手动关闭）
发现80没有因为81没有释放而导致死锁，因为底层有看门狗机制。
追溯源码：自旋，不断尝试获取锁
2、默认 lock() 小结
（1）默认指定锁时间为30s（看门狗时间）
（2）锁的自动续期：若是业务超长，运行期间自动给锁上新的 30s，不用担心业务时间过长，锁就自动过期
（3）加锁的业务只要运行完成，就不会给当前锁续期，及时不手动解锁，锁默认在30s 后自动删除。
3、指定时间 lock() --- 【推荐写法】
// 10s自动解锁，指定时间一定要大于业务时间（不然会报错，没把握就不要用）
lock.lock (10, TimeUnit.SECONDS);
4、指定时间 lock() 小结
问题：在锁到的时候，不会自动续期。
（1）如果我们传递了锁的超时时间，就发送给 redis执行脚本，进行占锁，默认的超时时间既我们指的时间
（2）若是未指定锁的超时时间，就使用 30*1000【LockWatchdogTimeout看门狗的默认时间】
（3）只要占锁成功，就会启动一个定时任务【重新给锁设置过期时间，新的过期时间就是看门狗的默认时间】，每隔 10 s都会自动再次续到30s, internallockLeaseTime【看门狗时间/3s】
三、读写锁
1、代码
@Autowired
RedissonClient redisson;
@Autowired
RedisTemplate redisTemplate;
// 并发写测试
@GetMapping("write")
@ResponseBody
public String writeValue(){
RReadWriteLock myLock = redisson.getReadWriteLock ("my_lock");
RLock rLock = myLock.writeLock ( );
rLock.lock ();
String s = "";
try {
System.out.println ("写锁加锁成功..."+Thread.currentThread ().getId () );
s= UUID.randomUUID ().toString ();
TimeUnit.SECONDS.sleep (30);
redisTemplate.opsForValue ().set ("writeValue",s);
} catch (Exception e) {
e.printStackTrace ( );
}
finally {
System.out.println ("写锁解锁成功..."+Thread.currentThread ().getId () );
rLock.unlock ();
}
return s;
}
// 并发读测试
@GetMapping("read")
@ResponseBody
public String readValue(){
RReadWriteLock myLock = redisson.getReadWriteLock ("my_lock");
RLock rLock = myLock.readLock ( );
rLock.lock ();
String s = "";
try {
System.out.println ("读锁加锁成功..."+Thread.currentThread ().getId () );
s = (String) redisTemplate.opsForValue ().get ("writeValue");
} catch (Exception e) {
e.printStackTrace ( );
}finally {
System.out.println ("读锁解锁成功..."+Thread.currentThread ().getId () );
rLock.unlock ();
}
return s;
}
2、结论
保证一定能读到最新数据，修改期间，写锁是一个排它锁（互斥锁）。读锁是一个共享锁
（1）读+读：相当于无锁，并发读情况下，只会在 redis 中记录好，所有当前的读锁，他们都会加锁成功。
（2）写+读：等待写锁释放
（3）写+写：阻塞方式
（4）读+写：有读锁，写也需要等待
只要有写的存在，都必须等待
四、信号量
/**
* 车库停车：
* 信号量也可以做分布式限流
* @return
*/
@GetMapping("/park")
public String park()throws Exception{
RSemaphore park = redisson.getSemaphore ("park");
// 获取一个信号，获取一个值，占一个车位
//park.acquire ();
//park.acquire (23);// 占用23个
// 如果有数量则占用，没有则失败
boolean b = park.tryAcquire ( );
if (b){
// 执行业务
}else {
return "没有可以占用的，失败";
}
return "占用成功,当前剩余车可占用量："+park.availablePermits ();
}
@GetMapping("/go")
public String go(){
RSemaphore park = redisson.getSemaphore ("park");
//park.release ();// 开发一个车位
park.release (30);// 开发 30个车位
return "增加车位成功";
}
五、闭锁
/**
* 模拟 5 个班级人走完，学校放假（闭校）
* @return
* @throws Exception
*/
@GetMapping("lockDoor")
public String lockDoor()throws Exception{
RCountDownLatch door = redisson.getCountDownLatch ("door");
door.trySetCount (5);
door.await ();// 等待闭锁都完成
return "放假了";
}
@GetMapping("/gogo/{id}")
public String gogo(@PathVariable("id")String id){
RCountDownLatch door = redisson.getCountDownLatch ("door");
door.countDown ();// 计数-1
long count = door.getCount ( );
return id+"班走完,剩余："+count;
}
六、分布式锁解决缓存一致性问题
1、redisson底层的每个锁 api调用都是使用 lua脚本（保证原子性）
2、锁的粒度：越细越快，越粗越慢
就是锁的名字不要尽量不要相同，比如一个接口的写锁大并发（100W），一个接口写锁小并发（1000），他们若是同一把锁，1000的并发可能要等100W的并发执行完成，所以设置锁名字要避免相同。
3、缓存一致性问题
缓存和数据库如何保持一致性
（1）双写模式
（2）失效模式
4、双写模式
既数据库改完，再改缓存
双写模式和失效模式在大并发下都会有问题：
问题：会有脏数据
方案一：加锁
方案二：若是允许延迟（今天更新的数据明天展示，或者几分钟几小时延迟），设置过期时间 （建议）
5、失效模式
将数据库改完，再将缓存删掉，等待下次主动查询在进行更新
问题：会有读写，脏数据
方案一：加锁
方案二：如果经常写，少读，不如直接数据库操作，去掉缓存层。
6、方案
无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办?
（1）如果是用户纬度数据（订单数据、用户数据)，这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
（2）如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。
（3）缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
（4）通过加锁保证并发读+写，写+写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。(业务不关心脏数据，允许临时脏数据可忽略）
总结:
（1）我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。
（2）我们不应该过度设计，增加系统的复杂性
（3）遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。
7、Canal（阿里） 解决缓存一致性问题
需要上大数据系统衔接电商的时候
缓存读写一致性框架（Spring Cache）
参考博客
https://blog.csdn.net/weixin_44565095/article/details/100598965
