聊到分布式锁,就不得不先聊到本地锁,如果没有从本地锁到分布式锁这个演进过程或者说是推导过程,我觉得是不合适的,甚至是不完整的。
程序的发展是一步一步递进,知道它是解决什么样的问题,才能更好的理解和学习。
文章大纲:
本文字数约为1w
字左右,建议可以腾出一点点空闲时间来阅读,都是我的存稿~ 哈哈,寻思着再不发,这个月都得过完了。
关于代码:
后期在检查时,发现案例中的代码是有点不太合适的,应当将所有案例中的递归调用方法改为循环重试,并限制重试次数,而非一直递归调用。 切记切记切记👨💻。
一、本地锁
1.1、本地锁的使用
本地锁主要是针对单体服务而言的,锁的都是单体应用内的进程。
像之前在单机情况下出现的读写并发情况。因为并发情况下网络出现问题或是出现其他卡顿问题,导致执行顺序发生变化,从而产生了数据不一致性。如下图:
解决并发最快的方式就是加锁吗,我们也就给它来把锁吧,Java中的锁是有蛮多的,我这里不过多讨论啦(synchronized、JUC)等等。
我案例中所使用的是 JUC 包下的读写锁ReentrantReadWriteLock
,毕竟不能让锁直接限制了Redis 的发挥~,读写锁是读并发,写独占的模式。
增加读写锁之后的流程图如下:
(图片说明:加上锁之后的流程)
案例代码如下:
/**
* @description: 单机redis下的操作
* @author: Ning Zaichun
* @date: 2022年09月06日 23:20
*/
@Slf4j
@Service
public class RedisCacheServiceImpl implements IRedisCacheService {
@Autowired
private MenuMapper menuMapper;
@Autowired
StringRedisTemplate redisTemplate;
private static final String REDIS_MENU_CACHE_KEY = "menu:list";
private ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
@Override
public List<MenuEntity> getList() {
//1、从缓存中获取
String menuJson = redisTemplate.opsForValue().get(REDIS_MENU_CACHE_KEY);
if (!StringUtils.isEmpty(menuJson)) {
System.out.println("缓存中有,直接从缓存中获取");
//2、缓存不为空直接返回
List<MenuEntity> menuEntityList = JSON.parseObject(menuJson, new TypeReference<List<MenuEntity>>() {
});
return menuEntityList;
}
//3、查询数据库
//不加锁情况下
// List<MenuEntity> noLockList = getMenuJsonFormDb();
// 加锁情况下
List<MenuEntity> menuEntityList = getMenuJsonFormDbWithReentrantReadWriteLock();
return menuEntityList;
}
public List<MenuEntity> getMenuJsonFormDb() {
System.out.println("缓存中没有,重新从数据中查询~==>");
//缓存为空,查询数据库,重新构建缓存
List<MenuEntity> result = menuMapper.selectList(new QueryWrapper<MenuEntity>());
//4、将查询的结果,重新放入缓存中
redisTemplate.opsForValue().set(REDIS_MENU_CACHE_KEY, JSON.toJSONString(result));
return result;
}
public List<MenuEntity> getMenuJsonFormDbWithReentrantReadWriteLock() {
List<MenuEntity> result = null;
System.out.println("缓存中没有,加锁,重新从数据中查询~==>");
// synchronized 是同步锁,所以当多个线程同时执行到这里时,会阻塞式等待
ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
readLock.lock();
try {
String menuJson = redisTemplate.opsForValue().get(REDIS_MENU_CACHE_KEY);
//加锁成功... 再次判断缓存是否为空
if (!StringUtils.isEmpty(menuJson)) {
System.out.println("缓存中,直接从缓存中获取");
//2、缓存不为空直接返回
List<MenuEntity> menuEntityList = JSON.parseObject(menuJson, new TypeReference<List<MenuEntity>>() {
});
return menuEntityList;
}
//缓存为空,查询数据库,重新构建缓存
result = menuMapper.selectList(new QueryWrapper<MenuEntity>());
//4、将查询的结果,重新放入缓存中
redisTemplate.opsForValue().set(REDIS_MENU_CACHE_KEY, JSON.toJSONString(result));
return result;
} finally {
readLock.unlock();
}
}
@Override
public Boolean updateMenuById(MenuEntity menu) {
//return updateMenuByIdNoWithLock(menu);
return updateMenuByIdWithReentrantReadWriteLock(menu);
}
public Boolean updateMenuByIdNoWithLock(MenuEntity menu) {
// 1、删除缓存
redisTemplate.delete(REDIS_MENU_CACHE_KEY);
System.out.println("清空单机Redis缓存");
// 2、更新数据库
return menuMapper.updateById(menu) > 0;
}
public Boolean updateMenuByIdWithReentrantReadWriteLock(MenuEntity menu) {
ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();
writeLock.lock();
try {
// 1、删除缓存
System.out.println("清除缓存");
redisTemplate.delete(REDIS_MENU_CACHE_KEY);
// 2、更新数据库
return menuMapper.updateById(menu) > 0;
}finally {
writeLock.unlock();
}
}
}
复制代码
具体还需大家去了解~
我这里加的 JUC 下的读写锁,原本我想的是弄的JUC的锁
1.2、本地锁存在的问题
看起来本地锁没有并发问题,不管有多少请求一起进来,都要去争取那唯一的一把锁,抢到了才能继续往下执行业务。
单体项目中,每把锁锁的就是当前服务中的当前线程的请求。
(图片说明:单体服务时)
但是当服务需要进一步扩展时,就会随之产生出一些问题。
多服务并发时,如果还是只给当前线程加锁,多个用户一起尝试获取锁时,可能会有多个用户同时获取到锁,导致出现问题。
如下图:
每个服务都是单独的,加锁操作也只是给自己的,大家不能共享,那么实际上在高并发的时候,是根本没效果的。
我1号服务抢到了锁,还没等到释放,2号服务又获取到了锁,接着3号、4号等等,大家都可以操作数据库,这把锁也就失去了它该有的作用。
因此就进一步出现了分布式锁,接下来继续看吧。
二、分布式锁的介绍
本地锁失效是因为无法锁住各个应用的读写请求,失效的根本原因就是其他的服务无法感知到是否已经有请求上锁了,即无法共享锁信息。
分布式锁,其实也就是将加锁的这一个操作,单独的抽取出来了,让每个服务都能感知到。
之前就说了,软件架构设计中,"没有什么是加一层解决不了的,如果加一层不行就再加一层"。
这里其实也是一样,只不过碰巧这一层可以在Redis中实现罢了,看起来倒是没有多加一层,但如果是用Zookeeper
或者其他方式来实现,你会发现架构中会多一层滴。
其实理解思想实现的方式有很多种的,
- Redis 实现分布式锁
- Zookeeper 实现分布式锁
- MySQL 专门用一张表来记录信息,实现分布式锁,也是常说的基于数据库实现分布式锁。
所谓的加锁,其本质也就是判断一个信号量是否存在罢了,分布式也就是把这个信号量从本地线程中,移植到了Redis中存储,让所有服务中的请求都能共享一把锁。知道思想后,实现方式并不局限,大家也不要局限了自己,都已经站在巨人肩膀上,就要想的更多一些~
我采用 Redis 实现分布式锁,主要原因:
- Redis 是基于内存操作的数据库,速度快;
- 市场主流的数据库,拥有较多的参考资料;
- Redis 社区开发者活跃,并且 Redis 对分布式锁有较好的支持;
今天所讨论的,主要就是针对于使用 Redis 实现分布式锁,流程图大致如下:
(图片说明:此图为获取锁的大致流程,其之后的构建缓存、释放锁等未在图上所标明)
虽然两个服务都是独立的,但是在执行数据库代码前,都需要先获取到读锁或者写锁,以确保并发时执行的正确性~
接下来就是说分布式锁的实现啦~
三、分布式锁的实现
在上一小节就已说分布式锁的实现有多种方式,大的范围中有 Redis、Zookeeper、MySQL等实现方式,我具体讲的是以 Redis 的实现。
讲解过程也是逐步深入,逐步演进,并非是直接丢出实现代码,针对为什么要这么做,为什么最终是这样,让大家有一个了解过程。
锁的第一个要求就是要能做到互斥,而在Redis中最容易想到,也是最简单的,无疑就是 setnx
命令。
我们就以 setnx
抛砖引玉,来对分布式锁的实现,做一个逐步演进的讨论。
3.1、setnx
Redis Setnx
( SET IF Not EXists )命令在指定的 key 不存在时,为 key 设置指定的值,这种情况下等同 SET 命令。当 key
存在时,什么也不做。
返回值
- 如果key设置成功了,则返回
1