秒杀思路:后台根据商品加入秒杀发布秒杀详细信息,生成静态页面,发布信息添加到库,前台查看秒杀信息,
(我前台的概念是买家使用的系统为前台,公司内部使用的管理系统为后台),秒杀中库存和事件通过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:审核接口
一文章不错,大攒下, 秒杀