是个面试题：
背景：商城现有一套成熟的订单系统，支持最高并发1000。抢购活动的时候会有大量用户50w，如何应对这一情况？前提时不要改变现有订单系统。
思路：抢购页面可以独立与商城系统外，可以临时性的在商城系统前添加N台机器，有序的将用户“放行”到商城系统内。
1.抢购商品页面纯静态化（做好qps压测评估），至于用户信息，通过js从cookie里取（临时且快速的方案，安全性不高，只要没黑客恶意搞，其实没什么问题的），如果不存在用户信息，通过ajax发送请求到用户中心生成用户cookie（加载静态页面的时候就判断是否发送ajax，别等到抢购时判断），如果存在，在抢购时直接获取cookie里的用户信息开始抢购。通过js从cookie里取信息可以大量的减少对商城主系统的依赖，防止造成主系统瘫痪
2.抢购开始时用验证码防秒杀器，建议事先生成好几百个验证码，随机取一个，别等到抢购时临时生成，不然容易挂
3.最难点，抢购减库存。防超卖，库存表和判重表建议单独搞台大服务器专门放这2个表，不然50w人开秒死都不知道怎么死的
一）：start transaction;
insert into 判重表;
update goods set goods_num=goods_num-1 where goods_id=111 and goods_num>0;
commit;
goods_num>0防超卖，判断受影响行数如果=0表示秒完了，比select for update悲观锁支撑的并发高多了
对这个sql进行压测，看tps达到多少，调性能参数
innodb_buffer_pool_instances和innodb_buffer_pool_size
三个方向考虑吧。横向就是做分布式，通过添加N台机器，部署N套系统的方式来并发处理。这里面要考虑好session的一致性。纵向的话，就是把瓶颈部分做优化，使用内存来持久数据，减少IO，还有合理的使用消息排队。这里可能要好好考虑内存与数据库一致性。还有就是业务方向。这个根据业务的去优化订单，要你们自己分析了。
为突发的数倍压力准备机器是不合适的。需要的只是能够抗住瞬间压力，同时保证平均压力在可负载的范围内。
可以考虑一些技术手段，比如主动拒绝，分级队列等。
一个是如前面所说的前端页面静态化问题，首先保证抢购页面除了抢购按钮和用户信息都是静态化的并且已经做好了缓存处理。只要前端页面撑得住，至于后台反馈的到底是成功还是失败都好说。
其次后台的设计，最好有一个分层处理做一个滤网。那么多用户是不是非要前1000个才是抢到的？或者是这台服务器只放通过尾号为1和9的，另外一台放通过尾号为2和8的，其余都失败处理？真要全收进来，每个服务器计数满了后面返回失败，然后把成功的送到下一层。
最好在最底层写一个专门做订单队列的server程序，比如可以部署2个server程序，每个server程序只处理先过来的500单请求，然后通知上层已满以便上层直接返回失败，最后从队列慢慢去写订单返回返回给用户就行了。
还有用户订单过期失效等后续问题就自己想办法解决了，反正一共就那么几单。
500000/1000 = 500
lucky_number = 88;
if(random(500) == lucky_number):
// 展示页面
else:
echo '正在排队中。。。刷新可以有机会插队哦~~'
有时候改一下业务逻辑会更有效。呵呵~
update: 为了安全，搞大一点吧
lucky_number = 888;
if(random(1000) == lucky_number):
// 展示页面
else:
echo '正在排队中。。。刷新可以有机会插队哦~~'