使用redis实现分布式锁解决分布式缓存问题
1. 缓存
商城首页的访问量非常大，而首页中的商品类目访问量更大，鼠标移动就在访问，查询所有的数据，如果每次访问都实时到数据库获取数据，数据库的访问压力太大。
而这些信息一般更新的频率比较低，短时间内不会发生改变。因此，我们可以考虑在前台系统中，增加一层缓存，把这些数据缓存起来，请求到来时，不再调用数据接口，而是直接读取缓存中的数据。
这样就能大大减少首页分类加载所需时间，提高并发性能。
加不加缓存的标准：
-
变化频率低
-
访问频繁
实现：使用Redis实现缓存。
1.1. 如何实现
- 先读缓存，缓存有，直接返回。
- 缓存没有，再读数据库
1.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();
}
1.3. 缓存一致性
- 双写模式：写数据库，写缓存
- 失效模式：缓存失效（删除缓存），写数据库
读取缓存步骤数据一致性一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
不管先保存到MySQL，还是先保存到Redis都面临着一个保存成功而另外一个保存失败的情况。
不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子：
1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。
因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。
解决：
- 基于mysql的binlog日志（canal）
- 消息队列
1.4. 缓存常见问题
缓存最常见的3个问题：
-
缓存穿透
-
缓存雪崩
-
缓存击穿
缓存穿透是指查询一个不存在的数据，由于缓存无法命中，将去查询数据库，但是数据库也无此记录，并且出于容错考虑，我们没有将这次查询的null写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
解决：空结果也进行缓存，但它的过期时间会很短，最长不超过五分钟。
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
解决：原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
缓存击穿是指对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：如果这个key在大量请求同时进来之前正好失效，那么所有对这个key的数据查询都落到db，我们称为缓存击穿。
与缓存雪崩的区别：
- 击穿是一个热点key失效
- 雪崩是很多key集体失效
解决：锁
2. 分布式锁
2.1. 本地锁的局限性
之前，我们学习过synchronized及lock锁，这些锁都是本地锁。接下来写一个案例，演示本地锁的问题
2.1.1. 编写测试代码
在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));
}
2.1.2. 使用ab工具测试
之前在redis中，玩过ab测试工具：httpd-tools（yum install -y httpd-tools）
ab -n（一次发送的请求数） -c（请求的并发数） 访问路径
测试之前需要在linux中修改hosts文件，添加域名映射：vi /etc/hosts
测试如下：5000请求，100并发
查看redis中的值：
只有186。这代码问题很大！
2.1.3. 添加本地锁
使用ab工具压力测试：5000次请求，并发100
查看redis中的结果：
完美！是否真的完美？
接下来再看集群情况下，会怎样？
2.1.4. 本地锁问题演示
接下来启动8087 8088 8089三个运行实例。
运行多个实例：
由于这三个运行实例的服务名都是index-service，而网关配置的就是通过服务名负载均衡，我们只要通过网关访问，网关就会给我们做负载均衡了。
再次执行之前的压力测试，查看redis中的值：
集群情况下又出问题了！！！
以上测试，可以发现：
本地锁只能锁住同一工程内的资源，在分布式系统里面都存在局限性。
此时需要分布式锁。。
2.2. 分布式锁的实现
随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！
分布式锁主流的实现方案：
- 基于数据库实现分布式锁
- 基于缓存（Redis等）
- 基于Zookeeper
每一种分布式锁解决方案都有各自的优缺点：
- 性能：redis最高
- 可靠性：zookeeper最高
这里，我们就基于redis实现分布式锁。
2.2.1. 基本实现
借助于redis中的命令setnx(key, value)，key不存在就新增，存在就什么都不做。同时有多个客户端发送setnx命令，只有一个客户端可以成功，返回1（true）；其他的客户端返回0（false）。
- 多个客户端同时获取锁（setnx）
- 获取成功，执行业务逻辑，执行完成释放锁（del）
- 其他客户端等待重试
代码：
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();
}
}
}
重启，服务集群，通过网关压力测试：
查看redis中num的值：
基本实现。
问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放
解决：设置过期时间，自动释放锁。
2.2.2. 优化之设置锁的过期时间
设置过期时间有两种方式：
- 首先想到通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）
- 在set时指定过期时间（推荐）
设置过期时间：
压力测试肯定也没有问题。自行测试
问题：可能会释放其他服务器的锁。
场景：如果业务逻辑的执行时间是7s。执行流程如下
-
index1业务逻辑没执行完，3秒后锁被自动释放。
-
index2获取到锁，执行业务逻辑，3秒后锁被自动释放。
-
index3获取到锁，执行业务逻辑
-
index1业务逻辑执行完成，开始调用del释放锁，这时释放的是index3的锁，导致index3的业务只执行1s就被别人释放。
最终等于没锁的情况。
解决：setnx获取锁时，设置一个指定的唯一值（例如：uuid）；释放前获取这个值，判断是否自己的锁
2.2.3. 优化之UUID防误删
实现如下：
**问题：**删除操作缺乏原子性。
场景：
- index1执行删除时，查询到的lock值确实和uuid相等
- index1执行删除前，lock刚好过期时间已到，被redis自动释放
- index2获取了lock
- index1执行删除，此时会把index2的lock删除
2.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);
} else {
// 3. 每隔1秒钟回调一次，再次尝试获取锁
try {
Thread.sleep(1000);
testLock();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
2.2.5. 总结
1、加锁
String uuid = UUID.randomUUID().toString();
Boolean lock = this.redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
2、释放锁
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);
3、重试
try {
Thread.sleep(1000);
testLock();
} catch (InterruptedException e) {
e.printStackTrace();
}
为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：
- 互斥性。在任意时刻，只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁（设置过期时间）。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
- 加锁和解锁必须具有原子性。
redis集群状态下的问题：
- 客户端A从master获取到锁
- 在master将锁同步到slave之前，master宕掉了。
- slave节点被晋级为master节点
- 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。
redisson为我们提供了成熟的redis分布式锁解决方案，具体使用可查看分布式锁Redisson快速入门及利用AOP实现声明式缓存