分享 小米抢购页面分析

yakczh · October 17, 2013 · Last by jeff_duan replied at October 19, 2013 · 4597 hits

只是第一次点击购买的时候不会通过 ajax post 去后台取数据,直接就弹出排队层,以后倒计时后的每次点击进入是有 ajax 请求的,也就是说其实抢购的时候到页面上构造请求就不需要等 8 秒,会比较容易抢吧。。。当然前提是后台返回的数据是真实的后台数据。

网易新闻属于标题党,是为了炒作。

小米用随机随机抽奖的方式,这种方式作者不认同,那么到底应该怎么做?如果你是小米,你会怎么做?

我勒个去。。。伤心了。。。

为什么你一定要买呢?

他们为什么不采用美团抽奖那种事先分号,再按某一天股票指数来抽奖的方式,也省的大家同时去抢了

我认为这并不是什么阴谋论,而是一个比较好的一个防止服务器奔溃的一个架构策略。

1)在假定大部分用户非前端工程师,无刨根问底的精神的情况下,只有极少数用户有可能获取真正的抢购 ajax request 并制作成脚本,可想而知该 request 估计也会通过 referrer 来进行访问保护以增加自动化难度。

2)在假设的范围内,最简单的做法是延缓随机时间,如果服务器同时最多能有 1000 个连接,每个连接要耗时 100ms,有 10w 人抢,那么最佳情况是分配 10 秒的队列时间,从而每个人都有机会在这 10 秒内得到 service。 如果不加以限流,更多的人得到的是 service not available,并且服务器和数据库可能会因为 cpu 100% 而导致性能极度恶化。

如果考虑到用户看到抢购失败会不停重试,情况将更加糟糕。

3)最佳的做法则是根据服务的容量自动设置 backoff 时间,请参加 wikipedia 这篇文章 http://en.wikipedia.org/wiki/Exponential_backoff 使用这个算法既可以获得最大的 throughout。 这个算法如果实施在服务端也可以避免一定的 DDOS 攻击,至少服务器不会崩溃。

4)通过 javascript 弹框延时的方式,所有的抢购代码都可以部署在 CDN 上,再多人也不怕进不到抢购页面。 通过 backoff strategy,用户不会看到 service not available 等页面,就算退一步连 ajax post 都获取服务失败,页面上的 javascript 还是可以给用户弹个窗说抢购失败(其实是服务器忙死了)。 从而保证了比较良好的用户体验,至少没死机不是么?

所以总体而言,通过这种方案,估计有个几台应用服务器就能轻松应对足够多的用户抢购了。

You need to Sign in before reply, if you don't have an account, please Sign up first.