一、怎么防止多用户同一时间抢购同一商品,防止高并发同时下单同一商品?
http://ask.csdn.net/questions/159351
http://www.cnblogs.com/lingmaozhijia/articles/1339222.html
最近在做抢购系统,但头疼的是,在多用户高并发的情况下经常会库存出现问题。排查到,在同一时间内多用户同时下单导致查询和插入不同步了,而查询中跟插入又有时间差而在高并发的情况下导致库存问题(我的项目大概是这样,首先 for update查出商品信息表,放入全局表里数组里,当用户扣款余额成功后,update商品信息表减去该用户下单的数量。数据库用的mysql,查询商品信息表的时候是加锁过的,但商品信息表数据越来越多的时候查询有时间差,导致高并发的时候在查询商品信息表放进变量数组里的时候,在执行后面的时间差里,其他用户也在下单,导致库存有问题)。现在提问,同一时间内同一个商品防止多用户抢购,也就是说同一秒内在高并发的情况下只能被一个用户下单,目前的思路是排队,阻塞队列。
1、update table set num=num-1 where num>1
不查直接更新,更新成功代表抢到了
2、把抢购系统放成两步,第一步为下单(即抢购),下单成功立即减少数量,更新表数据,
第二部为付款,后台写个程序,如果半个小时不付款,自动删除订单,然后增加数量。
这样的话,可以避过并发了,如果一步走,时间再短也会有并发的问题。
3、数据库中可以加行锁
4、好像有点像我买飞机票
下单立即就减数量,半小时不付款则取消订单 数量恢复。
5、可以使用队列+锁表来做。
二、最近一公司在为我单位在B/S平台上做生产调度管理,平台是MySQL4.0+Java。在测试过程中我发现开发人员没有对数据的并发进行控制。即两个人同时修改一条记录时,两个人均可提交,且最后提交人的数据会复盖前面修改人的记录。
本人对此提出异议后,软件开发人员告之,用生产管理系统中的权限管理,就可解决并发控制的问题!!!
我认为由于B/S结构不能象C/S结构那样始终与数据库相连,所以数据库本身进行并发控制的能力就被削弱了,故在提交前需要前台程序进行相应判断。而使用任何权限来限制用户的写操作(对同一条记录),从根本上是无法避免并发产生的!
1、如果把程序中的SQL语句,也就是UPDATE改一下应该就可以了吧!UPDATE加上WHERE条件,不光是主键相等,而且更新的字段,也必须加上原始的值.如表结构为:
ID,aNAME,age
数据
100,anders,40
101,arg,56
如果要把arg的name改为args的话
update 表名 set aname = 'args' where ID = 101 and aname = 'arg'
这样的话如果人先把aname改为其它的,更新就是报错!不会出现楼主所说的情况。
三、网站并发
时常看到高并发的问题,但高并发其实是最不需要考虑的东西。为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实你已经在用了。有这个意识就够了,不需要时刻盯着这个问题。只很少的网站真的能达到高并发。
简单做一个归纳,从低成本、高性能和高扩张性的角度来说有如下处理方案:
1、HTML静态化
2、图片服务器分离
3、数据库集群和库表散列
4、缓存
5、镜像
6、负载均衡;一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。
下面也是一个牛人所做的总结,跟上面部分相同。 高并发时,性能瓶颈及当前常用的应对措施
1.数据库瓶颈。Mysql并发链接100
2.apache 并发链接1500
3.程序执行效率
1.有数据库瓶颈时,当前处理方案无外乎 主从,集群。增加memcached【内存对象缓存系统】
如:手机之家新系统介绍及架构分享(http://www.slideshare.net/Fenng/ss-1218991?from=ss_embed)
就是在cache【缓存】层做优化 。又拍网架构(http://www.bopor.com/?p=652) 是以增加数据库,分表分库的方法解决。 Sina增加了mq(消息队列)来分发数据。 还风站用了key-value的数据库。其实这可以理解成一个持久化的缓存。
2.apache瓶颈。
增加服务器。负载均衡。如sina的F5
由于进程数的限制。会把一些基本不变的代码挪出来放到单独的服务器。如css/js/图片。
国内成功的案例是tom的cdn。又如nginx的横空出世和squid的反向代理都是基于这个原因出来的。
3.php的执行效率。原因有多个。
1).本身的效率低。
解决的成功案例是Zend Optimizer 和 facebooke的hiphop。Taobao是把php代码编译成模块解决效率问题。
2). 数据库查询效率问题。如可能有order by ,group by 等Sql数据问题。
这个其实应该归结到数据库设计问题。
解决的办法是建立正确的索引。增加memcache【分布式的高速缓存系统】。
对like表 用专用的sphinx.【SQL的全文检索引擎】和lucence 【基于Java 的全文信息检索】等搜索服务。
程序员都应该会用explain对sql语句作分析。
四、Web系统大规模并发—电商秒杀与抢购
http://www.csdn.net/article/2014-11-28/2822858
2. 悲观锁思路
解决线程安全的思路很多,可以从“悲观锁”的方向开始讨论。
悲观锁,也就是在修改数据的时候,采用锁定状态,排斥外部请求的修改。遇到加锁的状态,就必须等待。
虽然上述的方案的确解决了线程安全的问题,但是,别忘记,我们的场景是“高并发”。也就是说,会很多这样的修改请求,每个请求都需要等待“锁”,某些线程可能永远都没有机会抢到这个“锁”,这种请求就会死在那里。同时,这种请求会很多,瞬间增大系统的平均响应时间,结果是可用连接数被耗尽,系统陷入异常。
3. FIFO队列思路
那好,那么我们稍微修改一下上面的场景,我们直接将请求放入队列中的,采用FIFO(First Input First Output,先进先出),这样的话,我们就不会导致某些请求永远获取不到锁。看到这里,是不是有点强行将多线程变成单线程的感觉哈。
然后,我们现在解决了锁的问题,全部请求采用“先进先出”的队列方式来处理。那么新的问题来了,高并发的场景下,因为请求很多,很可能一瞬间将队列内存“撑爆”,然后系统又陷入到了异常状态。或者设计一个极大的内存队列,也是一种方案,但是,系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说,队列内的请求会越积累越多,最终Web系统平均响应时候还是会大幅下降,系统还是陷入异常。
4. 乐观锁思路
这个时候,我们就可以讨论一下“乐观锁”的思路了。乐观锁,是相对于“悲观锁”采用更为宽松的加锁机制,大都是采用带版本号(Version)更新。实现就是,这个数据所有请求都有资格去修改,但会获得一个该数据的版本号,只有版本号符合的才能更新成功,其他的返回抢购失败。这样的话,我们就不需要考虑队列的问题,不过,它会增大CPU的计算开销。但是,综合来说,这是一个比较好的解决方案。
有很多软件和服务都“乐观锁”功能的支持,例如Redis中的watch就是其中之一。通过这个实现,我们保证了数据的安全。
1)、乐观锁存在的问题,例: 两个请求(A、B)同时都会更新一条记录, A更新(判断版本通过)这时A事务还没结束(后面还有逻辑), 此时,B也更新(判断版本也通过)B事务结束, 后面A结束,这样A事务的更新不就错了吗(脏读) 。(乐观锁本来就不能解决脏读的问题)
相关推荐
在本电商网站实例中,我们将深入探讨MySQL数据库在构建电子商务平台中的关键作用。MySQL作为一款广泛应用的关系型数据库管理系统,以其高效、稳定和易用性深受开发者喜爱,尤其适合处理大量在线交易数据。在这个电商...
- **读写分片优化**:通过 Redis 分片技术,可以将数据分散在多个 Redis 实例上,分散读写压力,实现更高的并发处理能力。 5. **Redis 的其他高级特性** - **持久化**:Redis 提供 RDB 和 AOF 两种持久化方式,...
- 并发编程是应对高流量电商网站的关键,涉及线程池管理、锁机制(如synchronized、ReentrantLock)、并发容器(如ConcurrentHashMap)以及并发工具类的使用。 - 使用非阻塞I/O(NIO)和异步编程模型可以提高系统...
在构建一个基于SpringMVC的电商高并发秒杀系统时,设计思路往往涉及到多个关键领域。首先,我们从系统架构层面来分析,秒杀场景下的系统设计需要考虑到以下几个核心要点: 1. **高并发处理**:秒杀活动通常会引来...
在千亿级电商秒杀解决方案专题中,我们探讨的是如何在大规模并发...以上就是千亿级电商秒杀解决方案涉及的关键技术点,通过这些技术的综合运用,可以构建一个高效、稳定、安全的秒杀系统,满足高并发场景下的业务需求。
综上所述,这个电商项目实例不仅涵盖了基础的SSM框架使用,还涉及到分布式服务、缓存管理、消息队列以及单点登录等高级话题,对于提升开发者在分布式系统设计和实现上的能力具有很大的价值。学习并掌握这些知识,...
### 高并发高可用的电商平台架构 #### 一、设计理念 **1. 空间换时间** - **多级缓存与静态化** - **客户端页面缓存**:利用HTTP Header中的`Expires`、`Cache-Control`、`Last-Modified` (304响应码表示客户端...
分布式高级电商项目是一种复杂而高效的在线商业解决方案,它利用了现代技术栈来处理高并发、大数据量和实时性要求的问题。在这个项目中,主要采用了以下技术组件: 1. SOA(Service-Oriented Architecture,面向...
在实际项目中,例如一个电商系统,用户同时浏览商品时,可能会触发并发问题。通过设置适当的事务隔离级别,如可重复读,可以避免用户看到其他用户未完成的订单。同时,使用悲观锁在查看商品详情时锁定商品,确保其他...
【电商分布式系统】是现代电商平台的核心技术架构,它旨在通过将单个应用程序分解为一系列可独立部署的服务,来实现高可扩展性、高可用性和快速响应。淘淘商城的源代码是一个实例,展示了如何构建这样的分布式系统。...
【电商项目demo--天天新鲜】是一个综合性的电商项目实例,主要展示了如何利用现代技术栈构建一个功能完善的在线购物平台。该项目包含多个关键模块和技术,旨在处理高并发的订单处理、商品搜索以及提供高效的存储和...
在高并发环境中,系统往往面临着连接超时和资源超卖的问题,特别是在电商秒杀或抢购场景中,数据库和缓存系统的压力巨大。本示例针对这些问题,利用Redis的乐观锁机制来提供解决方案。Redis是一种高性能的键值存储...
2. **业务流程**:理解生鲜电商的业务模式,如采购、存储、配送等,确保系统支持这些流程的顺畅执行。 3. **功能需求**:列出系统必须实现的功能,例如商品分类与搜索、购物车管理、在线支付、订单处理、库存管理、...
在现代互联网环境中,电商平台面临的重要挑战之一就是处理高并发访问,同时保持系统高可用性。本文将深入探讨如何构建一个能够应对大规模并发访问,并且具备高可用性的分布式电商平台架构。 一、负载均衡 高并发...
4. **分布式**:在大型电商系统中,分布式技术是解决高并发、海量数据问题的关键。分布式数据库、分布式缓存、分布式任务调度等都是电商系统中的常见应用场景。分布式设计可以提高系统的可用性和处理能力,例如,...
### 高性能高并发服务的瓶颈及突破思路 #### 一、服务的瓶颈解析 在构建高性能、高并发的服务过程中,首先要明确程序的核心组成:**算法**、**数据结构**和**数据**。这些组成部分决定了程序对计算机资源的需求,...
总之,MGR云服务在电商业务中的应用展示了其强大的可伸缩性、高可用性和故障自修复能力,这些特点使其成为电商等需要高稳定性和高可用性的业务的首选解决方案。通过上述的实践与优化,MGR不仅能够保障数据的一致性和...
本文将深入探讨电商架构的关键要素,包括高并发处理、数据实时性与准确性、动态页面处理、商品图片展示优化、搜索引擎集成、读写操作平衡、数据管理策略、以及业务增长应对策略。 #### 高并发处理与数据实时性 ...