只是第一次点击购买的时候不会通过 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 还是可以给用户弹个窗说抢购失败（其实是服务器忙死了）。 从而保证了比较良好的用户体验，至少没死机不是么？
所以总体而言，通过这种方案，估计有个几台应用服务器就能轻松应对足够多的用户抢购了。