实战 SpringCloud 微服务“秒杀”架构（含代码）

前言：

文章主要介绍了微服务“秒杀”架构原有方案及新增方案、核心支撑文件、秒杀系统场景特点、限流以及负载与分流等等内容。

分析，在做秒杀系统的设计之初，一直在思考如何去设计这个秒杀系统，使之在现有的技术基础和认知范围内，能够做到最好；同时也能充分的利用公司现有的中间件来完成系统的实现。

我们都知道，正常去实现一个WEB端的秒杀系统，前端的处理和后端的处理一样重要；前端一般会做CDN，后端一般会做分布式部署，限流，性能优化等等一系列的操作，并完成一些网络的优化，比如IDC多线路（电信、联通、移动）的接入，带宽的升级等等。而由于目前系统前端是基于微信小程序，所以关于前端部分的优化就尽可能都是在代码中完成，CDN这一步就可以免了；

原有方案：

通过分布式锁的方式控制最终库存不超卖，并控制最终能够进入到下单环节的订单，入到队列中慢慢去消费下单

新增方案

请求进来之后，通过活动开始判断和重复秒杀判断之后，即进入到消息队列，然后在消息的消费端去做库存判断等操作，通过消息队列达到削峰的操作

其实，我觉得两种方案都是可以的，只是具体用在什么样的场景；原有方案更适合流量相对较小的平台，而且整个流程也会更加简单；而新增方案则是许多超大型平台采用的方案，通过消息队列达到削峰的目的；而这两种方案都加了真实能进入的请求限制，通过redis的原子自增来记录请求数，当请求量达到库存的n倍时，后面再进入的请求，则直接返回活动太火爆的提示。整编：微信公众号，搜云库技术团队，ID：souy