1.如何设计一个高性能的秒杀系统？

1.设计需求：

首先，建立一个秒杀系统，所需要的是将商品以及要售出的资源整合起来，集中供给，也就是说我们要将要售卖的商品管理起来，从而进行售出；

功能要点：

• 资源类整合统一（不能出现多卖或者少卖的情况）

• 关乎数据安全，（保证每个订单都能在高并发的时间下可以完成库存的减少-及时更新库存）；

• 高可用-（必须要能抗住大的数据流量，保证在 QPS 达到百万，我瞎说的）

• 高性能（在保证高可用的前提下，性能也要好，用户体验，及时的响应时间等）；

综合上述，就是好用，数据流程安全统一，完美；

2.项目背景：

本公司要做做电商平台的，因为之前是比较幸运做商品的管理，为了答谢广大的用户，平台推出秒杀活动，比如 5 折秒杀 MacBook pro 16 存（估计老板的心在滴血），老罗的直播间估计也经常搞这种，由于上半年的疫情原因，导致很多物品积压，美斯特邦威关闭很多实体门店，阿迪达斯五折甩卖，等等，线上直播带货，薇娅直播一姐，全明星进入带货的时代，8 小时带货 3 个亿的成交额，刘涛入职阿里成就为'刘一刀'，趋势所致，人心所向，秒杀系统民心所向，然而作为小白鼠的我就当为项目试试水了；

3.可行性方案：

由于有了公司的支持，我们开始了艰难的技术选型的会议讨论中，

3.1 技术选型

首先毋庸置疑的，

• 为了系统的维护性，

我们选取的是微服务（springboot+dubbo 服务治理+zookerper 注册中心），

• 为了性能，我们需要缓存 Redis 来确保数据

• 为了高可用，（防止数据库宕机，我们计划采用 MQ,异步削峰）

虽然说技术选型已经有了计划，但是具体的业务分析和总体功能的设计还是比较难得，作为小白鼠实验的我，没有产品的经验，只能是通过一个用户最直观的设计来完成基础的功能，嗯嗯，卢卡要当一回产品经理了；

3.2 秒杀系统产品设计

在日益完成的带货节，双十一，光棍节等节日成为全民在家，秒杀自己喜欢物品的时间，同时呢也会有很多的优惠券和折扣的发放，用商家的话来说，一年只有一次，’买到就是赚到‘，殊不知为了这些个活动，这些活动背后的程序工作者又要掉多少头发了，唉顿时，感慨万千，没办法毕竟是国之栋梁啊，继续说，因为秒杀的经验是从淘宝的双十一，疯狂点手机来的，所以我们来了解一下，关于淘宝双十一的秒杀的具体布局；

2009 年 双十一当天销售额 0.52 亿，27 家品牌参与; 2010 年 双十一当天销售额 9.36 亿，711 家品牌参与； 2011 年 双十一当天销售额 33.6 亿，2200 家品牌参与； 2012 年 双十一当天销售额 132 亿，10000 家品牌参与； 2013 年 双十一当天销售额 352 亿，20000 家品牌参与； 2014 年 双十一当天销售额 571 亿，27000 家品牌参与； 2015 年 双十一当天销售额 912 亿，40000 家品牌参与； 2016 年 双十一当天销售额 1207 亿，98000 家品牌参与； 2017 年 双十一当天销售额 1682 亿，140000 家品牌参与； 2018 年 双十一当天销售额 2135 亿，180000 家品牌参与； 2019 年 双十一当天销售额 2684 亿 200000 家品牌参与

上述是淘宝的交易额，每秒的并发，但是是成交的笔数，还不是访问量和点击量以及购买量；

3.3 总体设计

1.秒杀，按钮得显眼，商品要保证在库存卖空（准备只卖 1000 件，我们就将按钮变为不能点击状态）变为灰色；

2.界面尽可能简单，因为我们需要的是商品的秒杀，用户之前肯定就已经了解过产品了，

3.具体的功能要实现；

买单-->支付->锁库存->减库存->增销量,完成下单；

当然一般的支付完成之后，还有拆订单，去哪个地方的仓库调货，这也需要物流的系统去监控，这个我们就先不考虑了，我们只关心秒杀的具体实现；

因为商品在网络中售卖会遇见，网络抖动啊，数据流量洪峰啊，有可能会有攻击等常见的问题，所以我们要做好数据安全，缓存更新的准备；

下面我们就来详细设计我们得秒杀系统了；

3.4 秒杀系统的详细设计：

这个系统说明是参照敖丙的秒杀系统写的文章，原文链接在下方

 https://mp.weixin.qq.com/s/KWb3POodisbOEsQVblsoGw

订单在创建过程中---》请求库存>0,如果成功就直接生成订单数据；

•  上述从用于请求开始 Nginx 是第一步，负载均衡，保证每次请求竟可能分流，（其中有哈希，轮询，权重等算法，用于特定的 ip 地址区分从而用不同的服务器去响应，处理请求）；

•  风控这块我不是特别了解，先埋下坑；

•  开始进行主服务的访问，但是这里如果是要访问具体的数据，redis 的集群环境下由从服务来响应，如果是要下单改库存的操作，这里就得访问 Redis 的主服务操作了；（读写分离，集群环境）

•  下单操作调用支付接口，这里使用 MQ 来异步削峰（有人肯定会问，为啥要用 MQ，因为面试官也会问），首先是因为下单的这个操作是要保证数据安全的，必须要有顺序，也就是先到先得的一个操作， MQ 为了保证数据的异步发起消息队列，然后监听到具体的服务下单的要求，开始跳转到支付接口去请求支付服务，为了保证支付接口幂等性（ 一个用户对于同一个操作发起一次或多次的请求，请求的结果一致，不会因为多次点击而产生多条数据），这里保证幂等性，分布式事务结果统一等问题都是要考虑的，也及时多次提交一个订单，只会处理一笔

•  因为使用 MQ，会直接返回响应结果，不用用户等待，(异步),然后双写操作，放到数据库中，然后刷新缓存等操作； 这是大多数的秒杀操作的标准解决方式，淘宝的解决方式肯定比这个高级的多，但是思路都是这样的，只不过他们会技术上采用中间件，比如数据库中间件 sharding Sphere ,创建数据的时候直接放在业务型的数据库中，比如按照轮询依次放在 order_nums 表中,（数据创建的时候会确定一个条件，符合条件会放入对应的数据库中）， 然后我们具体开始拆分细节 3.5 秒杀系统的设计要点

限流，

请求的分流：

前端请求--资源静态化-->

• 末尾

愿你们都可以在技术的海洋里，乘风破浪，我是卢卡，我们下期再见哦^_^

要是有比较想看的技术文章和想了解技术栈，可以私信我品味技术人生，都在摸爬滚打中慢慢变强！！！