昨晚和一公司工作几年的同事闲扯了一些程序人生和技术问题。感觉自己目前的经验还是太少太少了，看的书也不是太多，惭愧啊。
就比如同事问了我一个如何做一个我们很常见的“秒杀”系统，我当时一拍脑门直接回答说加个排它锁不就行了么，但是晚上回到家里google了一番之后，深深的感到脸红啊。一个看似简单的“秒杀”系统，里面涉及到的东西也着实不少，而不仅仅是一个简单的加锁就行了的。我大致整理了一下我想到的和google到的需要注意的地方，当然有很多的不足，同时也希望大神们能够指点一点：
1） 对现有网站业务的冲击
因为秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。
2） 高并发情况以及数据库的负载
用户在秒杀开始前，通过不停的刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器、数据库服务器造成极大的负载压力。
3） 突然增加的网络和服务器带宽
假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10,000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。
4） 直接下单
秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL，如果得到这个URL，不用等到秒杀开始就可以下单了。
5） 防止机器秒杀
防止网上的一些“秒杀器”
针对上面的5个问题，对应的策略如下：
1） 秒杀系统独立部署
为了避免因为秒杀活动的高并发访问而拖垮整个网站，使整个网站不必面对蜂拥而来的用户访问，将秒杀系统独立部署，如果需要，还可以使用独立的域名，以和网站完全隔离，即使秒杀系统崩溃了，也不会对网站造成任何影响。
2） 秒杀商品页面静态化
秒杀商品页面重新设计，不使用网站原来的商品详情页面，页面内容静态化：商品描述，商品参数，成交记录，用户评价全部写入一个静态页面，用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器、数据库服务器。
3） 租借秒杀活动网络带宽
对于因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。
4） 动态生成随机下单页面URL
为了避免用户直接访问下单页面URL，需要将该URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。
5） 防止“秒杀器”感觉很难，
因为似乎总是有办法可以跳过设置的“障碍”。真正做到防止，仅靠webserver怕是很难防范，一般的做法都是增加一些人为的“障碍”，比如：
注册时有一定的门槛，像皮皮书屋一样，通过输入程序执行结果作为验证 –à之前批量手工注册
参加秒杀的积分或者等级策略 -à 挂太阳，就如同你当你为了升级QQ等级的时候一直挂着QQ一样。
验证码，阻止自动化操作 -à 可以图像识别
ip阻止 –à 但是ip可以伪造,可以代理