1.背景介绍
2.案例演示（超买现象）并且使用jvm提供的锁
2.1 新建一个数据库（将数据库的库存改为5000）
CREATE TABLE `db_stock` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_code` varchar(255) DEFAULT NULL COMMENT '商品编号', `stock_code` varchar(255) DEFAULT NULL COMMENT '仓库编号', `count` int(11) DEFAULT NULL COMMENT '库存量', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;2.2 测试工具
使用压力测试工具
配置的100*50=5000次请求
2.3 代码演示
先不加锁演示
执行完成5000次但是数据库显示还有库存，这个时候就会发生超卖情况。
加锁
重启项目运用工具 数控库存重置5000
这个时候就不会出现超卖的现象
因此jvm的锁也是可以处理一定问题的。但是也有例外
2.4 jvm锁失效的场景
- 多例模式
上述情况不出现超卖是因为添加了独占的排他锁，同一时刻只 有一个请求能够获取到锁，并减库存。此时，所有请求只会one-by-one执行下去，也就不会发生超卖现象。这样多例模式下不是同一个service对象这样就会出现超卖的问题。
- 添加事务
失效的原理是a用户访问资源的时候，做了一系列操作在释放锁和提交事务之间的时候，b用户访问到了a事务未提交的操作。
- 多服务集群
就是分布式服务多太机器压根就不是一个jvm虚拟机。
复制3个上述案例工程
改造代码，配置nginx做代理转发
###nginx配置
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
upstream distributedlock{
server 127.0.0.1:1100;
server 127.0.0.1:1110;
server 127.0.0.1:1120;
}
server {
listen 80;
server_name localhost;
charset gbk;
location / {
proxy_pass http://distributedlock;
}
}
}配置在不同的端口
访问80端口有效并且回进行负载均衡，通过工具进行压力测试。启动3个项目
演示集群锁失效
3.mysql分布式锁解决锁失效问题
3.1 基于一条sql语句解决锁失效
update delete insert 语句本身就是自带加锁
重启3个项目使用工具测试
优缺点：
1.表记锁定，当我们操作记录a并且锁定的时候，不能操作该表下的记录b
2.无法解决一对多的表记录。
3.无法使用该记录更新前后的状态。
4.解决了失效问题 （多例模式，事务，集群）都可以解决
3.2 悲观锁
* 在一般的查询语句中我们这条记录先查询到记录a的数据但是在这之间 * 其他用户操作了记录a的数据导致 2着数据不一致引起的问题 * 当我们加入悲观锁之后，做查询的时候已经为我们添加了锁，意味着这个查询上的锁没有结束别的操作不能进行
使用悲观锁之后就可以解决一条sql语句的缺陷
但是悲观锁的缺点如下
- 性能低（加了事务）
- 可能回发生死锁，保证加锁的顺序
- 操作需要统一，在其他查询该表的语句都需要加for update
3.3 乐观锁
乐观锁的就是需要在添加的时候判断版本号
修改数据库
修改代码
缺点：效率低，需要不停的检查版本号，读写分离的情况下不可靠。
3.4总结mysql锁
性能：一个sql > 悲观锁 > jvm锁 > 乐观
如果追求极致性能、业务场景简单并且不需要记录数据前后变化的情况下。
优先选择：一个sql
如果写并发量较低（多读），争抢不是很激烈的情况下优先选择：乐观锁
如果写并发量较高，一般会经常冲突，此时选择乐观锁的话，会导致业务代码不间断的重试。
优先选择：mysql悲观锁
不推荐jvm本地锁。
4.redis锁
关于redis事务在我之前的文章有锁介绍
4.1 redis乐观锁
利用redis监听 + 事务
redis配置这里不介绍了
缺点效率非常低
4.2 redis分布式锁
注意点
防止死锁
防止误删
接下来还是用工具进行压力测试，这里不演示了都是同一个api接口
存在的问题：
释放锁的判断和释放锁不是原子性的，所以会有一定的可能回照成错删，没有保证到释放锁和释放锁判断的原子性
解决上述问题 引入 lua脚本（详细搜索一下）
修改代码 将上图释放锁框内的修改如下
// 先判断是否自己的锁，再解锁
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, Boolean.class), Arrays.asList("lock"), uuid);优化手写分布式锁添加自动延期,可重入锁。
添加构建工程
自动续期
重入锁
总结
特征：
1. 独占排他：setnx
2. 防死锁：
redis客户端程序获取到锁之后，立马宕机。给锁添加过期时间
不可重入：可重入
3. 防误删：
先判断是否自己的锁才能删除
4. 原子性：
加锁和过期时间之间：set k v ex 3 nx
判断和释放锁之间：lua脚本
5. 可重入性：hash（key field value） + lua脚本
6. 自动续期：Timer定时器 + lua脚本
7. 在集群情况下，导致锁机制失效：
1. 客户端程序10010，从主中获取锁
2. 从还没来得及同步数据，主挂了
3. 于是从升级为主
4. 客户端程序10086就从新主中获取到锁，导致锁机制失效
锁操作：
加锁：
1. setnx：独占排他 死锁、不可重入、原子性
2. set k v ex 30 nx：独占排他、死锁 不可重入
3. hash + lua脚本：可重入锁
1. 判断锁是否被占用（exists），如果没有被占用则直接获取锁（hset/hincrby）并设置过期时间（expire）
2. 如果锁被占用，则判断是否当前线程占用的（hexists），如果是则重入（hincrby）并重置过期时间（expire）
3. 否则获取锁失败，将来代码中重试
4. Timer定时器 + lua脚本：实现锁的自动续期
判断锁是否自己的锁（hexists == 1），如果是自己的锁则执行expire重置过期时间
解锁
1. del：导致误删
2. 先判断再删除同时保证原子性：lua脚本
3. hash + lua脚本：可重入
1. 判断当前线程的锁是否存在，不存在则返回nil，将来抛出异常
2. 存在则直接减1（hincrby -1），判断减1后的值是否为0，为0则释放锁（del），并返回1
3. 不为0，则返回0
重试：递归 循环 4.3 redisson中的分布式锁
官方文档
https://github.com/redisson/redisson/wiki/1.-%E6%A6%82%E8%BF%B0我们使用data-redis手写的分布式锁会比较麻烦并且也比较复制，如果处理的不好还会出现一些问题，redisson为我们封装好了如何方便使用分布式锁的api。
引入依赖
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.11.2</version>
</dependency>4.3.1 可重入锁
基于Redis的Redisson分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口。
大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。
RLock对象完全符合Java的Lock规范。也就是说只有拥有锁的进程才能解锁，其他进程解锁则会抛出IllegalMonitorStateException错误。
另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。
public Object redissonLock() {
int reduce = 1;
//获取锁加锁
RLock lock = redissonClient.getLock("lock");
lock.lock();
// lock.lock(30,TimeUnit.MINUTES);//设置过期时间
/**
* 默认30s过期时间并且在实例消失之前回自动续期
* 就是说假设你的业务逻辑大于30s 但是你并没有设置过期时间那么他会自动续期保证业务
*/
try {
//mysql操作
// 先查询库存是否充足
List<Stock> list = this.stockMapper.selectList(new QueryWrapper<Stock>().eq("product_code", "10011"));
if (CollUtil.isEmpty(list))
return "不存在商品";
//业务选取仓库 演示第一个
Stock stock = list.get(0);
//判断
if (stock.getCount() < reduce)
return "库存不足！";
//减少
stock.setCount(stock.getCount() - reduce);
stockMapper.updateById(stock);
//可重入锁
// this.morelock();
} finally {
lock.unlock();
}
return null;
}
private void morelock() {
//重入锁必须相同
RLock lock = redissonClient.getLock("lock");
lock.lock();
log.info("重入锁");
lock.unlock();
}
521
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
