php秒杀业务分析

假期整理

**

秒杀业务分析

**

• 正常电子商务流程
• （1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货
  秒杀业务的特性
  （1）低廉价格；（2）大幅推广；（3）瞬时售空；（4）一般是定时上架；（5）时间短、瞬时并发量高；

2 秒杀技术挑战

• 假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就说最大并发请求数是10000，秒杀系统需要面对的技术挑战有：
  1. 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。
  2. 解决方案：将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离。
  3. 高并发下的应用、数据库负载
  4. 用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。
  5. 解决方案：重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容静态化，用户请求不需要经过应用服务。
  6. 突然增加的网络及服务器带宽
  7. 假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。
  8. 解决方案：因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。
  9. 直接下单
  10. 秒杀的游戏规则是到了秒杀才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。
  11. 解决方案：为了避免用户直接访问下单页面URL，需要将改URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。
  12. 如何控制秒杀商品页面购买按钮的点亮
  13. 购买按钮只有在秒杀开始的时候才能点亮，在此之前是灰色的。如果该页面是动态生成的，当然可以在服务器端构造响应页面输出，控制该按钮是灰色还
      是点亮，但是为了减轻服务器端负载压力，更好地利用CDN、反向代理等性能优化手段，该页面被设计为静态页面，缓存在CDN、反向代理服务器上，甚至用户浏览器上。秒杀开始时，用户刷新页面，请求根本不会到达应用服务器。
  14. 解决方案：使用JavaScript脚本控制，在秒杀商品静态页面中加入一个JavaScript文件引用，该JavaScript文件中包含
      秒杀开始标志为否；当秒杀开始的时候生成一个新的JavaScript文件（文件名保持不变，只是内容不一样），更新秒杀开始标志为是，加入下单页面的URL及随机数参数（这个随机数只会产生一个，即所有人看到的URL都是同一个，服务器端可以用redis这种分布式缓存服务器来保存随机数），并被用户浏览器加载，控制秒杀商品页面的展示。这个JavaScript文件的加载可以加上随机版本号（例如xx.js?v=32353823），这样就不会被浏览器、CDN和反向代理服务器缓存。
  15. 这个JavaScript文件非常小，即使每次浏览器刷新都访问JavaScript文件服务器也不会对服务器集群和网络带宽造成太大压力。
  16. 如何只允许第一个提交的订单被发送到订单子系统
  17. 由于最终能够成功秒杀到商品的用户只有一个，因此需要在用户提交订单时，检查是否已经有订单提交。如果已经有订单提交成功，则需要更新 JavaScript文件，更新秒杀开始标志为否，购买按钮变灰。事实上，由于最终能够成功提交订单的用户只有一个，为了减轻下单页面服务器的负载压力，
      可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。
  18. 解决方案：假设下单服务器集群有10台服务器，每台服务器只接受最多10个下单请求。在还没有人提交订单成功之前，如果一台服务器已经有十单了，而有的一单都没处理，可能出现的用户体验不佳的场景是用户第一次点击购买按钮进入已结束页面，再刷新一下页面，有可能被一单都没有处理的服务器处理，进入了填写订单的页面，可以考虑通过cookie的方式来应对，符合一致性原则。当然可以采用最少连接的负载均衡算法，出现上述情况的概率大大降低。
  19. 如何进行下单前置检查
  20. · 下单服务器检查本机已处理的下单请求数目： 如果超过10条，直接返回已结束页面给用户； 如果未超过10条，则用户可进入填写订单及确认页面； · 检查全局已提交订单数目： 已超过秒杀商品总数，返回已结束页面给用户；
      未超过秒杀商品总数，提交到子订单系统；
  21. 秒杀一般是定时上架
  22. 该功能实现方式很多。不过目前比较好的方式是：提前设定好商品的上架时间，用户可以在前台看到该商品，但是无法点击“立即购买”的按钮。但是需要考虑的是，有人可以绕过前端的限制，直接通过URL的方式发起购买，这就需要在前台商品页面，以及bug页面到后端的数据库，都要进行时钟同步。越在后端控制，安全性越高。
  23. 定时秒杀的话，就要避免卖家在秒杀前对商品做编辑带来的不可预期的影响。这种特殊的变更需要多方面评估。一般禁止编辑，如需变更，可以走数据订正多的流程。
  24. 减库存的操作
  25. 有两种选择，一种是拍下减库存 另外一种是付款减库存；目前采用的“拍下减库存”的方式，拍下就是一瞬间的事，对用户体验会好些。
  26. 库存会带来“超卖”的问题：售出数量多于库存数量
  27. 由于库存并发更新的问题，导致在实际库存已经不足的情况下，库存依然在减，导致卖家的商品卖得件数超过秒杀的预期。方案：采用乐观锁

update auction_auctions set

quantity = #inQuantity#

where auction_id = #itemId# and quantity = #dbQuantity#

还有一种方式，会更好些，叫做尝试扣减库存，扣减库存成功才会进行下单逻辑：

update auction_auctions set

quantity = quantity-#count#

where auction_id = #itemId# and quantity >= #count#

秒杀器的应对

秒杀器一般下单个购买及其迅速，根据购买记录可以甄别出一部分。可以通过校验码达到一定的方法，这就要求校验码足够安全，不被破解，采用的方式有：秒杀专用验证码，电视公布验证码，秒杀答题。

3 秒杀架构原则

尽量将请求拦截在系统上游

传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】。

读多写少的常用多使用缓存

这是一个典型的读多写少的应用场景【一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%】，非常适合使用缓存。

4 秒杀架构设计
秒杀系统为秒杀而设计，不同于一般的网购行为，参与秒杀活动的用户更关心的是如何能快速刷新商品页面，在秒杀开始的时候抢先进入下单页面，而不是商品详情等用户体验细节，因此秒杀系统的页面设计应尽可能简单。
商品页面中的购买按钮只有在秒杀活动开始的时候才变亮，在此之前及秒杀商品卖出后，该按钮都是灰色的，不可以点击。
下单表单也尽可能简单，购买数量只能是一个且不可以修改，送货地址和付款方式都使用用户默认设置，没有默认也可以不填，允许等订单提交后修改；只有第一个提交的订单发送给网站的订单子系统，其余用户提交订单后只能看到秒杀结束页面。
要做一个这样的秒杀系统，业务会分为两个阶段，第一个阶段是秒杀开始前某个时间到秒杀开始， 这个阶段可以称之为准备阶段，用户在准备阶段等待秒杀；第二个阶段就是秒杀开始到所有参与秒杀的用户获得秒杀结果， 这个就称为秒杀阶段吧。
4.1 前端层设计
首先要有一个展示秒杀商品的页面， 在这个页面上做一个秒杀活动开始的倒计时， 在准备阶段内用户会陆续打开这个秒杀的页面， 并且可能不停的刷新页面。这里需要考虑两个问题：

第一个是秒杀页面的展示

我们知道一个html页面还是比较大的，即使做了压缩，http头和内容的大小也可能高达数十K，加上其他的css， js，图片等资源，如果同时有几千万人参与一个商品的抢购，一般机房带宽也就只有1G_{10G，网络带宽就极有可能成为瓶颈，所以这个页面上各类静态资源首先应分开存放，然后放到cdn节点上分散压力，由于CDN节点遍布全国各地，能缓冲掉绝大部分的压力，而且还比机房带宽便宜}

第二个是倒计时

出于性能原因这个一般由js调用客户端本地时间，就有可能出现客户端时钟与服务器时钟不一致，另外服务器之间也是有可能出现时钟不一致。客户端与服务器时钟不一致可以采用客户端定时和服务器同步时间，这里考虑一下性能问题，用于同步时间的接口由于不涉及到后端逻辑，只需要将当前web服务器的时间发送给客户端就可以了，因此速度很快，就我以前测试的结果来看，一台标准的web服务器2W+QPS不会有问题，如果100W人同时刷，100W QPS也只需要50台web，一台硬件LB就可以了~，并且web服务器群是可以很容易的横向扩展的(LB+DNS轮询)，这个接口可以只返回一小段json格式的数据，而且可以优化一下减少不必要cookie和其他http头的信息，所以数据量不会很大，一般来说网络不会成为瓶颈，即使成为瓶颈也可以考虑多机房专线连通，加智能DNS的解决方案；web服务器之间时间不同步可以采用统一时间服务器的方式，比如每隔1分钟所有参与秒杀活动的web服务器就与时间服务器做一次时间同步。

浏览器层请求拦截

（1）产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求;

（2）JS层面，限制用户在x秒之内只能提交一次请求;

4.2 站点层设计
前端层的请求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
（1）同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
（2）同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面
如此限流，又有99%的流量会被拦截在站点层。
4.3 服务层设计
站点层的请求拦截，只能拦住普通程序员，高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎么整？
（1）大哥，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透过有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”；
（2）对于读请求，还用说么？cache来抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的；
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。

用户请求分发模块：使用Nginx或Apache将用户的请求分发到不同的机器上。

用户请求预处理模块：判断商品是不是还有剩余来决定是不是要处理该请求。

用户请求处理模块：把通过预处理的请求封装成事务提交给数据库，并返回是否成功。

数据库接口模块：该模块是数据库的唯一接口，负责与数据库交互，提供RPC接口供查询是否秒杀结束、剩余数量等信息。

·
· 随着互联网普及率的不断提高，中国电商稳步发展。iiMedia Research(艾媒咨询)数据显示，2019年上半年，中国的网络零售总额已达到195209.7亿元，占社会零售总额的24.7%，截至2019年，中国移动电商用户规模将突破7亿人。
· 　移动终端和支付技术的进步助推电商在网民中的渗透率提升，电商体系在中国已发展成熟，用户规模逐渐触达网民规模天花板。随着电商的稳步发展，各大电商平台都不遗余力的开拓新的营销模式来增加消费者的欲望，2019年最流行的消费模式是直播带货和社团团购。
· 2019上半年中国电商行业热点——直播成新带货方式
· 　直播电商：直播带货成为新的生活方式
· 　　直播带货是从用户的角度介绍商品功能和使用效果直接刺激消费者的购买欲望。iiMedia Research(艾媒咨询)数据显示，88.5%的受访直播电商用户表示直播的方式能够强烈的刺激他们的消费欲望，约三成直播电商受访用户称每周会观看直播四到六次，直播俨然已经成为一种新的带货方式，渗透消费者的日常生活。
· 　2019上半年中国电商行业热点——社区拼团发展迅速
· 　社区拼团：用户参与度高
· 　　社团团购主打价格优势，通过团购方式增加用户参与度和联系度打破地理的限制。iiMedia Research(艾媒咨询)数据显示，有社区拼团经历的用户，会比较频繁地参与社区拼团。超六成的受访用户每周都会参与社区拼团。其中，27.6%的受访用户每周会参与一到三次。超四成的用户称，优惠的价格是他们参与拼团最关注的因素，超过一半的用户表示对社区团购带来的优惠是比较满意的。
· 　中国电商行业发展趋势分析
· 　1、新零售时代流量获取话题突出 平台多样模式创新争取用户
· 　　艾媒咨询分析师认为，电商行业进入新零售时代以来，关于用户流量获取的问题越来越受到各大平台关注。线上平台获客成本持续居高，以及发展线下带来的转型成本都成为各平台发展面对的考验。面对流量获取的问题，电商平台开始探索更多新型电商模式，如社交电商、直播电商等创新模式涌现，电商平台对于流量的争夺将趋于白热化。
· 　2、电商体系加速成熟 行业发展将更显规范化
· 　　中国消费者生活水平日渐提高、电商普及程度不断加强、国家政策鼓励电子商务业务的开展，多方因素推动着电商体系发展更加成熟。艾媒咨询分析师认为，中国电商行业已进入成熟发展阶段，电商在中国零售行业的位置愈加重要。但与此同时，行业仍然存在诸多乱象，《电商法》的出台是政府重视行业规范发展的信号，未来相关监管措施仍会进一步加强。
· 　3、消费者电商购物更注重品质 平台背书影响力扩大
· 　　电商供应链环节的日益完善，使消费者多样化的消费需求得到满足，用户对于电商购物的关注也从商品丰富度、性价比，逐渐往商品质量保障方面转移。艾媒咨询分析师认为，在消费升级的背景下，质量保障成为各大平台争取用户的关键。而随着电商行业发展逐渐往头部靠拢，未来平台背书的作用将更加明显，口碑建设的重要性愈加突出。
· 4、电商平台加强社交化布局 组团拼购模式发展速度提升
· 　　现阶段各大电商平台开始注重产品社交化布局，如纷纷进入拼购、社区拼团等细分赛道，平台在社交化领域的竞争开始受到关注。艾媒咨询分析师认为，电商社交化运营模式是降低平台获客成本的有效手段，并且能有助于商家解决销路问题，整体发展迅速，未来入局到社交化运营的电商平台将继续增加。
· 　5、商平台加码内容营销 视频成新阶段获客重要载体
· 　　艾媒咨询分析师认为，在获客成本不断攀升的情况下，电商平台对于内容营销的重视程度不断提高。而消费者信息获取趋向于碎片化，电商平台内容营销的模式也能有效切中用户需求。未来5G应用更加深化后，以视频为载体的内容营销模式将是平台获客的重要手段，能够从展现形式、增强消费者信息等角度更好帮助产品销售。
· 　6、基础设施完善助力电商平台渗透加强 下沉城市争夺将更趋激烈
· 　　艾媒咨询分析师认为，中国电商发展的基础环境正不断完善，如物流配送覆盖的地域、购物支付的便利性等，逐渐完善的基础设施也有助于电商平台对更多地区和人群的渗透加强。未来随着一二线城市用户消费逐渐饱和，下沉市场将成为电商平台新的发展重点。