秒杀思路以及问题

推荐链接

 

秒杀思路：后台根据商品加入秒杀发布秒杀详细信息，生成静态页面，发布信息添加到库，前台查看秒杀信息，

（我前台的概念是买家使用的系统为前台，公司内部使用的管理系统为后台），秒杀中库存和事件通过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：审核接口

 

一文章不错，大攒下， 秒杀        

评论

3 楼 javaboy2006 2014-07-15  

ahyyxx222 写道

感觉想多了，秒杀的重点只是排个队，还有让无意义的人不要再排了。
秒10个，就开放1000个，只要能承受1000并发，监控到数量够了，立即将处理秒杀的服务器断开服务，用另一台服务器静态资源替代。原秒杀服务器开始按到达时间统计那1000个的先后然后取前10个，再去执行入库、购买提示之类的操作准备，然后重新上线，给用户发结果通知，如果有的用户先后时间精确度无法区分，大可以随机排个先后，用户也没理由反对。

memcached还是不要用了，毕竟也是个网络连接，纯内存处理是最快的，进1000个，断开，处理，然后重新上线，通知

分布式环境下如何构建队列？
只能在每个分布式节点上各自构建队列，然后根据可秒杀资源总数从各个队列头中随机获取命中的请求，最后消耗掉资源（持久化），并通知命中的请求会员。

2 楼 步青龙 2012-06-07  

ahyyxx222 写道

感觉想多了，秒杀的重点只是排个队，还有让无意义的人不要再排了。
秒10个，就开放1000个，只要能承受1000并发，监控到数量够了，立即将处理秒杀的服务器断开服务，用另一台服务器静态资源替代。原秒杀服务器开始按到达时间统计那1000个的先后然后取前10个，再去执行入库、购买提示之类的操作准备，然后重新上线，给用户发结果通知，如果有的用户先后时间精确度无法区分，大可以随机排个先后，用户也没理由反对。

memcached还是不要用了，毕竟也是个网络连接，纯内存处理是最快的，进1000个，断开，处理，然后重新上线，通知

多谢，我再整理下思路

1 楼 ahyyxx222 2012-06-07  

感觉想多了，秒杀的重点只是排个队，还有让无意义的人不要再排了。
秒10个，就开放1000个，只要能承受1000并发，监控到数量够了，立即将处理秒杀的服务器断开服务，用另一台服务器静态资源替代。原秒杀服务器开始按到达时间统计那1000个的先后然后取前10个，再去执行入库、购买提示之类的操作准备，然后重新上线，给用户发结果通知，如果有的用户先后时间精确度无法区分，大可以随机排个先后，用户也没理由反对。

memcached还是不要用了，毕竟也是个网络连接，纯内存处理是最快的，进1000个，断开，处理，然后重新上线，通知