其他分享
首页 > 其他分享> > 防止商品超卖的 3 个思路!

防止商品超卖的 3 个思路!

作者:互联网

作者:叁滴水
博客:https://blog.csdn.net/qq_30285985/

前言

在多个人同时对一个商品下单时,如果处理的不得当会存在超卖的现象,这种严重的bug是无法接受的。这是一种极为常见的并发问题,这个时候就有开发者想到了通过锁来控制。但是由于很多小伙伴对于锁没有一个充分的认识,最后却弄巧成拙。

如下,我列举一些常见的解决思路和我的想法,请大家参考。

一、如何防止超卖

在防止超卖的逻辑编写时,加锁这个思路是没有问题的,但是要加什么锁,锁哪一段逻辑就成为了问题。

1、思路1

jvm提供了synchronizedreentrantlock

这两个锁适合在减库存的时候使用吗?

理论上讲,是可以使用的,但是服务必须是单机部署。如果是多台服务器,就会变成如下场景,锁根本没有作用。

2、思路2

jvm锁弊端很明显,这时就会想到分布式锁,分布式锁实现的方法有很多。

我列举了下redis和zk的实现及其对比,这种方式不管是单机还是集群中使用都是可以有效的防止超卖的。大概的思路是由redis的setNX命令实现进行加锁,加锁之后实现单线程减库存,这也算是一种相对较好的解决方式。

3、思路3

我在网上曾看到有人列举前面两种实现方式,这里重点说明下,单机锁和分布式锁是不推荐的!

其实防超卖最终的目的是防止数据库的库存(goods_num)小于0。导致小于0的原因是多个线程在程序中计算库存,然后在赋值给数据库。这么多锁要解决的问题,其实一条sql就可以实现。

update t_goods set goods_num=goods_num - 1 where goods_id=1 and goods_num>0

如上所示。例如卖了id为1的商品1件。这时库存减一,重点是where条件中判断了goods_num>0。这样就间接的限制了只有库存在大于1的时候该sql才会减一。直接就防止了超卖的现象。其实这个时候应该就会有人抬杠了,这是电商场景呀,直接连接数据库压力很大的。其实这个时候就要在减库存之前进行友好的限流了。

redis提供了几个命令。

这几个都是原子操作,并且在执行成功之后会返回结果。例如:

redis> SET failure_times 10
OK
redis> DECR failure_times
(integer) 9

这样如果有场景数据库减库存压力太大,可以双重判断,商品开卖之前,redis缓存商品的库存,先通过DECR减少redis库存,再减少数据库库存,当redis库存已经为0的时候,就没有必要再减少数据库的数据了。

总结

如上便是我的想法,如果您有更好的解决方式,欢迎点评。

本文来自作者「叁滴水」投稿,谢谢分享,也欢迎爱好技术分享的各位技术朋友向「Java技术栈」投稿,让更多人看到,投稿方式:关注公众号「Java技术栈」在后台回复:投稿。

近期热文推荐:

1.600+ 道 Java面试题及答案整理(2021最新版)

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了,真香!

3.阿里 Mock 工具正式开源,干掉市面上所有 Mock 工具!

4.Spring Cloud 2020.0.0 正式发布,全新颠覆性版本!

5.《Java开发手册(嵩山版)》最新发布,速速下载!

觉得不错,别忘了随手点赞+转发哦!

标签:库存,num,数据库,redis,goods,防止,思路,超卖
来源: https://blog.51cto.com/u_15222959/2817105