什么是电商秒杀系统--参考文档

秒杀项目

目标：从0到1构建一个高并发的秒杀系统

三个阶段

从0到1构建一个电商系统

从0到1构建秒杀系统

从0到1构建高并发秒杀系统

为了完成这个目标，我们需要知道几个前提

1、什么是电商

2、什么是秒杀

3、什么是高并发

4、如何设计高并发秒杀系统

什么是电商

商家通过互联网(软件)的方式来销售商品。就是电商。

例如，我们所看到的，什么淘宝，京东之类。良品铺子，都可以在网上进行购买他们的商品，这些就是电商

电商类型

个人电商：

软件只买一家门店的商品就是个人电商，

例如：良品铺子通过软件买的商品，各位同学去开一家门店，然后通过软件来卖自家的商品，就是电商

平台电商

软件卖多家门店的商品就是平台电商，例如：淘宝，京东就属于这一类

如何开发电商

为什么会出现电商

首先，我们要弄明白一点，没有电商之前，我们是通过门店来销售商品，还有的是通过会销等其他方式，我们只讨论门店销售

这一块。

这个时候，随着互联网的出现，越来越多的人发现门店销售有限，只能够销售一方，这个时候就有人想，如果我们想将商品销售到全中国，于是有人准备去开很多分店去解决，但是发现，成本太高。这个时候，有人就想，我们想销售到全中国的同时，想大量的降低成本。所以大家发现互联网发送一个消息全中国的人都可以收到，于是，马云说，我们来尝试一下吧。成功我就发了，不成功 ，我就做杭州教英语，继续老师。没有想到，成功了，所以了就出现了电商。

我为什么要说这段故事呢，很简单，大家有没有发现，电商的前身就是门店，他们两个是不同场合不同的名称。就好像黑白无常一样，知道了黑，就知道了白。

所以，如果我们想开发一个电商项目，就必须知道门店是如何经营的，也就是说，我们必须知道门店他们是如何卖商品的。有哪些角色组成。

大家好好想一下，门店内卖商品的流程，我就比如去良品铺子进行

消费者，商品，付钱，发票单(个人电商)

消费者----->选择商品------>付钱-------->发票单(什么时候买的什么商品)

我们就可以得到最简单的商品购买流程。（个人大型电商）

如果出现超市之类的，加一个购物车，先放到购物车，然后一起付钱

消费者----->选择商品----->购物车------>付钱-------->发票单(什么时候买的什么商品)

如果是去商场之类的，就加一个商家（平台电商）

消费者----->商家------>选择商品----->购物车------>付钱-------->发票单(什么时候买的什么商品)

模块设计

我们以开发一个最简单的电商项目为例

消费者----->选择商品------>付钱-------->发票单(什么时候买的什么商品)

我们可以得出这4个模块

用户模块

商品模块

支付模块

订单模块

不管多复杂的电商，所有的都是在这个基础上扩展出来的新的模块，例如：购物车，商家，发货，评价，退款，秒杀等等

什么是秒杀

秒杀就是在很短时间内，卖出所有的商品。

就好比，我们在淘宝网看到的商品，京东上看到的秒杀，我们扩展一下，还有很多类似的场景

春节，我们在12306抢票，我们在支付宝抢红包，在微服务摇一摇等等都是秒杀的场景。

秒杀类型

1秒秒杀类型

1秒类秒杀有限商品

分钟秒杀类型

一分钟之类秒杀有限商品

小时秒杀类型

1小时之类秒杀所有商品

1天内秒杀类型

1天之类秒杀所有商品

如何实现秒杀系统

为什么会出现秒杀

我们刚才看到，秒杀就是在有限的时间秒杀商品，说明秒杀针对的对象还是商品

说明什么，说明秒杀是在商品的基础上扩展出来的。只是加了有一个时间限制。所以我们可以得到秒杀商品是属于商品的一个类型，属于什么类型呢，属于商品营销类型，秒杀本质上就是一种营销活动，所以我们可以得出秒杀就是商品的营销类型。

因此，如果我们要设计一个秒杀系统，我们必须知道电商的逻辑

消费者----->选择商品------>付钱-------->发票单(什么时候买的什么商品)

消费者----->秒杀商品(时间限制)------>付钱-------->发票单(什么时候买的什么商品)

模块设计

所有秒杀系统设计还是和原有逻辑没有变化，只是把普通商品替换了。

其实我们只需要设计一个模块即可，我们可以把时间设置到秒杀模块里面，但是时间有很多类型，很多商品都需要设置时间

秒杀模块

时间模块

秒杀系统过渡到高并发

如果我们想将一个秒杀系统设计成为一个高并发的秒杀系统，光有这些设计是不够的，我们还需要知道什么是高并发

前面我们讲过了相应的高并发知识点，但是我们在这里还是要回顾一下高并发的知识点。

什么是高并发

高并发就是在1秒内用户请求非常大，服务器能够处理在1秒之内能够这些请求，不会导致服务器宕机。就是高并发。

高并发指的是1秒内用户用户请求数，高并发能力就是指服务器处理能力。

多大才算高并发

那么什么用户达到多少请求才算是高并发呢？

答案：这个问题的答案不是指系统处理的一个数字。

为什么会有高并发

一般我们开发一个项目，都会把所有的模块全部一次性放到一个项目中进行开发，然后进行部署，最后进行优化。

如果我们的系统目前并发量为300，也就是每秒能够处理300个请求。

随着用户请求数，在1秒内出来的请求，发出600并发，这个时候，系统变得非常慢。接下来，我们就开始优化，如何保证系统能够处理600个并发量，

如果我们优化后，单机可以达到600并发量的出来，

但是，用户数是不稳定的，如果用户在1秒内请求持续加大，达到了1000千，

我们接下来继续优化系统，发现系统的1秒最高并发量为600，大了就响应变慢，甚至宕机了。

这个时候，我们又开始优化，如何 保证系统能够处理1000并发量。

随着用户数，持续增大，到达45

42·9 2000,10000,10W,100W持续增加，那我们系统如何能处理这么大的请求量呢 ？

答案：继续优化。

现在我们发现系统处理的请求数是一个持续的问题，不是一劳永逸的问题。

来看一个场景：

固态硬盘SSD（Solid State Disk）说：我读取和写入高达 1000MB/秒

mysql说：我单机TPS10000+

nginx说：我单机QPS10W+

静儿说：给我一台56核200G高配物理机，我可以创建一个单机QPS1000W

总结

如果硬是要说高并发有一个标准，就是超过了单机处理的最大并发量，就算是高并发

高并发的本质不是「多大算高并发」的一个数字，而是从架构上、设计上、编码上怎么来保证或者解决由并发引起的问题。

当别人问你：“做过高并发吗？”回答者完全可以描述自己系统的各项指标，然后开始叙述自己对系统中对预防、解决并发问题作出的思考和行动。

高并发量级

高并发量级一般是指系统能够在一天处理的请求数

千万级并发

亿级并发

10亿级并发

服务器并发处理能力

1秒内能够响应的请求数。这个数有多大，才是服务器并发能力

如何实现高并发

拆分原则

系统角度：按照系统功能/业务功能拆分，比如商品系统，购物车系统，结算系统，订单系统等

功能角度：对一个系统功能进行再次拆分，比如，优惠券系统可以拆分为后台劵创建系统，领劵系统，用劵系统

读写角度：根据读写比例特征进行拆分，比如，商品系统，交易的各个系统都会读取数据，读的流量大于写，因此可以拆分成商品写服务，商品读服务，读服务 可以考虑使用缓存提升性能，写的量太大，需要考虑分库分表，有些聚合读写的场景，如商品详情页，可考虑数据异构拆分系统，将分散在多处的数据聚合在一起存储，以提升系统的性能和可靠性。

aop角度：根据访问特征，按照AOP进行拆分，比如，商品详情页可以拆分为CDN,页面渲染系统，CDN就是一个AOP系统，

模块角度：比如，按照基础或者代码维护特征进行拆分，如基础模块分库分表，数据库连接池等，代码结构一般按照三层架构（Web Service DAO）进行划分

无状态原则

如果设计的系统是无状态的，那么应用就非常容易水平扩展，实际生产环境可能是这样的，应用无状态，配置文件有状态，比如，不同的机房需要读取不同的数据源，此时，就需要通过配置文件或配置中心指定。

服务化原则

首先，判断是不是只需要简单的单点远程服务调用，单机不行集群是不是就可以解决，在客户端注册多台机器并使用Nginx进行负载均衡是不是就可以解决？

总结为：进程内服务------>单机远程服务------>集群手动注册服务-------->自动注册和发现服务--------->服务的分组/隔离/路由/------>服务治理

消息队列原则

消息队列用来解耦一些不需要同步调用的服务或者订阅一些自己系统关关系的变化。

使用消息队列可以实现服务解耦(一对一消费，一对多消费)，异步处理，流量削峰/缓冲等

比如：电商系统中的交易数据，有非常多的系统关系并订阅该数据。

比如：订单生产系统

缓存原则

本地缓存：内存缓存，属于进程的缓存。

本地分布式缓存：内存缓存，多进程共享，但是通过内网进行访问的缓存。

分布式缓存：外部内存缓存，多进程共享，但是通过外网进行访问的缓存。

异步并发化原则

假设一个读服务需要如下数据，数据A，数据B，数据C,数据D，数据E 时间分别为10ms,15ms,10ms,20ms,5ms,

如果串行读取，需要花费60ms,

如果数据C依赖A,B,数据D谁 也不依赖，数据E依赖数据C，那么就可以直接并发读取A,B,D ,AB被C读取，然后再读取E，总读取时间为30ms,性能优化了一倍。

如何设计秒杀高并发系统

前提是我们必须要知道目前我们的系统是2000万秒杀20万手机。真正的并发量是多少。

计算2000万的并发量

每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。 其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。

一天时间

如果我们要求2000万人在1天内抢完20万个手机。

平均值：20000000 / 86400 = 232/s

峰值：20000000 * 80% / 86400 * 40 = 232/s

16000000/34560 = 463/s

一个小时

计算每秒服务器每秒需要处理的数量

平均值：20000000 / 16060 =5556/s (QPS)

峰值：16000000/1440 = 13889/s(QPS)

峰值：16000000/720 = 27778/s(QPS)

总结

好像看起来是一条水平线，可是用户不听我们的呀，我们必须得算出一个峰值呀，

这样才能够算是真实的，目前有一个

假如目前aspnetcore项目每秒能够处理500个并发

大家可以估算一下，需要多少台机器

答案：56台服务器。

可是这只是我们的一个估算，我们该如何知道真实的呢？

两个前提，

1、电商系统

2、秒杀系统

那么，我们如何设计这些系统呢？

电商系统设计

用户模块

商品模块

支付模块

订单模块

秒杀系统设计

秒杀模块

时间模块

高并发秒杀系统相关技术

相关技术：微服务,webapi aspnetcore，restful ,缓存，消息队列，限流，nginx,docker k8s,服务治理,IdentityServer4 mysql linux 自己研发小框架。

相关工具：jmeter