秒杀技术挑战
1.将秒杀系统独立部署，甚至使用独立域名，使其与网站完全隔离，避免对现有业务造成冲击。
2.重新设计秒杀商品页面，不使用网站原来的商品详细页面，页面内容或详情静态化，用户请求不需要经过应用服务。避免对数据库造成冲击。
3.为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。以应对突然增加的网络带宽和服务器带宽。
4.定时上架，控制购买按钮的点亮和下单。页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。以控制下单时间区间。
5. 进行下单前置检查
下单服务器检查本机已处理的下单请求数目：
如果超过10条，直接返回已结束页面给用户；
如果未超过10条，则用户可进入填写订单及确认页面；
检查全局已提交订单数目：
已超过秒杀商品总数，返回已结束页面给用户；
未超过秒杀商品总数，提交到子订单系统；
6.如何应对超卖问题。
做尝试扣减库存，扣减库存成功才会进行下单逻辑：
update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity >= #count#
秒杀架构原则
一.尽量将请求拦截在系统上游。二.读多写少常多使用缓存。
（1）浏览器层请求拦截。
1. 用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求。
2. 限制用户在x秒之内只能提交一次请求。
（2）站点层拦截
前端层的请求拦截，只能拦住小白用户（不过这是99%的用户哟），高端的程序员根本不吃这一套，写个for循环，直接调用你后端的http请求，怎么整？
- 同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面
- 同一个item的查询，例如手机车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面。
如此限流，又有99%的流量会被拦截在站点层。
（3）服务器层设计
站点层的请求拦截，只能拦住普通程序员，高级黑客，假设他控制了10w台肉鸡（并且假设买票不需要实名认证），这下uid的限制不行了吧？怎么整？
1. 大哥，我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？对于写请求，做请求队列，每次只透过有限的写请求去数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”；
2. 对于读请求，还用说么？cache来抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的；
如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。
（4）数据库设计