注册网站名称,上海出大事啦,js打开本wordpress,集团网站建设管理制度最近业务试水电商#xff0c;接了一个秒杀的活。之前经常看到淘宝的同行们讨论秒杀#xff0c;讨论电商#xff0c;这次终于轮到我们自己理论结合实际一次了。 ps#xff1a;进入正文前先说一点个人感受#xff0c;之前看淘宝的ppt感觉都懂了#xff0c;等到自己出解决方… 最近业务试水电商接了一个秒杀的活。之前经常看到淘宝的同行们讨论秒杀讨论电商这次终于轮到我们自己理论结合实际一次了。 ps进入正文前先说一点个人感受之前看淘宝的ppt感觉都懂了等到自己出解决方案的时候发现还是有很多想不到的地方其实都没懂再次验证了“细节是魔鬼”的理论。并且一个人的能力有限只有大家一起讨论才能想的更周全更细致。好了闲话少说下面进入正文。 一、秒杀带来了什么 秒杀或抢购活动一般会经过【预约】【抢订单】【支付】这3个大环节而其中【抢订单】这个环节是最考验业务提供方的抗压能力的。 抢订单环节一般会带来2个问题 1、高并发 比较火热的秒杀在线人数都是10w起的如此之高的在线人数对于网站架构从前到后都是一种考验。 2、超卖 任何商品都会有数量上限如何避免成功下订单买到商品的人数不超过商品数量的上限这是每个抢购活动都要面临的难题。 二、如何解决 首先产品解决方案我们就不予讨论了。我们只讨论技术解决方案 1、前端 面对高并发的抢购活动前端常用的三板斧是【扩容】【静态化】【限流】 A扩容 加机器这是最简单的方法通过增加前端池的整体承载量来抗峰值。 B静态化 将活动页面上的所有可以静态的元素全部静态化并尽量减少动态元素。通过CDN来抗峰值。 C限流 一般都会采用IP级别的限流即针对某一个IP限制单位时间内发起请求数量。 或者活动入口的时候增加游戏或者问题环节进行消峰操作。 D有损服务 最后一招在接近前端池承载能力的水位上限的时候随机拒绝部分请求来保护活动整体的可用性。 2、后端 那么后端的数据库在高并发和超卖下会遇到什么问题呢主要会有如下3个问题主要讨论写的问题读的问题通过增加cache可以很容易的解决 I 首先MySQL自身对于高并发的处理性能就会出现问题一般来说MySQL的处理性能会随着并发thread上升而上升但是到了一定的并发度之后会出现明显的拐点之后一路下降最终甚至会比单thread的性能还要差。 II 其次超卖的根结在于减库存操作是一个事务操作需要先select然后insert最后update -1。最后这个-1操作是不能出现负数的但是当多用户在有库存的情况下并发操作出现负数这是无法避免的。 III最后当减库存和高并发碰到一起的时候由于操作的库存数目在同一行就会出现争抢InnoDB行锁的问题导致出现互相等待甚至死锁从而大大降低MySQL的处理性能最终导致前端页面出现超时异常。 针对上述问题如何解决呢 我们先看眼淘宝的高大上解决方案 I 关闭死锁检测提高并发处理性能。 II修改源代码将排队提到进入引擎层前降低引擎层面的并发度。 III组提交降低server和引擎的交互次数降低IO消耗。 以上内容可以参考丁奇在DTCC2013上分享的《秒杀场景下MySQL的低效》一文。在文中所有优化都使用后TPS在高并发下从原始的150飙升到8.5w提升近566倍非常吓人 不过结合我们的实际改源码这种高大上的解决方案显然有那么一点不切实际。于是小伙伴们需要讨论出一种适合我们实际情况的解决方案。以下就是我们讨论的解决方案 首先设定一个前提为了防止超卖现象所有减库存操作都需要进行一次减后检查保证减完不能等于负数。由于MySQL事务的特性这种方法只能降低超卖的数量但是不可能完全避免超卖 update number set xx-1 where (x -1 ) 0; 解决方案1 将存库从MySQL前移到Redis中所有的写操作放到内存中由于Redis中不存在锁故不会出现互相等待并且由于Redis的写性能和读性能都远高于MySQL这就解决了高并发下的性能问题。然后通过队列等异步手段将变化的数据异步写入到DB中。 优点解决性能问题 缺点没有解决超卖问题同时由于异步写入DB存在某一时刻DB和Redis中数据不一致的风险。 解决方案2 引入队列然后将所有写DB操作在单队列中排队完全串行处理。当达到库存阀值的时候就不在消费队列并关闭购买功能。这就解决了超卖问题。 优点解决超卖问题略微提升性能。 缺点性能受限于队列处理机处理性能和DB的写入性能中最短的那个另外多商品同时抢购的时候需要准备多条队列。 解决方案3 将写操作前移到Memcached中同时利用Memcached的轻量级的锁机制CAS来实现减库存操作。 优点读写在内存中操作性能快引入轻量级锁之后可以保证同一时刻只有一个写入成功解决减库存问题。 缺点没有实测基于CAS的特性不知道高并发下是否会出现大量更新失败不过加锁之后肯定对并发性能会有影响。 解决方案4 将提交操作变成两段式先申请后确认。然后利用Redis的原子自增操作相比较MySQL的自增来说没有空洞同时利用Redis的事务特性来发号保证拿到小于等于库存阀值的号的人都可以成功提交订单。然后数据异步更新到DB中。 优点解决超卖问题库存读写都在内存中故同时解决性能问题。 缺点由于异步写入DB可能存在数据不一致。另可能存在少买也就是如果拿到号的人不真正下订单可能库存减为0但是订单数并没有达到库存阀值。 三、总结 1、前端三板斧【扩容】【限流】【静态化】 2、后端两条路【内存】【排队】 四、非技术感想 1、团队的力量是无穷的各种各样的解决方案先不谈可行性都是在小伙伴们七嘴八舌中讨论出来的。我们需要让所有人都发出自己的声音不要着急去否定。 2、优化需要从整体层面去思考不要只纠结于自己负责的部分如果只盯着一个点思考最后很可能就走进死胡同中了。 3、有很多东西以为读过了就懂了其实不然。依然还是需要实践否则别人的知识永远不可能变成自己的。 4、多思考为什么会发生什么不要想当然。只有这样才能深入进去而不是留在表面。 ps以上仅仅是我们讨论的一些方案设想欢迎大家一起讨论各种可行方案。 本文转自http://www.cnblogs.com/billyxp/p/3701124.html
