这一次，彻底弄懂“秒杀系统” _秒杀系统

【51CTO.com原创稿件】说到“秒杀”，恐怕大多数人想到的就是“双 11”，“促销”，“买买买”等火爆的场面吧。

文章插图

图片来自 Pexels
大家为了打折商品蜂拥而至，造成电商网站一片繁华的景象。但作为程序员的我们，看到的却是背后的高并发和可靠性。无论你处在软件开发的哪个阶段，都希望能够设计一套属于自己的秒杀系统。
今天我们一起来看看，一套秒杀系统在架构设计上需要有哪些考量：

秒杀场景的特点
系统隔离的设计思路
客户端设计
代理层设计
应用层设计
数据库设计
压力测试
总结

秒杀场景的特点
秒杀场景是电商网站定期举办的活动，这个活动有明确的开始和结束时间，而且参与互动的商品是事先定义好了，参与秒杀商品的个数也是有限制的。同时会提供一个秒杀的入口，让用户通过这个入口进行抢购。
总结一下秒杀场景的特点：

定时开始，秒杀时大量用户会在同一时间，抢购同一商品，网站瞬时流量激增。
库存有限，秒杀下单数量远远大于库存数量，只有少部分用户能够秒杀成功。
操作可靠，秒杀业务流程比较简单，一般就是下订单减库存。库存就是用户争夺的“资源”，实际被消费的“资源”不能超过计划要售出的“资源”，也就是不能被“超卖” 。

系统隔离的设计思路
在分析秒杀的特点后，我们发现秒杀活动是有计划的，并且在短时间内会爆发大量的请求。为了不影响现有的业务系统的正常运行，我们需要把它和现有的系统做隔离。
即使秒杀活动出现问题也不会影响现有的系统。隔离的设计思路可以从三个维度来思考。

业务隔离
技术隔离
数据库隔离

业务隔离
既然秒杀是一场活动，那它一定和常规的业务不同，我们可以把它当成一个单独的项目来看。在活动开始之前，最好设计一个“热场” 。
“热场”的形式多种多样，例如：分享活动领优惠券，领秒杀名额等等。“热场”的形式不重要，重要的是通过它获取一些准备信息。
例如：有可能参与的用户数，他们的地域分布，他们感兴趣的商品。为后面的技术架构提供数据支持。
技术隔离

文章插图

技术隔离架构图
前面有了准备工作，那么从技术上需要有以下几个方面的考虑：

客户端，前端秒杀页面使用专门的页面，这些页面包括静态的 html 和动态的 JS，他们都需要在 CDN 上缓存。
接入层，加入过滤器专门处理秒杀请求，即使我们扩展再多的应用，使用再多的应用服务器，部署再多的负载均衡器，都会遇到支撑不住海量请求的时候。

所以，在这一层我们要考虑的是如何做好限流，当超过系统承受范围的时候，需要果断阻止请求的涌入。

应用层，瞬时的海量请求好比请求的“高峰”，我们架构系统的目的就是“削峰” 。

需要使用服务集群和水平扩展，让“高峰”请求分流到不同的服务器进行处理。同时，还会利用缓存和队列技术减轻应用处理的压力，通过异步请求的方式做到最终一致性。
由于是多线程操作，而且商品的额度有限，为了解决超卖的问题，需要考虑进程锁的问题。
数据库隔离
秒杀活动持续时间短，瞬时数据量大。为了不影响现有数据库的正常业务，可以建立新的库或者表来处理。
在秒杀结束以后，需要把这部分数据同步到主业务系统中，或者查询表中。如果数据量特别巨大，到千万级别甚至上亿，建议使用分表或者分库。
客户端设计
上面提到的三个隔离维度中，我们对技术维度是最为关心的。如果说浏览器/客户端是用户接触“秒杀系统”的入口，那么在这一层提供缓存数据就是非常必要的。
在设计之初，我们会为秒杀的商品生成专门的商品页面和订单页面。这些页面以静态的 HTML 为主，包括的动态信息尽量少。
从业务的角度来说，这些商品的信息早就被用户熟识了，在秒杀的时候，他们关心的是如何快速下单。
既然商品的详情页面和订单页面都是静态生成的，那么就需要定义一个 URL，当要开始秒杀之前，开放这个 URL 给用户访问。