秒杀系统注意的问题
1) 对现有网站业务的冲击
因为秒杀活动只是网站营销的一个附加活动,这个活动具有时间短,并发访问量大的特点,如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪。
2) 高并发情况以及数据库的负载
用户在秒杀开始前,通过不停的刷新浏览器页面以保证不会错过秒杀,这些请求如果按照一般的网站应用架构,访问应用服务器、连接数据库,会对应用服务器、数据库服务器造成极大的负载压力。
3) 突然增加的网络和服务器带宽
假设商品页面大小200K(主要是商品图片大小),那么需要的网络和服务器带宽是2G(200K×10,000),这些网络带宽是因为秒杀活动新增的,超过网站平时使用的带宽。
4) 直接下单
秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买,在此时间点之前,只能浏览商品信息,不能下单。而下单页面也是一个普通的URL,如果得到这个URL,不用等到秒杀开始就可以下单了。
5) 防止机器秒杀
防止网上的一些“秒杀器”
针对上面的5个问题,对应的策略如下:
1) 秒杀系统独立部署
为了避免因为秒杀活动的高并发访问而拖垮整个网站,使整个网站不必面对蜂拥而来的用户访问,将秒杀系统独立部署,如果需要,还可以使用独立的域名,以和网站完全隔离,即使秒杀系统崩溃了,也不会对网站造成任何影响。
2) 秒杀商品页面静态化
秒杀商品页面重新设计,不使用网站原来的商品详情页面,页面内容静态化:商品描述,商品参数,成交记录,用户评价全部写入一个静态页面,用户请求不需要经过应用服务器的业务逻辑处理,也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器、数据库服务器。
3) 租借秒杀活动网络带宽
对于因为秒杀新增的网络带宽,必须和运营商重新购买或者租借。为了减轻网站服务器的压力,需要将秒杀商品页面缓存在CDN,同样需要和CDN服务商临时租借新增的出口带宽。
4) 动态生成随机下单页面URL
为了避免用户直接访问下单页面URL,需要将该URL动态化,即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数,在秒杀开始的时候才能得到。
思路:
2、秒杀时使用decr或decrBy命令对商品数量减一。如果不是负数说明抢到。(比如key: 秒杀id_商品id)
3、一旦返回数值是负数说明商品已售完。
1、确定一个秒杀开始时间和结束时间,并把它放在redis里面。
2、使用活动开始时间-当前时间可以计算出当前秒杀是否正在进行以及倒计时。
1、使用活动开始时间-当前时间可以计算出一个秒为单位的数值。
2、在redis中设置一个key(活动开始标识)。设置key的过期时间为第三步计算出来的时间。
3、展示页面的时候取出key的有效时间。Ttl命令(比如key: 秒杀id。expire key)。使用js倒计时。
4、一旦活动开始的key失效,说明活动开始。
5、需要在活动的逻辑中,先判断活动是否开始。