秒杀系统设计

秒杀系统设计

首先我们进行秒杀（高并发系统）设计时，需要考虑和关注的问题：

第一点： 服务单一职责 + 独立部署

为了使得我们的秒杀服务不影响其他服务和功能，我们一般设置，建立独立的秒杀微服务，使得即使秒杀微服务自己扛不住，挂掉的情况下，也不会其他服务的正常运行。

第二点：秒杀链接的加密

如果让别人事先知道我们的秒杀链接地址，就会很容易造成链接的暴露，遭受恶意的攻击，故我们应该将我们的秒杀链接进行加密处理：

• 可以将链接地址进行MD5加密或者生成UUID，等到进行秒杀的时候才能看到
• 对于秒杀的商品，处于对应的商品ID以外，我们最少再带上一个随机码，只在秒杀成功时才进行返回

第三点：库存预热 + 快速扣减

因为秒杀场景一般都是读多写少的场景，十几万的并发访问，但是秒杀的商品数量可能只有100个左右，此时我们并不需要所有的请求都必须进来，进行实施时的库存校验。可以将库存预热，，设置一个定时任务，时间一到将秒杀的数据放在redis中，通过信号量控制进来秒杀的请求。即将秒杀商品的总数作为信号量存入到redis中

第四点：动静分离

使用Nginx做好动静分离，保证秒杀和商品详情页的动态请求才会打开后端的服务集群，使用CDN内容分发网络，分担集群的压力。

• 一个是将静态资源保存在Nginx服务器中，使得静态请求直接由Nginx处理返回，只有少量的动态请求才能路由到我们的后台服务器处理
• 或者将静态资源事先保存在阿里云等相关服务器的CND节点中，使得我们的静态请求直接去最近的CND节点上去拉取资源

第五点：恶意请求拦截

对于我们的秒杀连接的非法攻击请求，比如：每秒进行1000次刷新请求，肯定不是人为的，或者需要携带令牌的请求并未携带令牌，伪造请求过来；就需要识别这种非法攻击请求进行拦截

拦截的地方一般设置在网关层，使得我们进入网关以后的请求都是正常的动态请求

第六点：流量错峰

即使用各种手段，将流量分担到更大宽度的时间点，比如我们设置验证码，先加入购物车，等等方式。

第七点：限流，熔断，降级

限流分为前端限流和后端限流：

其中前端限流的比较常见的方式就是当我们点击了立即抢购按钮以后，只有一秒等时间以后才可以进行下一次的点击，或者只能点击一次，点击完了以后变成不可点击的状态。

而后端限流：首先可以先过滤是用户的请求，还是恶意攻击者的请求

对于用户的请求，即是正常的，我们也可以进行限流操作，比如：同一个IP的请求我们只接受一个或者几个（自己设置）

例如我们的网关层设置秒杀的总的访问量，当所有机器的访问量超过了这个数字，就会等上几秒再进行下一次的处理

熔断机制保证各个服务之间的快速响应：

如果此时秒杀服务需要调用其他服务进行处理，而在整个服务的调用链中存在某一个服务的处理时间过慢，等待的状况，我们需要将其服务进行熔断处理，返回快速失败，从而将其隔离，不影响其他服务之间的相互快速调用和响应。熔断隔离可以防止雪崩问题。

降级操作

或者当我们的服务压力过大，可以使用降级处理，例如：在服务的压力太大的情况下，可以进行降级，返回**当前访问量过大，请稍后处理。。。**等等相关信息，从而减少服务器的压力

第八点：队列削峰 – 使用消息队列

秒杀服务的杀手锏！！！当存在100万个请求，如果请求量再大，我们将秒杀成功的请求进入队列，慢慢创建订单，扣减库存即可。

如果秒杀的只是一个100个商品，此时我们使用Redis + 信号量，然后将获取到信号量的用户交给我们的订单集群进行处理即可。但是如果此时是双十一，存在大量进行秒杀的商品，此时，我们就需要使用到了消息队列，我们将获取到信号量的，即秒杀成功的用户请求，进入队列当中，然后我们的订单集群服务只需要从我们的队列中获取秒杀成功的请求，进行订单的创建和处理即可，这样就可以大大降低后端订单服务处理请求的压力！！！

高并发的秒杀系统的流程 — 独立服务【使用Redis + MQ消息队列】

根据上面的秒杀系统设计的几点考虑，我们的秒杀系统设计的大致思路如下所示：