Springboot整合Redis如何实现超卖问题

这篇文章将为大家详细讲解有关Springboot整合Redis如何实现超卖问题，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。写一段简单正常的超卖逻辑代码，多个用户同时操作同一段数据，探究出现的问题。Redis中存储一项数据信息，请求对应接口，获取商品数量信息；
商品数量信息如果大于0，则扣减1，重新存储Redis中；
运行代码测试问题。在单应用模式下，使用jmeter压测。测试结果：每个请求相当于一个线程，当几个线程同时拿到数据时，线程A拿到库存为84，这个时候线程B也进入程序，并且抢占了CPU，访问库存为84，最后两个线程都对库存减一，导致最后修改为83，实际上多卖出去了一件既然线程和线程之间，数据处理不一致，能否使用synchronized加锁测试？依旧还是先测试单服务器数量100重新压测，得到的日志信息如下所示：在单机模式下，添加synchronized关键字，的确能够避免商品的超卖现象！但是在分布式微服务中，针对该服务设置了集群，synchronized依旧还能保证数据的正确性吗？假设多个请求，被注册中心负载均衡，每个微服务中的该处理接口，都添加有synchronized，依然会出现类似的超卖问题：synchronized只是针对单一服务器的JVM进行加锁，但是分布式是很多个不同的服务器，导致两个线程或多个在不同服务器上共同对商品数量信息做了操作！在Redis中存在一条命令setnx (set if not exists)setnx key value
如果不存在key，则可以设置成功；否则设置失败。修改处理接口，增加key1、请求进入接口中，如果redis中不存在key，则会新建一个setnx；如果存在，则不会新建，同时返回错误编码，不会继续执行抢购逻辑。
2、当创建成功后，执行抢购逻辑。
3、抢购逻辑执行完成后，删除数据库中对应的setnx的key。让其他请求能够设置并操作。这种逻辑来说比之前单一使用syn合理的多，但是如果执行抢购操作中出现了异常，导致这个key无法被删除。以至于其他处理请求，一直无法拿到key，程序逻辑死锁！可以采取try … finally进行操作这个逻辑相比上面其他的逻辑来说，显得更加的严谨。但是，如果一套服务器，因为断电、系统崩溃等原因出现宕机，导致本该执行finally中的语句未成功执行完成！！同样出现key一直存在，导致死锁！在设置成功setnx后，以及抢购代码逻辑执行前，增加key的限时。但是上述代码的逻辑中依旧会有问题：如果处理逻辑中，出现超时问题。
当逻辑执行时，时间超过设定key有效时间，此时会出现什么问题？从上图可以清楚的发现问题：
如果一个请求执行时间超过了key的有效时间。
新的请求执行过来时，必然可以拿到key并设置时间；
此时的redis中保存的key并不是请求1的key，而是别的请求设置的。
当请求1执行完成后，此处删除key，删除的是别的请求设置的key！依然出现了key形同虚设的问题！如果失效一直存在，超卖问题依旧不会解决。既然出现key形同虚设的现象，是否可以增加条件，当finally中需要执行删除操作时，获取数据判断值是否是该请求中对应的，如果是则删除，不是则不管！修改上述代码如下所示：由于获得锁的线程必须执行完减库存逻辑才能释放锁，所以在此期间所有其他的线程都会由于没获得锁，而直接结束程序，导致有很多库存根本没有卖出去，免费云主机域名所以这里应该可以优化，让没获得锁的线程等待，或者循环检查锁我们将锁封装到一个实体类中，然后加入两个方法，加锁和解锁可以看到失败的线程不会直接结束，而是会尝试重试，一直到重试结束时间，才会结束实际上这个最终版依然存在3个问题1、在finally流程中，由于是先判断在处理。如果判断条件结束后，获取到的结果为true。但是在执行del操作前，此时jvm在执行GC操作(为了保证GC操作获取GC roots根完全，会暂停java程序)，导致程序暂停。GC操作执行完成后(暂停恢复后)，执行del操作，但是此时的key还在当前加锁的key么？2、问题如图所示关于“Springboot整合Redis如何实现超卖问题”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。

相关推荐: JavaScript怎么作为方法来调用函数

这篇文章主要讲解了“JavaScript怎么作为方法来调用函数”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“JavaScript怎么作为方法来调用函数”吧！ 在 JavaScript 中，您可以把函数定义为对象…