关于乐观锁 about springboot-seckill HOT 19 OPEN

你说的属于悲观锁解决超卖方案，每次更新前要select for update给指定商品信息加排他锁，然后阻塞其他请求，但这种情况下并发性能大大降低。

from springboot-seckill.

from springboot-seckill.

乐观锁发生冲突时版本号已经被其他请求+1，所以重试时需要获取最新的版本号，直接update还是用原来的版本号，会一直重试失败。

from springboot-seckill.

from springboot-seckill.

直接update还是会导致超卖问题，如果需要用排他锁，update之前要select for update申请排他锁才可以。

from springboot-seckill.

from springboot-seckill.

from springboot-seckill.

stock_count > 0 这个条件已经是乐观锁了。根本不会出现超卖现象。那个版本号原理就是cas，在这里有点多此一举。同时redis是单线程，根本不会有两个线城同时减库存，所以不可能存在超卖现象

from springboot-seckill.

确实是这样的，因为加了库存判断，这就已经解决超卖问题，是我理解有误。

from springboot-seckill.

学习了,谢谢,刚刚我也是在这个环境又疑惑,5次判断乐观锁,如果数量不是 更新减一,而是用户自己下单的数量减N,那这一步是比较好的

from springboot-seckill.

afterPropertiesSet();这个同步mysql和redis库存的操作，因为mysql和redis的速率不同导致redis上的库存已经用完但是mysql还没来得及更新，然后afterPropertiesSet()会把redis上的库存同步为mysql上一样的，会不会产生大量的redis上的超卖

from springboot-seckill.

afterPropertiesSet();这个同步mysql和redis库存的操作，因为mysql和redis的速率不同导致redis上的库存已经用完但是mysql还没来得及更新，然后afterPropertiesSet()会把redis上的库存同步为mysql上一样的，会不会产生大量的redis上的超卖

不会，这个同步是初始化的时候同步，redis库存用完意味着此次秒杀结束

from springboot-seckill.

long stock = redisService.decr(GoodsKey.getGoodsStock, "" + goodsId);//10
if (stock < 0) {
afterPropertiesSet();
long stock2 = redisService.decr(GoodsKey.getGoodsStock, "" + goodsId);//10
if(stock2 < 0){
localOverMap.put(goodsId, true);
return Result.error(CodeMsg.SECKILL_OVER);
}
}
但是代码上写的逻辑就是redis上的库存一为0就会更新mysql上的缓存数量

from springboot-seckill.

long stock = redisService.decr(GoodsKey.getGoodsStock, "" + goodsId);//10
if (stock < 0) {
afterPropertiesSet();
long stock2 = redisService.decr(GoodsKey.getGoodsStock, "" + goodsId);//10
if(stock2 < 0){
localOverMap.put(goodsId, true);
return Result.error(CodeMsg.SECKILL_OVER);
}
}
但是代码上写的逻辑就是redis上的库存一为0就会更新mysql上的缓存数量

昂，你应该这样理解，超卖是出现数据库为负数的情况，所以就算redis缓存同步为上次一样的也没关系，这样的后果只是多一些人来参加秒杀，但是不会出现超卖，这些人最后的结果的是秒杀失败。

from springboot-seckill.

我在想redis上如果不出现超卖，那mybatis上是不是也不会超卖，然后mybatis上是不是就不用加锁了

from springboot-seckill.

我在想redis上如果不出现超卖，那mybatis上是不是也不会超卖，然后mybatis上是不是就不用加锁了

mysql更新操作默认加X锁，数据库主要控制好事务，下单，减库存要加事务。还有我估计这里同步还是考虑到秒杀取消订单的情况。redis单线程，你直接实现不超卖也可以。

from springboot-seckill.

谢谢大佬代码学习了

from springboot-seckill.

hello,你是如何测试的,然后确认的乐观锁性能要比悲观锁性能高, 并发多少 ，
我看了最早的你的想法 我觉得思路是对的 , 不太确认为什么你的测试结果却不好。 @Lxiaolong

from springboot-seckill.

这个如果只有乐观锁去判断的话，那不是秒杀的时候失败的概率会很高？

from springboot-seckill.