代码拉取完成，页面将自动刷新
1.商品在编辑了规格后，删除了redis中的skuId，在调用updateStock方法中的写入redis之前时。
2.如果有其他地方调用了getGoodsSkuByIdFromCache，此时无法命中缓存，则查询数据库后写入。
由于1#还处于事务中，数据库中的数据对其他事务为未提交状态，不会被获取到，甚至1#卡顿使得sku的update都还没调用。此时2#读取到的数据库为修改前的老数据。并且1#和2#写入redis的顺序不可控，可能会出现1#先写入然后2#再写入的情况，此时redis中的数据为老数据。
目前一个简单的想法是在进入商品的editGoods方法时使用skuId设置redislock，方法结束后释放，在getGoodsSkuByIdFromCache中对锁进行检测，这样即可保证更新商品时不会有上述问题。
Chopper711
拥有者
细心的发现，之前有个同学也提过类似的问题，他的意思是编辑商品库存直接写入，极端情况会存在库存事务问题。
这边不是很喜欢锁这个东西，虽然系统中使用了redisson，但是使用的地方目前就一个，而且准备未来剔除掉。
目前主要保证的是在商品并发秒杀时库存不超买（基于现有架构，不涉及库存变更，商品变更，redis清空的场景的话，不回有超卖问题），当前描述的这个场景发生概率极低，这边想想后续有什么样的好方案提供。感谢关注，后续有更好的方案再来回复这个issues
锁这种东西该用还是得用呀，尤其是库存变更这种高频多线程的地方，再加上现在基本都是微服务，实例一多那更没法避免了
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
Chopper711
拥有者
锁这种东西该用还是得用呀，尤其是库存变更这种高频多线程的地方，再加上现在基本都是微服务，实例一多那更没法避免了
@Morrowind 可以参考库存扣减，并不是锁，只不过是把事务从数据库转到了lua脚本。越是高频的地方应该是更加不能用锁的，不然死锁等待、内存溢出zzz
登录 后才可以发表评论
