即所有人看到的URL都是同一个，服务器端可以用redis这种分布式缓存服务器来保存随机数），并被用户浏览器加载，控制秒杀商品页面的展示。
这个JavaScript文件的加载可以加上随机版本号（例如xx.js?v=32353823），这样就不会被浏览器、CDN和反向代理服务器缓存。
6、如何只允许第一个提交的订单被发送到订单子系统
1）问题描述
1. 由于最终能够成功秒杀到商品的用户只有一个，因此需要在用户提交订单时，检查是否已经有订单提交。
2. 如果已经有订单提交成功，则需要更新 JavaScript文件，更新秒杀开始标志为否，购买按钮变灰。
3. 事实上，由于最终能够成功提交订单的用户只有一个，为了减轻下单页面服务器的负载压力，
可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。
2）解决方案
1. 假设下单服务器集群有10台服务器，每台服务器只接受最多10个下单请求。
2. 在还没有人提交订单成功之前，如果一台服务器已经有十单了，而有的一单都没处理，
可能出现的用户体验不佳的场景是用户第一次点击购买按钮进入已结束页面，再刷新一下页面，
有可能被一单都没有处理的服务器处理，进入了填写订单的页面，可以考虑通过cookie的方式来应对，符合一致性原则。
当然可以采用最少连接的负载均衡算法，出现上述情况的概率大大降低。
7、如何进行下单前置检查
1）下单服务器检查本机已处理的下单请求数目
1. 如果超过10条，直接返回已结束页面给用户；
2. 如果未超过10条，则用户可进入填写订单及确认页面；
2）检查全局已提交订单数目
1. 已超过秒杀商品总数，返回已结束页面给用户；
2. 未超过秒杀商品总数，提交到子订单系统；
PS：
1. 由于秒杀商品数量通常极少，可以直接在集群的每台下单服务器上都设置一个最大下单数来限制本服务器上提交的请求数
2. 超过该高数目后，其他请求直接跳转至秒杀活动结束页面。这样可以在在全局判断之前在每台服务器上完成初步过滤。
8、秒杀一般是定时上架
1. 提前设定好商品的上架时间，用户可以在前台看到该商品，但是无法点击“立即购买”的按钮。
2. 但是需要考虑的是，有人可以绕过前端的限制，直接通过URL的方式发起购买，这就需要在前台商品页面，以及bug页面到后端的数据库，都要进行时钟同步。
9、减库存的操作
1. 有两种选择，一种是拍下减库存 另外一种是付款减库存；目前采用的“拍下减库存”的方式，拍下就是一瞬间的事，对用户体验会好些。
10、“超卖”问题
1. 由于库存并发更新的问题，导致在实际库存已经不足的情况下，库存依然在减，导致卖家的商品卖得件数超过秒杀的预期。
方案：采用乐观锁
11、秒杀器的应对
1. 秒杀器一般下单个购买及其迅速，根据购买记录可以甄别出一部分，可以通过校验码达到一定的方法，这就要求校验码足够安全，不被破解
2. 采用的方式有：秒杀专用验证码，电视公布验证码，秒杀答题。
1.3 秒杀架构原则1、尽量将请求拦截在系统上游
1. 传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时
2. 流量虽大，下单成功的有效流量甚小【一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0】。
2、读多写少的常用多使用缓存