就是参考业务介绍概念秒杀什么是秒杀？(组图)

前言

最近，部门一直在讨论电子商务业务秒杀活动的总体思路。大家对这个讨论的反馈还不错，所以我简单整理了一下，分享给大家参考

业务介绍

概念

秒杀

什么是尖峰？通俗的讲，就是网上商家为了促销等目的而组织的网上购物活动。

比如京东的秒杀就是定时定量的秒杀。在规定时间内，无论产品的秒杀是否完成，该会话的秒杀活动都会结束。这种秒杀对时间的要求不是特别严格。只要起步快，几秒命中的概率还是比较大的。

淘宝之前做过一元抢购，一般限1件，价格“吓人”。这种秒杀通常在开始时间的1到3秒内售罄。参与本次秒杀一般是运气问题，不要太勉强

业务特点

大量瞬时并发

秒杀期间，大量用户同时抢购，瞬间并发访问量猛增10倍，甚至100倍以上。

库存不足

一般秒杀活动中的产品很少，导致只有极少数用户能够成功购买到产品。

简单的业务

流程比较简单，一般下单电商系统 高并发库存系统设计，扣库存，下单付款

技术难题

现有业务的影响

秒杀是一种营销活动。如果和其他营销活动应用部署在同一台服务器上，肯定会对现有的其他活动产生影响。极端情况下，可能会导致整个电商系统服务宕机。

直接下单

订购页面是一个普通的URL地址。需要在秒杀开始前进行控制。无法下单，只能浏览对应的活跃商品信息。简而言之，禁用订单按钮是必需的

页面流量突然增加

秒杀事件前后，会有很多用户请求对应的商品页面，这会导致后台服务器的流量突然增加，同时对应的网络带宽也会增加。造成压力过大

建筑设计理念

电流限制

因为秒杀活动的库存一般很少，只有少数用户可以成功秒杀。因此可以限制大部分用户流量，只允许少量用户流量进入后端服务器

削峰

秒杀开始的那一刻，会有大量的用户进来，所以一开始会有一个瞬间的流量高峰。如何让瞬时流量峰值更加平缓是秒杀系统设计成功的关键因素。实现流量高峰和低谷，一般使用缓存和MQ中间件来解决问题

异步

Seckill 实际上可以作为一个高并发系统来处理。这时候可以考虑做业务兼容，把同步业务设计成异步处理任务，提高网站的整体可用性

缓存

秒杀系统的瓶颈主要体现在下单和扣货的过程中。在这些流程中，主要使用OLTP数据库，如MySQL、SQLServer、Oracle等。由于数据库底层采用B+树的存储结构，随机读写效率比较低。如果我们把一些业务逻辑迁移到内存缓存或者Redis上，会大大提高并发效率

整体架构

客户端优化

客户端优化有两个主要问题

秒杀页面

在 Lightning Deal 开始之前，许多用户实际上访问了该页面。如果这个页面的一些资源，如CSS、JS、图片、产品详情等，访问后端服务器，甚至是DB，服务肯定会不可用。所以一般情况下，我们会将整个页面静态化，将页面静态化后的页面分发到CDN边缘节点，起到分散压力的作用

阻止下单

主要通过在静态页面添加JS文件引用来防止下单。 js文件开头包含activity是否启动的标志和动态订单页面的url参数。同时这个JS文件不会被CDN系统缓存，会一直请求后端服务，所以这个JS文件一定要小。在activity即将启动时（如提前），通过后台界面修改js文件使其生效

API 访问层优化

对于不从事计算机方面的用户，可以防止客户端优化。但是有一定网络基础的用户是不行的，所以服务端也需要添加一些相应的控件，不能信任客户端的任何操作。一般控制分为2类

限制用户维度访问频率

对于同一个用户（Userid维度），做页面级缓存，单位时间请求，统一走缓存，返回同一个页面

限制产品维度的访问频率

当同一时间有大量请求查询同一个产品时，可以做页面级缓存。不管谁下次访问，只要是这个页面，都会直接返回

SOA服务层优化总结

上两层只能限制异常用户的访问。如果秒杀活动运行良好，并且有很多用户参与，会造成系统压力过大甚至宕机，需要后端流量控制

后端系统的控制可以通过消息队列、异步处理、提高并发等方式来解决。对于超过系统水位的请求，直接采用“Fail-Fast”原则电商系统 高并发库存系统设计，拒绝

秒杀整体流程图

秒杀系统的核心在于逐层过滤，逐步降低瞬时访问压力，减少最终对数据库的影响。通过上面的流程图，你会发现压力最大的地方在哪里？

MQ排队服务，只要MQ排队服务能承受，下单、扣库存的压力都可以自己控制。根据数据库的压力，可以自定义订单消费者的数量，避免消费者数据的出现。卷太大会导致数据库压力过大或直接停机。

库存服务提供秒杀产品的库存管理，可以提前锁定库存，避免超卖。同时，通过超时处理任务，发现已经抢到货了，但是订单还没有付款，等到指定的付款时间后，这些订单就会被处理，以及下单商品对应的库存会恢复的

总结

核心思想：逐层过滤

尽量拦截上游的请求，减轻下游压力

充分利用缓存和消息队列，提高请求处理速度和削峰填谷的作用