JAVA 抢购实现问题 急!!!!!!!!!!!!!!!!

darlling 2013-06-22 07:34:45
网站需要开发一个限时限量抢购功能。
遇到问题:
当很多人同时抢一个东西时,会超出限制数量。
原因:生成订单之前有一系列判断,很多用户同时进行这些判断,通过之后保存订单,这里有很多用户会通过购买验证,导致超量。
...全文
991 7 打赏 收藏 转发到动态 举报
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
qq_32213697 2015-10-22
  • 打赏
  • 举报
回复
跟你说一下思路: 第一种方法:悲观锁、实务未完成前拒绝其他请求,但是很明显会影响效率并且有些请求可能永远拿不到这个锁。 第一种方法:队列、就是将所有请求放到队列里,按照先来先处理,原则上这样所有请求最后都会被处理。但是当你处理速度长时间跟不上请求访问数,很可能会撑爆你的队列内存。 第二种方法:乐观锁、简单理解就是在悲观锁基础上加上版本控制,允许多线程同时请求,但是为每个请求加上版本标示,比如有a、b两个请求,一开始a先来,版本为1.0,a进入处理,然后b请求,版本也为1.0,当a处理完成,版本依然为1.0,实务成功,版本变为1.1,此时b处理成功发现版本为1.1,与自己的1.0不对应,实务回滚
xiaohui0929 2014-09-17
  • 打赏
  • 举报
回复
楼主解决了吗?我也需要的了这个问题,还望楼主分享一下
one-fly 2014-04-16
  • 打赏
  • 举报
回复
是redis不是redid打错了
one-fly 2014-04-16
  • 打赏
  • 举报
回复
可以将商品数量保存到redid中,多个用户对商品数量key调用decr命令,并且都会返回一个值,只有当返回的值大于零时,才生成订单,其他的都算是抢购失败,redis是单线程处理数据的,所以不会有并发问题,至于效率肯定比数据库快!希望能帮到你!
  • 打赏
  • 举报
回复
要用到线程锁吧
北吹 2013-06-26
  • 打赏
  • 举报
回复
抢购的实质还是排队,先抢先得。 个人观点,做成队列,服务端和客户端异步。所有通过验证的用户都把信息丢入队列,服务端依次从队列里取用户,取满为止。 这样可以解决超量问题,不过客户端抢购结果会有一定延迟。
妞_ 2013-06-26
  • 打赏
  • 举报
回复
不会!

67,513

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧