技术挑战:

1.  对现有网站业务造成冲击。

        秒杀活动是一种营销手段，活动时间短，并发访问量大，如果和网站原有的应用部署在一起，必然会对现有业务造成冲击，还有可能导致整个网站的瘫痪。

2.  高并发下的应用和数据库负载

        秒杀活动开始前，用户会通过浏览器不停的刷新以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器，连接数据库服务器，会对应用和数据库造成极大的负载压力。

3.  突破增加的网络及服务器带宽

        假设商品页面大小200k，网站的带宽就是并发数乘以200k，这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。

4.  直接下单

        秒杀的规则是秒杀时间到了才能开始对商品进行下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的 URL，如果得到这个 URL，不用等到秒杀开始就可以下单了。

应对策略:

1.   秒杀系统独立部署

        为了避免因为秒杀活动并发访问而拖垮整个网站，使整个网站不必面对蜂拥而至的大量用户访问，可以将秒杀系统独立部署，独立的负载均衡，WEB服务器，应用服务器，数据库服务器等。甚至可以使用独立的域名，使其与其他网站完全隔离，即使秒杀系统崩溃，也不会对其他网站造成任何影响。

  2.   秒杀商品页面静态化

        重新设计秒杀商品页面，不要使用网购平台原来的商品详情页面，页面整体内容全部静态化，将商品描述，商品参数，成交记录和用户评价等全部写入一个静态页面，这个页面需要通过后台管理功能提前自动生成，还需要将运营人员维护的秒杀价格自动写入这个静态页面，并将秒杀商品数量写入缓存服务器。

        整个秒杀详情页全部静态化后，用户请求就不需要进入应用服务器并进行业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态WEB服务器和数据库服务器来解决商品详情页需求。

   3.   租借秒杀活动网络带宽  

        因为秒杀新增的网络带宽，必须和运营商重新购买或租借。为了减轻网站源站入口的带宽压力和服务器压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新的出口带宽。

4.   动态生成随机下单页面URL

        为了避免用户直接访问下单页面URL，需要将该URL动态化，即使秒杀系统的开发人员也无法在秒杀开始之前访问到下单页面的URL，办法是在下单页面的URL中加入由服务端生成的随机数作为参数，在秒杀开始前才可以得到。

架构设计:

      秒杀抢购系统的参与用户关心的是快速的刷新页面信息，在秒杀开始时抢先进入下单页面，对商品详情的关注度较低，因此秒杀系统的页面设计应该尽量简单简洁。

      商品页面的购买按钮只有在秒杀活动开始时才可以变亮，并可以点击，在此之前或秒杀商品销售光之后，该按钮都应该是灰色的，且不可点击。

     订单确认页面也应该简洁，抢购数量默认值（可修改为系统设定的最大值），送货地址默认值（可修改），只有系统限定数量的订单会发送给网站的订单子系统，其余用户提交订单后只能看到描述结束页面（商品已抢购结束）。

1.  如何控制秒杀商品页面购买按钮的点亮

购买按钮只有在秒杀活动开始的时候才点亮，之前是灰色不可点击状态。如果该页面设计为是后端服务器查询数据库动态生成，并构造响应页面输出，当然是可以的。但为了减轻后端服务器负载压力，更好的利用CDN、反向代理等性能优化手段，该页面需要设计为静态页面，缓存在CDN、反向代理服务器上，甚至是用户浏览器上。秒杀开始之前，用户刷新页面，请求根本不会达到后端应用服务器。

        解决方案：  使用js脚本控制，在秒杀商品静态页面中加入一个js文件的引用，在该js文件中加入秒杀是否开始的标记和下单页面URL的随机数参数，当秒杀开始的时候，生成一个新的js文件并被用户浏览器加载，控制秒杀商品页面的展示。这个js文件使用随机版本号，这种情况下就不会被浏览器，CDN和反向代理服务器缓存。

这个 js文件非常小，即使每次刷新浏览器都会重新下载这个js文件，也不会对js服务器集群和网络带来太大的压力。

2.  如何控制只允许制定数量的订单才可以被发送到订单子系统（防止超卖）

由于需要限制最终成功抢购或秒杀的商品是系统设定的限量数，因此在用户提交订单时，需要检查已经提交成功的订单数，为了减轻下单页面服务器的负载夜里，可以控制下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。