本文主要是介绍分布式锁：四种方案解决商品超卖的方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一 分布式锁
1.1 分布式锁的作用
在多线程高并发场景下，为了保证资源的线程安全问题，jdk为我们提供了synchronized关键字和ReentrantLock可重入锁，但是它们只能保证一个工程内的线程安全。在分布式集群、微服务、云原生横行的当下，如何保证不同进程、不同服务、不同机器的线程安全问题。jdk并没有给我们提供既有的解决方案。需要自己通过编写方案来解决，目前主流的实现有以下方式：
-
基于mysql关系型实现
-
基于redis非关系型数据实现
-
基于zookeeper/etcd实现
二 模拟单体超卖
2.1 工程结构
2.2 编写工程代码
1.pom文件
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>5.1.46</version></dependency><dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.4.1</version></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><version>1.18.16</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-devtools</artifactId><version>2.3.12.RELEASE</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope><exclusions><exclusion><groupId>org.junit.vintage</groupId><artifactId>junit-vintage-engine</artifactId></exclusion></exclusions></dependency>2.配置文件
server.port=9999
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/fenbu_lock?characterEncoding=utf-8&useSSL=true
spring.datasource.username=root
spring.datasource.password=cloudiip
redis.host=172.16.116.1003.controller
@RestController
public class StockController {@Autowiredprivate StockService stockService;@GetMapping("stock/deduct")public String deduct(){// this.stockService.deduct();this.stockService.deductByMsqlDb();return "hello stock deduct！！";}}
4.service
@Service
public class StockService {@Autowiredprivate StockMapper stockMapper;private Stock stock = new Stock();private ReentrantLock lock = new ReentrantLock();public void deduct(){
// lock.lock();
// try {
// stock.setStock(stock.getStock() - 1);
// System.out.println("库存余量：" + stock.getStock());
// } finally {
// lock.unlock();
// }}public void deductByMsqlDb(){// 先查询库存是否充足Stock stock = this.stockMapper.selectById(1L);// 再减库存if (stock != null && stock.getCount() > 0){stock.setCount(stock.getCount() - 1);this.stockMapper.updateById(stock);}}}5.mapper
@Mapper
public interface StockMapper extends BaseMapper<Stock> {
}
6.启动类
@SpringBootApplication
@MapperScan("com.atguigu.distributed.lock.mapper")
public class DistributedLockApplication {public static void main(String[] args){SpringApplication.run(DistributedLockApplication.class, args);System.out.println("========================启动成功==========");}}7.pojo类
@Data
@TableName("db_stock")
public class Stock {@TableIdprivate Long id;private String productCode;private String stockCode;private Integer count;// private Integer stock = 5000;
}8.附件数据表
1.新建一个数据库，附件数据表，如图
2.脚本文件
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=1 DEFAULT CHARSET=utf8;2.3 测试验证
http://localhost:9999/stock/deduct
查看数据库
2.4 jmeter模拟并发访问
2.4.1 启动jmeter
2.4.2 配置jmeter
1.添加线程组
并发100循环50次，即5000次请求。
3.给线程组添加HTTP Request请求：
4.将接口地址：http://localhost:9999/stock/deduct 配置到下面
5.再选择你想要的测试报表，例如这里选择聚合报告：
启动测试，查看压力测试报告：
参数api说明如下：
1.Label 取样器别名，如果勾选Include group name ，则会添加线程组的名称作为前缀
# Samples 取样器运行次数
Average 请求（事务）的平均响应时间
Median 中位数
90% Line 90%用户响应时间
95% Line 90%用户响应时间
99% Line 90%用户响应时间
Min 最小响应时间
Max 最大响应时间
Error 错误率
Throughput 吞吐率
Received KB/sec 每秒收到的千字节
Sent KB/sec 每秒收到的千字节
测试结果：请求总数5000次，平均请求时间129ms，中位数（50%）请求是在36ms内完成的，错误率0%，每秒钟平均吞吐量716.7次。
结论：此时如果还有人来下单，就会出现超卖现象（别人购买成功，而无货可发）。
三 方案1：使用jvm的本地锁解决冲突
3.1 原理
添加synchronized关键字之后，StockService就具备了对象锁，由于添加了独占的排他锁，同一时刻只有一个请求能够获取到锁，并减库存。此时，所有请求只会one-by-one执行下去，也就不会发生超卖现象。
3.2 操作
用jvm锁（synchronized关键字或者ReetrantLock）试试：
2.使用jmeter再次测试
查看数据库
并没有发生超卖现象，完美解决。
3.3 此方案的缺点失效情况
1.多例模式 2.事务 ；3.集群
四 方案2：使用update的sql解决本地锁
4.1 操作案例
1.mapper级别
@Update("update db_stock set count=count-#{count} where product_code=#{productCode} and count>=#{count}")int updateStock(@Param("productCode") String productCode,@Param("count") Integer count);
2.service
public void deductBySql(){// 先查询库存是否充足this.stockMapper.updateStock("1001",1);System.out.println("请求进来了.......");}3.查看数据库
4.并发压力测试
5.查看效果：均正确消费。
4.2 此方案缺点
优点：能够解决jvm本地锁多失效的3种情况。
缺点：1.确定锁的范围 行级锁还是表级锁；2.同一个商品有多条库存记录；3.无法记录库存前后的变化记录。
五 解决单体超卖的其他方式
3.1 使用悲观锁和乐观锁
除了使用jvm锁之外，还可以使用数据锁：悲观锁 或者 乐观锁。
一个sql：直接更新时判断，在更新中判断库存是否大于0 ;
update table set surplus = (surplus - buyQuantity) where id = 1 and (surplus - buyQuantity) > 0
1.悲观锁：在读取数据时锁住那几行，其他对这几行的更新需要等到悲观锁结束时才能继续 。
select ... for update
2.乐观锁：读取数据时不锁，更新时检查是否数据已经被更新过，如果是则取消当前更新进行重试。
version 或者 时间戳（CAS思想）。
这篇关于分布式锁：四种方案解决商品超卖的方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
