秒杀系统项目实战（七）秒杀系统架构方案之同步解决方案

在大多数业务公司，由于人员匮乏，技术实例储备不多，而且还有可能用户量不多，所以大部分的秒杀系统架构方案都是采用的同步的解决方案，这个同步的解决方案是什么样子的呢？在这里给大家弄一个图展示下。

这里详细的给大家介绍下对应的秒杀请求流程

1）用户发起秒杀请求

2）服务端首先识别判断下验证码是否正确，如果不正确则直接返回错误的信息，如果正确则进行到下一步。

3）服务端判断根据redis缓存预热的数据，判断活动是否已经结束，如果结束则返回错误信息，如果没结束，则进行到下一步

4）服务端验证访问请求的ip是否处于黑名单内，如果在黑名单内，则直接返回错误信息，如果没在黑名单内，则进行到下一步。
   这里主要是由于电商领域里面存在很多恶性竞争，还有很多恶意抢购的灰产通过不正当手段恶意请求，占用大量的系统资源和带宽资源。

5）验证真实库存是否足够，如果库存不足，则返回错误信息，如果库存足够，则进行到下一步。

6）扣减缓存中的库存，由于是前端拦截系统，这里直接扣除缓存中的库存。

7）计算秒杀价格，由于秒杀价格和真实的商品价格可能存在差异，所以需要计算核对真实的商品价格。除了价格外，有的活动还可以使用优惠券等，就更多了，所以这里都要进行相关的处理

8）把真实价格返回给客户端

9）客户端根据真实的价格发起订单提交请求

10）服务端收到请求后验证相关的参数

11）服务端进行真实库存的扣减，并且创建新的订单，返回给客户端通知支付

12）客户端进行支付操作。

又回到开始，我们提到过这种方案一般不太建议采取。有一些小伙伴说，我们公司就是这样做的，一直都在用，从来没出现过问题啊。其实根本的原因就是使用同步下单方式确实可以做秒杀系统，但是同步下单的性能不会太高。之所以你们公司采用同步下单的方式做秒杀系统没出现大的问题，那是因为你们的秒杀系统的并发量没达到一定的量级，也就是说，你们的秒杀系统的并发量其实并不高。如果12306、淘宝、天猫、京东、小米等大型商城的秒杀系统是这么玩的话，那么，他们的系统迟早会被玩死，他们的系统工程师不被开除才怪！所以，在秒杀系统中，这种同步处理下单的业务流程的方案是不可取的。

以上就是秒杀系统的同步方案，大家可以多熟悉下，最后总结下：

1、这个同步方案的流程没问题。

2、同步方案的并发量真的很低