秒杀思路：后台根据商品加入秒杀发布秒杀详细信息，生成静态页面，发布信息添加到库，前台查看秒杀信息，
（我前台的概念是买家使用的系统为前台，公司内部使用的管理系统为后台），秒杀中库存和事件通过ajax
取服务器时间(客户端的时间不准)，秒杀库存的统计已下单为主，库存数量的更改以下单为准，秒杀结束和下面《》里内容
就直接抛秒杀结束的静态页面.
《阻止秒杀请求，比如有一个商品，已经有100人在秒杀，前100人至少有一个人来买
正在秒杀的信息可以放入缓存(可以用开源的memcached等)【key:商品id，value:action请求统计数】
(只允许让产品数量的N倍以内的人请求秒杀可以通过配置文件判断）》
要参与秒杀的商品都放入缓存中，价格，库存，id，数量，加上一个字段 加上sell_num 卖出数量，缓存中存储是否
已经达到卖出数量，达到的话就直接抛出秒杀结束静态页面。支付的时候根据是否已卖出判断，商品的秒杀数量已经达到的话操作秒杀用户信息的操作事务回滚。先下单成功的去库中减1，保存用户支付信息
( action请求统计数可以单独弄服务器来做 这个action只做一件事情就是统计请求数量,用servlet就可以了，一台不行，弄多台,多台的话可以考虑单独一个缓存服务器)
昨天晚上睡觉的时候还在想这个秒杀，还是发现了一些问题，一个在秒杀商品共享一个action，
1：每个商品的秒杀用户都可能不同，都会变化，一起秒杀过来，怎么让秒杀同一个商品的共享同一个action
2：什么时候开始对USER_NUM开始递增，根据客户端时间显然不行，调度？还是每次请求都判断下时间？
解释下为什么要同一个商品要共享一个action：用户数不是确定的 秒杀这个商品的人肯定得共享这个商品的action，为了知道USER_NUM是否已经超过允许的，不允许的话直接抛出秒杀结束静态页面。有多少的秒杀商品就应该有多少的action实例，请求的这个商品的秒杀就是请求这个商品对应的action，但是参与秒杀的商品数不是固定的。该如何设计action，这样的需求怎么配置？？？秒杀这玩意儿还真的很麻烦，你妹的，看来这样的action无法配置，那就所有用户共同用一个action，放一个map, key:商品ID，value:请求数。这个商品有请求的话就放入map,重新put(商品id,请求+1)每次请求判断下该商品的时间，到了时间就对该商品的请求数进行+1操作
网络误差：请求action的到操作库的时间 可能会导致超过了秒杀结束时
主要的问题
1共同问题：宽带问题
2 服务器端的问题：1：web服务器所在的PC硬件配置 2 web服务器的处理能力 3 数据库服务器的处理能力
用户的问题：1 用户PC配置问题 2 用户所使用的浏览器(用IE就是等死) 3 用户对秒杀点击的及不及时问题
前台对于秒杀时间问题显示问题：加载静态页面用ajax 请求服务器，获取服务器时间当前时间和开始时间，结束时间，
然后页面秒杀的时间就根据第一次请求的时间用js处理
一个文章不错，贴上来：javascript实现秒杀倒计时
被秒杀过的商品数据直接转入历史库，原表不存该数据，减少查询时间，秒杀关注的是未来或者正在秒杀的商品，历史已成为过去，只是查看。
秒杀这东西我感觉都是虚头，刚好那一秒 0 微妙 如此精确的时间，这个时间点可能真的没人在0微妙 秒杀到，那肯定还有要让一个人秒杀到的，估计很多是选这一秒内的随机数，或者这一秒的第一个人。如果以提交订单为主那就谁先提交谁先得到。
提交定后后，秒杀结束，静态页面灰色的立即购买该为该商品以过期，减少不必要的考虑
所有问题都已解决，网络延迟，这个问题我们这个真心没办法
秒杀seckill大致接口：
前台就是请求静态页面查看，ajax查询动态信息，比如库存，秒杀时间
1：查询秒杀分类信息接口(包括全部秒杀，aa秒杀，bb秒杀，价格段秒杀)
2：搜索秒杀接口
3：秒杀详细内页接口
4: 秒杀剩余时间接口
5: 跳转秒杀结束静态页面接口
6：查询秒杀开始结束和当前服务器时间接口
7：查询已卖出数接口
8: 查询秒杀缓存接口
9: 修改秒杀缓存接口
10:删除秒杀缓存接口
后台：
1：商品加入秒杀接口（同时添加到缓存中）
2：秒杀分类管理接口
3：修改详细秒杀信息接口
4：删除详细秒杀信息接口(转入历史库)
5：静态页面生成接口
6：历史秒杀管理接口
7：秒杀搜索接口
8：请求配置（配置商品的N倍才可请求秒杀)
9：审核接口
一文章不错，大攒下， 秒杀