单实现减库存1.4

三种情况导致Jvm本地锁失效1、多例模式下Jvm本地锁失效2、Spring的事务导致Jvm本地锁失效3、集群部署导致Jvm本地锁失效

1.7

mysql锁演示1.7.1、一个sql1.7.2、悲观锁1.7.3、乐观锁1.7.4、mysql锁总结

1.8

库存在并发量较大情况下很容易发生超卖现象一旦发生超卖现象就会出现多成交了订单而发不了货的情况。

场景商品S库存余量为5时用户A和B同时来购买一个商品此时查询库存数都为5库存充足则开始减库存

用户Aupdate

dependenciesdependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependencydependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactIdversion5.1.46/version/dependencydependencygroupIdcom.baomidou/groupIdartifactIdmybatis-plus-boot-starter/artifactIdversion3.4.3.4/version/dependencydependencygroupIdorg.projectlombok/groupIdartifactIdlombok/artifactId/dependencydependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactIdscopetest/scope/dependency/dependenciesapplication.yml配置文件

server.port10010

spring.datasource.driver-class-namecom.mysql.jdbc.Driver

spring.datasource.urljdbc:mysql://192.168.239.11:3306/atguigu_distributed_lock

spring.datasource.passwordhouchenDistributedLockApplication启动类

MapperScan(com.atguigu.distributed.lock.mapper)

public

{SpringApplication.run(DistributedLockApplication.class,

args);}}

stockService;GetMapping(stock/deduct)public

String

deduct(){this.stockService.deduct();return

hello

this.stockMapper.selectById(1L);//

再减库存if

0){stock.setCount(stock.getCount()

1);this.stockMapper.updateById(stock);}}

}测试

使用jmeter压力测试工具高并发下压测一下添加线程组并发100循环50次即5000次请求。

启动测试查看压力测试报告

使用jvm锁synchronized关键字或者ReetrantLock试试

/***

this.stockMapper.selectById(1L);//

再减库存if

{stock.setCount(stock.getCount()

1);this.stockMapper.updateById(stock);}}重启tomcat服务再次使用jmeter压力测试效果如下

查看mysql数据库

添加synchronized关键字之后同一时刻只有一个请求能够获取到锁并减库存。

此时所有请求只会one-by-one执行下去也就不会发生超卖现象

1.6

原理StockService有多个对象不同的对象持有不同的锁所以还是会有多个线程进入到

临界区

this.stockMapper.selectById(1L);//

再减库存if

{stock.setCount(stock.getCount()

1);this.stockMapper.updateById(stock);}}

}重启tomcat服务再次使用jmeter压力测试查看数据库发现库存确实没有减到

发生超卖

this.stockMapper.selectById(1L);//

再减库存if

{stock.setCount(stock.getCount()

1);this.stockMapper.updateById(stock);}}

重启tomcat服务再次使用jmeter压力测试查看数据库发现库存确实没有减到

发生超卖

{this.stockService.deduct();}return

hello

使用jvm锁在单工程单服务情况下确实没有问题但是在集群情况下会怎样

接下启动多个服务并使用nginx负载均衡

application/octet-stream;sendfile

on;upstream

3在post中测试http://localhost/stock/deduct

Jmeter压力测试

http://localhost:80/stock/deduct

两台机器时吞吐量明显大于单个机器

每个服务都有自己的本地锁所以无法锁住临界区导致多线程的安全问题

1.7

{this.stockMapper.updateStock(1001,

1);}public

this.stockMapper.queryStockForUpdate(1001);if

(stocks

{stocks.setCount(stocks.getCount()

1);this.stockMapper.updateById(stocks);}}在StockeMapper中定义selectStockForUpdate方法

public

queryStockForUpdate(Param(productCode)

String

注意测试之前需要把库存量改成5000。

压测数据如下比jvm锁性能高很多

mysql数据库存

【注意】使用MySQL乐观锁时也需要注意锁的粒度尽量使用行级锁否则系统吞吐量会降低

1.7.3、乐观锁

乐观锁是相对悲观锁而言乐观锁假设认为数据一般情况下不会造成冲突所以在数据进行提交更新的时候才会正式对数据的冲突与否进行检测如果发现冲突了则重试。

“version”

字段来实现。

当读取数据时将version字段的值一同读出数据每更新一次对此version值加一。

当我们提交更新的时候判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对如果数据库表当前版本号与第一次取出来的version值相等则予以更新。

StockService

this.stockMapper.selectById(1L);//

再减库存if

stock.getVersion();stock.setCount(stock.getCount()

1);//

1stock.setVersion(stock.getVersion()

1);//

(this.stockMapper.update(stock,

new

{deduct();}}}重启后使用jmeter压力测试工具结果如下

并发度比较低说明乐观锁在并发量越大的情况下性能越低因为需要大量的重试并发量越小性能越高。

高并发情况下性能较低ABA问题读写分离的情况下可能会导致乐观锁不可靠

1.7.4、mysql锁总结

如果追求极致性能、业务场景简单并且不需要记录数据前后变化的情况下。

优先选择一个sql

如果写并发量较高一般会经常冲突此时选择乐观锁的话会导致业务代码不间断的重试。

优先选择mysql悲观锁

https://blog.csdn.net/hc1285653662/article/details/127564372

改造StockService

为了提高请求响应的速度将库存放在redis中进行操作*/public

void

redisTemplate.opsForValue().get(stock:

1001);Long

{redisTemplate.opsForValue().set(stock:

1001,

jmeter启动测试可以看到并发比无锁时候的mysql库存要高

1.8.2

使用watch命令监视某个key如果在监视的过程中该key被某个客户端修改后那么自身对于key的修改将会失败

1.8.3

为了提高请求响应的速度将库存放在redis中进行操作*/public

void

stock:1001redisTemplate.execute(new

{Overridepublic

operations.opsForValue().get(stock:

1001);Long

{operations.multi();operations.opsForValue().set(stock:

1001,

{e.printStackTrace();}deduct();}return

exec;}return

null;}});}查看测试结果发现并发很低可能因为我redis部署在阿里云上的docker里网络开销导致并发很低但是确实解决超卖问题

1.8.4