在大多数业务公司,由于人员匮乏,技术实例储备不多,而且还有可能用户量不多,所以大部分的秒杀系统架构方案都是采用的同步的解决方案,这个同步的解决方案是什么样子的呢?在这里给大家弄一个图展示下。
这里详细的给大家介绍下对应的秒杀请求流程
1)用户发起秒杀请求 2)服务端首先识别判断下验证码是否正确,如果不正确则直接返回错误的信息,如果正确则进行到下一步。 3)服务端判断根据redis缓存预热的数据,判断活动是否已经结束,如果结束则返回错误信息,如果没结束,则进行到下一步 4)服务端验证访问请求的ip是否处于黑名单内,如果在黑名单内,则直接返回错误信息,如果没在黑名单内,则进行到下一步。 这里主要是由于电商领域里面存在很多恶性竞争,还有很多恶意抢购的灰产通过不正当手段恶意请求,占用大量的系统资源和带宽资源。 5)验证真实库存是否足够,如果库存不足,则返回错误信息,如果库存足够,则进行到下一步。 6)扣减缓存中的库存,由于是前端拦截系统,这里直接扣除缓存中的库存。 7)计算秒杀价格,由于秒杀价格和真实的商品价格可能存在差异,所以需要计算核对真实的商品价格。除了价格外,有的活动还可以使用优惠券等,就更多了,所以这里都要进行相关的处理 8)把真实价格返回给客户端 9)客户端根据真实的价格发起订单提交请求 10)服务端收到请求后验证相关的参数 11)服务端进行真实库存的扣减,并且创建新的订单,返回给客户端通知支付 12)客户端进行支付操作。
又回到开始,我们提到过这种方案一般不太建议采取。有一些小伙伴说,我们公司就是这样做的,一直都在用,从来没出现过问题啊。其实根本的原因就是使用同步下单方式确实可以做秒杀系统,但是同步下单的性能不会太高。之所以你们公司采用同步下单的方式做秒杀系统没出现大的问题,那是因为你们的秒杀系统的并发量没达到一定的量级,也就是说,你们的秒杀系统的并发量其实并不高。如果12306、淘宝、天猫、京东、小米等大型商城的秒杀系统是这么玩的话,那么,他们的系统迟早会被玩死,他们的系统工程师不被开除才怪!所以,在秒杀系统中,这种同步处理下单的业务流程的方案是不可取的。
以上就是秒杀系统的同步方案,大家可以多熟悉下,最后总结下:
1、这个同步方案的流程没问题。
2、同步方案的并发量真的很低
还没有评论,来说两句吧...